はじめに
Azureでシステムを構築・運用して数年が経ちますが、これまで数多くのAzure障害に遭遇してきました。パブリッククラウドの世界では「Design For Failure」という言葉を耳にします。これは、クラウドは必ず止まるものなので、それを前提にシステム設計をしましょう、という考え方です。多くの人がこの考え方に基づきパブリッククラウド上でシステムを構築しますが、いざ障害が発生した時に確実に無傷で済むような作り込みはなかなかできません。VMが突然動かなくなったことに備えて、冗長構成（可用性セットや可用性ゾーン）を組むことは当然ですし、それで救われる障害もありますが、時としてAzure障害というのはAzureのデータセンター内のコア・ネットーワークの障害であったり、グローバルで影響がでるDNS障害であったり、と様々です。こういった障害は一年のうち数回は発生しているものです。我々はこのようなAzure障害とどのように付き合っていけばよいか、考えてみたいと思います。
監視の重要性
当然ですが、システム障害が発生した時には、まずそれに気付く必要があり、そのための監視設計はとても重要です。自社で提供しているサービスが正常に稼働していることを確認するためには「サービス監視（外形監視）」を行いますが、Azure上でシステムを構築している場合は、Azureリソースの「診断設定」ログや「リソースヘルス」を監視したり、クラウド全体の状態を確認するための「サービスヘルス」を監視することも必要です。Azure上での監視・通知については下記のブログでも解説しているのでご参考ください。
障害はいつどのように検知する？
我々はシステム障害をいつどういう形で検知するでしょうか。大きく分けて以下の3パターンがあると思います。
1. 監視システムによる検知
監視システムが正常に機能していれば、システムの異常や障害を検知し通知を行ってくれます。運用側から見れば一番きれいな形です。その後落ち着いて障害対応できますのでヒューマンエラーによる追加障害を引き起こす可能性も低くなりますし、顧客に対しても自発的に障害発生の連絡ができますし、とにかく気持ちが楽です(笑)
2. ユーザからの問い合わせ
二つ目はそのサービスを利用するユーザからの問い合わせにより障害発生に気付くパターンです。これは運用者からすれば、監視設計に漏れがあったことを示すことになりますので、少々気まずい状況になります。顧客報告の雰囲気も重くなりますが、とにかくひたすら頑張って障害対応して、一段落したら監視設計をしっかり見直しましょう。
（斯く言う私も過去同様の失敗を何回もやっています。それだけ監視設計って難しいと思います。）
3. SNSなどによる情報発信
まぁもはやこの方法で障害検知することはないと思いますが、ネット上でも障害情報が上がってきますのでそこから情報取得することもあります。（どちらかというと障害検知時もしくは検知後にその障害の詳細情報や世の中の影響を確認したりするのが目的になります。）
3.1 Azure Status
こちらは誰もが見ていると思いますが、下記Azureサービスの状態を見ることができます。対象サービスが「赤色」であれば明らかにAzure障害が発生しています。他方で、このサイトで対象サービスが「緑色」であれば、一概にAzure障害と言い切れないことになりますので、自システムにおいて詳細な調査を進める必要があります。ただし、このサイトが「緑色」であっても、一部の範囲でAzure障害が発生している可能性は十分に考えられますので断定するのは避けましょう。（自分のVMが乗ってるホストサーバーだけ壊れたなんて言うケースもザラにあります。）
3.2 twitter
その他有効な情報取得の手段としてtwitterがあります。Microsoftが下記のようなAzure障害発信用のアカウントを作っており、何等か障害が発生した場合はこのアカウントから通知されます。”非公式”という扱いですが、発信スピードは速いので是非フォローしておきましょう。
『Azure障害情報(日本関連のみ) 』・・・ https://twitter.com/azurestatusjp
『Azure Support』・・・https://twitter.com/AzureSupport
3.3 Downdetector
あと、私はこんなサイトも参考にしています。
障害情報そのものは上記とあまり変わりませんが、障害の発生箇所の可視化やSNSで発信されているAzure障害関連のつぶやきを拾ってくれますので参考になります。ちなみにAzure以外の障害情報も同様に掲載されており協力なツールです。
とにかくMicrosoft サポートに頼る
実は上記のようなサイトに載るような障害は大規模なものだけです。こういう所に上がらない小規模なAzure障害も多数あり、むしろその方が多い印象です。さらに、こういった小規模なAzure障害による被害の方が情報がない分、対応が面倒で長期化します。そんな時に頼りになる（頼らざるを得ない）のがMicrosoftサポートです。
ここから本番障害に絡んだMicrosoftサポートの使い方について解説していきますが、サポートに関する詳細やノウハウは下記の記事が大変参考になりますので、こちらもご一読ください。
自環境でAzureリソースが正常に動作しなくなった場合は、まずMicrosoftサポートにSR（Service Request）を投げましょう。その際には、対象のサブスクリプションIDやリソース名を正確に伝えることが大事です。私も過去焦ってサブスクIDを誤って伝えてしまい「そんなリソースはありません」という余計なリレーをしてしまったことがありますが、障害対応時は時間との勝負なのでそういう無駄なやり取りが命取りになります。落ち着いて問い合わせしましょう。
Microsoftサポートプラン
Microsoft のAzureサポートプランの説明を貼っておきます。サポートプランは保守運用する環境に応じて選択してください。検証環境はPoC環境であればDeveloperプランで十分かと思いますが、本番ワークロードを運用している場合は、Standardプラン以上が必須です。
さらにエンタープライズで本番ワークロードを運用している場合は「ユニファイドサポート（旧プレミアサポート）」に入ることも検討してください（すでにお客様が入っていることこともよくありますので確認しましょう）。その他にも「MicrosoftパートナーのPremierサポート」などサポート形態は様々です。Microsoftのサポートプランはその種類が多岐にわたり複雑ですので、悩んだらお近くのMicrosoft窓口、もしくはMicrosoftパートナーに相談するのが早いです。
このレベルのプランになりますと、顧客に対しTAM(Technical Account Manager)という人が就きます。通常のサポートは一問一答形式ですが、このTAMは顧客のビジネスを理解した上で、障害発生時のビジネスインパクトを把握しMicrosoft内でエスカレーションをしてくれたり、障害の状況を一早く共有してくれたりと、その顧客の方を向いて対応してくれます。特に障害時においては、営業チームよりプレミアサポートのTAMの方が正確な情報を素早くキャッチできると聞いたことあります。TAMを有効活用することが障害対応を突破する一つのポイントなると思います。
Sev.AでSRをするということ
Microsoftサポートに問い合わせ（SR）を行う際には、重要度（Severity）というものを設定します。C→B→Aの順に深刻度が上がっていきます。
本番障害が発生した場合は、Sev.AでSRを発行することになります。Sev.Aが発行されると、Microsoft側では一時間以内にエンジニアがアサインされ電話連絡が来ます。そこで詳細を会話しながら障害解決に向けた動きを確認することになります。
Sev.Aの注意点としては、
- Sev.Aが上げられるのは、例えばシステム停止などの重要障害で、顧客やエンドユーザにリアルタイムで影響がでている時
- Sev.Aの場合、障害解消が見込まれてSev.Bに下げられるようになるまで時間に関係なく対応できる体制が必要
という2点です。1点目は、仮に問い合わせでSev.Aを使ったとしても、ビジネスインパクトが出てなければ半強制的にSev.Bに落とされることもあります。（当然と言えば当然ですね、むやみにSev.Aを使われてもMirosoft側も困ってしまいます。）また、2点目は言ってしまえば、問い合わせる側も覚悟が必要ということです。時間曜日問わずSev.Aを発行するということは、こちらもきちんと体制を張って対応しなければなりません。本番障害の対応ということであれば当然ですが、逆にそうでない時には使わない方が良いということです。このあたりきちんと押さえた上で問い合わせしましょう。
なお、Microsoftサポートでは、Azureに起因した問題や障害の場合、問い合わせにかかるレイバー（消費時間）はゼロ、つまり無料になることがあります。問い合わせの際にレイバーの消費があるか確認しておくことをオススメします。
障害後の後片付け
Azureサービスの障害である場合、後日MicrosoftサポートからRCA（Root cause analysis）という障害報告書的なものを受領することがあります。
RCAには今回の障害の直接原因・根本原因、対応結果、是正計画 が記載されてます。おそらく後日、障害に対する顧客説明が必要になりますが、その際にMicrosoft側の正式見解としてRCAの内容を報告することになりますので、きちんと読んで理解しておきましょう。
また、Microsoftサポート側の対応は一旦ここまでとなりますが、Microsoft側の是正計画をしっかりウォッチしたい場合は、是正計画に記載されている対応スケジュールを過ぎたあたりで再度SRを発行すれば、サポートエンジニアが対応状況を報告してくれます。
これまでのAzure障害については、下記サイトにまとめられています。RCAもしっかり掲載されていますので、過去分も含めて確認したい場合は参考にしてみてください。
さいごに
今回は、私がこれまで経験してきたAzure障害とその対応方法について思いつく限りで紹介してみました。「Design For Failure」ではないですが、障害というのは今後無くなるものではないと思います。ただ、障害が発生した時に、障害解決に至るまで最短ルートで落ち着いて対応すれば、そんな辛いモノではありません。場数をこなすことも必要ですが、本ブログで書いた内容が少しでもお役に立てば幸いです。
また、「自分はこんなツールで障害を検知している」とか「こんなサイトが役に立つ」みたいな皆様のノウハウがあれば是非共有いただけると嬉しいです。それでは！