3/8 に Azure の Japan East で久し振りに大規模な障害が発生しました。既に RCA が上がってきていて、ぶちぞう RD がブログで書いているので、原因についてはそっちを参照で。
そして今年も 3/11 を過ぎたことですし、ちゃんとアーキテクチャと運用を最新のサービスや仕組みでリフレッシュしていかないといけないですね。ちょっとポエム臭くなってきたけど、割と中身は真面目に。
さて、障害の継続時間は 2 時間ぐらいでしたが、例によって Storage 周りの障害だったため、数多くの Azure サービスが影響を受けました。障害発生中の Azure Status はこんな感じでした。
Azure の Storage はご存知のように Blob / Table / Queue / Disk / File といった、各サービスの土台となる機能を提供しているので、ここに障害が発生すると大体こうなります。
これまでに数回、大規模な Storage 障害発生していますが長時間かつグローバルで影響を受けてます。今回は Japan East だけで 2 時間で回復という、珍しいパターンのように感じます。
Publickey のクラウドサービスの障害まとめは、後から振り返ることが出来て良いですね。
利用したことがない人には想像が付きにくいかもしれないですが、AWS でいうと EBS と S3 と SQS に対して同時に障害が発生したようなものです。以前 EBS に障害が発生した時、やはり規模は大きくなりました。
Azure や AWS に関係なく、クラウドの障害は基本的に発生するものなので、障害発生時にも可用性を維持するための機能が用意されています。Azure だと可用性セットだったり、AWS だと Multi-AZ とかですね。
よく使われているサービスに対して、どのように備えておくべきなのか調べたり考えたのでまとめました。
High availability と Disaster recovery
Azure はこういった場合のアーキテクチャに関してドキュメントを用意しています。まだ英語ですが、徐々に日本語に翻訳されていくはずです。
最初に HA と DR について定義がされています。この違いは重要だと思うので頭に入れておきたいです。
Storage
作成する時に LRS / ZRS / GRS / RA-GRS などを選択します。GRS / RA-GRS は別のリージョンに非同期でレプリケーションが行われているので、6 個のレプリカが常に用意されて安心。という仕組みです。*1
Storage で GRS を使っている場合には、障害発生時にセカンダリリージョンに対してフェールオーバーが行われますが、このフェールオーバーが実施される条件というのは非常にハードルが高いです。
具体的にはデータセンター全体が災害などによってダメージを受けた場合ぐらいのようです。
実際に 3/8 の障害でも、これまでの障害でもフェールオーバーは行われていませんし、これまでに Storage でフェールオーバーが実施されたという情報を見たことがないです。基本的に DR 向けの機能というわけです。
Microsoft としても、まずは「復旧を待つ」という選択肢を最初に持ってきています。
オプション 1: 復旧を待つ
Azure Storage の停止が発生した場合の対処方法 | Microsoft Docs
この場合、ユーザーによる操作は必要ありません。 Azure サービスを利用できるようにするために鋭意取り組んでいます。 サービスの状態は Azure サービス正常性ダッシュボードで監視できます。
障害が数十分で解決するのか、それとも数時間になるのかは予測が出来ないので、サービスによっては復旧を待つという選択は取りにくい場合もあると思います。
なので今回の障害の場合にも Storage の可用性を維持するためには、Japan East / Japan West にそれぞれ Storage を用意して同時に書き込む、もしくは独自にレプリケーションを行うしかなかったでしょう。
Blob の場合は 2 つのアカウントを CDN エンドポイントとして追加することで、比較的簡単に対応できそうです。Queue も普段はランダムで選んだアカウントで読み書きし、障害時には動作しているほうだけ使う、という対応も考えられるでしょう。この辺りは割と簡単ですね。
SQL Database
Stoarge の障害では大体 SQL Database も影響を受けます。理由は言うまでもありません。
しかし Storage の GRS が余程のことがない限りフェールオーバーしないのに対して、SQL Database は Active Geo Replication という機能が用意されているので、実は対応が割と楽になっています。
アプリケーション側では接続文字列をフェールオーバー時に切り替える必要はありますが、実装方法次第で簡単に解決することもできるはずです。
ドキュメントでは SQL Database を利用したアーキテクチャが複数紹介されています。
そして重要なのが実際に障害を発生させて、テストを定期的に行うことでしょう。特に最近は GitLab のデータベース喪失の話もありましたし、注目されているかと思います。
これもまたドキュメントが用意されているのと、Active Geo Replication は手動でフェールオーバーを行うこともできるので、一昔前に比べると圧倒的に行いやすくなっています。
とはいえ、障害がすぐに解消する可能性が基本的には高いので、まずは復旧を待つという選択肢が有効です。
App Service (Web App / Mobile App / API App)
App Service はコンテンツの格納に Storage を使っているので、障害が発生すると Web サーバーとしては動作していても、ファイルが読み込めないため動かないというパターンになります。
基本的に App Service などの Web サーバー系はステートレスに作るべきで、そうすれば複数リージョンに常にアプリケーションをデプロイして、Traffic Manager でフェールオーバーを行うことが出来ます。
複数リージョンに対してアプリケーションをデプロイする方法は、標準では提供されていないので AppVeyor などの CI SaaS からローリングで更新したり、手軽にするなら Site Replicator Extension 方法もあります。
Virtual Machines
VM の SLA は Standard Storage の場合は 2 インスタンス以上、Premium Storage の場合は 1 インスタンスとなってますが、基本的には可用性セットを作成して最低 2 台用意し、障害ドメインを分けておくべきです。
可用性セットや障害ドメイン、更新ドメイン含めて、ドキュメントがちゃんと用意されています。最高。
VM は用途にもよると思いますが、DR のことも考えると App Service と同様に別リージョンに用意しておける作りにしておくのが重要でしょう。つまりステートレスに作っておくということです。
今回の障害では Managed Disk を使って VM を立ち上げていると、影響をほぼ受けなかったとのことです。Managed Disk はかなりイケてるサービスです。
先日のAzure Storage障害を受けて。Azure SQL DBはアクティブ地理レプリケーション、VMはManaged Diskを構成していれば、影響はほぼなかったはずです。
— SATO Naoki / さとうなおき (@satonaoki) 2017年3月10日
Active Geo Replication を含め、新しくリリースされたサービスに乗っかっておくというのは、割と重要なポイントだと思います。まだまだリージョン間に跨ってサービスを運用させるには手間がかかりますが、どのように対応するかを知っておくだけでも違います。
まとめ
最後の方は疲れて適当になってきた感がありますが、ちょっと何するべきかまとめます。
- 大前提として Japan East / Japan West の運用をとれる構成にする
- Storage は DR の観点から GRS を有効にする
- HA としては複数リージョンでアカウントを分けてアプリケーションレベルでの対応
- SQL Database は Active Geo Replication を有効にする
- 必要ならさらに自動バックアップを使う
- App Service / Virtual Machines はステートレスに作る
- いつでも破棄、作り直しが出来るような作りに
- Virtual Machines では可用性セットと Managed Disk を使う
ただし、ダウンタイムが許容できる場合は復旧するまで待つという選択肢で十分です。それでも Storage の GRS や SQL Database のバックアップは行っておきましょう。
余談ですが、今回の障害で Azure を使っている bitFlyer も例外なく影響を受けていたのですが、1 時間後ぐらいに Japan East から Japan West への切り替えが行われていて、真面目にかなり凄いと思いました。
切り替えに至った決断など、その時の話を聞いてみたいものです。
*1:ZRS は正直よくわからない
