11 月 18 日に発生した Azure Storage サービスの中断に関する根本原因分析と改善策の最終報告
このポストは、12 月 17 日に投稿された Final Root Cause Analysis and Improvement Areas: Nov 18 Azure Storage Service Interruption の翻訳です。
2014 年 11 月 18 日、Azure Storage および Virtual Machines などのその他の一部のサービスにサービス中断が発生し、多数の Microsoft Azure ユーザーの皆様にその影響が及びました。インシデント発生後、マイクロソフトでは根本原因分析 (RCA) の暫定報告をまとめたブログ記事を公開し、問題の解決に向けてどのように取り組んでいるかをお伝えすると共に、このインシデントの調査と対策強化を最優先事項として取り組んでまいりました。今回の記事では、このような問題の再発防止策や、お客様とのコミュニケーションやサポート対応の改善策の概要を含む、根本原因分析の最終結果をお伝えいたします。マイクロソフトは、今回のサービス中断によりお客様のアプリケーションおよびサービスに多大なる影響が出ましたことを真摯に受け止め、心よりお詫び申し上げます。また、お客様から Microsoft Azure にお寄せいただいている信頼に改めて感謝しますと共に、フィードバックのご提供を通じて弊社製品の継続的な改善にご協力いただいている皆様にお礼申し上げます。
根本原因分析
11 月 18 日 (太平洋時間) (11 月 19 日 (協定世界時間))、Microsoft Azure でサービス中断が発生し、複数のリージョンで Azure Storage サービスへの接続が断続的に切断される状態となりました。また、Azure Virtual Machines をはじめとする Azure Storage に依存するサービスで、Azure Storage サービスとの接続が切断されたことにより二次的な影響が発生しました。
この報告では、ストレージ更新の際の標準的な手順、この手順からの逸脱によりサービス中断に至った経緯、一部のお客様に対して二次的な障害が発生した原因、およびお客様とのコミュニケーションとサポートに関する問題についてご説明します。また、同様の問題の再発を防止し、お客様とのコミュニケーションやサポート対応を改善するためにマイクロソフトが実施する対策を概説いたします。
Microsoft Azure Storage のデプロイメントについて
Azure Storage のデプロイメントには、ソフトウェアのデプロイメント (コードの発行) と構成のデプロイメント (設定変更) の 2 種類があります。ソフトウェアのデプロイメントと構成のデプロイメントのどちらの場合でも、複数の段階の検証を必ず実施し、小規模な範囲に分けて徐々に Azure のインフラストラクチャにデプロイされます。このように段階的にデプロイする手法は「フライティング (flighting)」と呼ばれ、フライティングの実施中は厳重に正常性を監視します。使用を継続しながらテストを実施し、良好な結果が得られた場合は、適用範囲を広げながら Azure Storage インフラストラクチャ全体に変更をデプロイしていきます。
通常は、このデプロイメントは次の手順で実施しています。
- まず、内部のテスト環境に更新をデプロイし、テストと検証を行います。
- テスト環境での検証に合格すると、次は運用前環境に更新をデプロイし、運用環境と同等のワークロードを実行します。
- 運用前環境での検証の完了後、小規模な範囲の運用環境にデプロイします。
- この範囲での検証工程が完了すると、徐々にデプロイする範囲を広げていきます (フライティング)。更新のフライティング期間中は、このデプロイメントの範囲は地理的に分離されているため、何らかの問題が新たに発生した場合でも、その影響は対となるリージョンの組み合わせ (西ヨーロッパと北ヨーロッパなど) の片方だけに限定されます。
Azure Storage で発生したインシデントの概要
マイクロソフトは、自社プラットフォームのパフォーマンスの強化をあらゆる面で継続的に進めています。今回のソフトウェアの変更は、Azure Storage Table フロントエンドにおける CPU フットプリントを低減させ、Azure Storage のパフォーマンスを強化することを目的としていました。
このソフトウェアの変更は、構成スイッチで新しいコードが既定で無効になるように設定し、上記のフライティングの手法を使用してデプロイしました。その後、テスト環境と運用前環境において、Azure Table ストレージのフロントエンドで構成スイッチを使用してコードを有効化しました。さらに、正常性チェックに合格していることを確認した後、変更を一部の運用環境で有効化して、数週間にわたるテストを実施しました。
テスト期間中、この更新により大幅なパフォーマンス向上が見られ、Azure Table ストレージのパフォーマンスについて一部のお客様で発生していた問題が解決されました。この改善状況を踏まえ、運用環境で更新を広範にデプロイすることが決定されました。このデプロイ中に、次の 2 つの運用上のミスが発生しました。
1. 標準のフライティング デプロイメント ポリシーでは変更を小規模な範囲に分けて徐々にデプロイするということが定められていますが、これが遵守されませんでした。
Azure Table ストレージのパフォーマンスに関する問題の修正を担当していたエンジニアが、この変更は運用環境のインフラストラクチャの一部で数週間のフライティング テストを実施済みであり、インフラストラクチャ全体で有効化してもリスクは低いと考えていたためです。また、構成ツールには、インフラストラクチャ全体に変更を徐々にデプロイするというポリシーを適切に実施する機能がありませんでした。
2. テスト環境および運用前環境における検証は Azure Table ストレージのフロントエンドに対して実施されましたが、構成スイッチが誤って Azure BLOB ストレージのフロントエンドに対して有効化されました。
Azure BLOB ストレージのフロントエンドでこの変更が有効化されたところ不具合が発生し、Azure BLOB ストレージのフロントエンドで無限ループに陥り、サービスの要求を処理できなくなりました。
自動監視機能の警告により、エンジニアリング チームはインシデント発生後数分で異常を認識しました。問題発生後 30 分以内に全世界で変更を元に戻したため、Azure BLOB ストレージのフロントエンドの大部分で問題の発生が回避されました。しかし、既に無限ループが発生していた Azure BLOB ストレージのフロントエンドでは、この無限ループのために構成を更新できませんでした。その結果、構成更新後に再起動が必要となり、復旧までにさらに時間を要しました。
デプロイメント ポリシーの強制適用
問題が発見された後、すべての構成変更が直ちに停止され、主要なデプロイメント ツールの欠陥について調査が行われました。原因分析の終了後、デプロイメント ツールが更新され、コードと構成のどちらのデプロイメントの場合でも、標準的な更新の際には上記のテストとフライティングのポリシーが強制的に適用されるようになりました。
要約しますと、Microsoft Azure には明確な運用上のガイドラインがありながら、デプロイメント ツールは担当者の判断と手順に依存していたという不備があったということです。このツールは更新されたため、現在はデプロイメント プラットフォーム自身によりポリシーが強制適用されるようになっています。
Virtual Machines における二次的なサービス中断
Azure コンピューティングの自動回復機能により、Azure Storage サービスの中断が解消された後、ほぼすべての Virtual Machines は手動操作を必要とせず回復しました。しかし、一部の Virtual Machines では、正常に再起動できなかったり、RDP や SSH、またはその他のパブリック エンドポイントからアクセスできなかったりしたため、手動による操作が必要であることが判明しました。この問題の潜在的な原因は次の 3 つです。
1. ディスク マウントのタイムアウト
回復処理において、サービスが中断からの回復処理を実行している間に Storage サービスの負荷が高まり、一部の VM で起動処理中にディスク マウントのタイムアウト エラーが発生しました。この影響を受けたお客様は、Azure サポート チームが公開したトラブルシューティングに関するブログ記事 (英語) の手順に従うことで VM のブロックを解除することができました。なお、サービスが中断から完全に復旧した後には、Azure Storage サービスの負荷が通常のレベルに戻ったため、ほとんどの Virtual Machines は再起動するだけで回復しました。
2. VM のセットアップの失敗
Storage サービスが中断している間にプロビジョニングおよび作成された Windows Virtual Machines で、Windows のセットアップが正常に完了しませんでした。これらの Windows Virtual Machines は、VM のプロビジョニング手順を再実行して作成し直されました。なお、Linux Virtual Machines はこの影響を受けませんでした。
3. ネットワーク プログラムのエラー
Virtual Network 内にデプロイされたごく一部の Virtual Machines が、RDP 接続や SSH 接続を含むパブリック IP アドレスのエンドポイントに接続できなくなりました。Storage サービスが中断している間にこの状況が発生したため、サービスが中断から回復した後も、ネットワークのプログラムを修正するとができませんでした。影響を受けた Virtual Machines には数時間以内にサービスを復元するための対策がデプロイされ、再起動は不要になりました。
サービス中断時の事象の時系列順のまとめ (日時は協定世界時間)
- 2014/11/19 00:50 AM – 複数のリージョンで Storage サービスの中断を検出しました。
- 2014/11/19 00:51 AM ～ 05:50 AM – 複数のリージョンで Storage サービスに一次的な影響が発生しました。ほぼすべてのお客様に影響が発生しましたが、この時間内に回復しました。
- 2014/11/19 05:51 AM ～ 11:00 AM – Storage サービスの影響範囲は少数のお客様に限定されました。
- 2014/11/19 10:50 AM – Storage サービスの影響が完全に解消されました。また、Storage サービスの中断の一次的な影響により少数の Virtual Machines が引き続き影響を受けていることを確認しました。
- 2014/11/19 11:00 AM – Azure エンジニアリング チームが継続してプラットフォームの自動化を実行し、影響が残っている Virtual Machines の検出と修復を実施しました。
- 2014/11/21 11:00 AM – Azure 環境全体で自動回復処理が完了しました。Azure チームは引き続きお客様からのご質問やサポートの要求に対応しました。
お客様とのコミュニケーションおよびサポートに関する問題
上記のサービス中断のほかにも、インシデント発生中にお客様とのコミュニケーションが不十分で、適切なサポートを提供することができなかったという問題がありました。この問題は、次の 3 つの不備により発生しました。
1) サービス正常性ダッシュボードに掲示される状態情報に遅延や誤りがあった。
2) コミュニケーションのための手段が不十分 (Twitter、ブログ、フォーラム)。
3) Microsoft サポートの対応の遅れ。
サービス正常性ダッシュボードにおけるインシデント初期の掲示遅延と不具合
サービス正常性ダッシュボードでは、発行ツールと同様に Web コンポーネントを使用して状態に関する情報を更新しています。この Web コンポーネントには、必要に応じてフェールオーバーが可能なように、プライマリとセカンダリの 2 つのデプロイメントがあります。Storage サービスの中断を受けてセカンダリ Web コンポーネントへのフェールオーバーを実行したところ、発行ツールにおいてストレージの場所をプライマリからセカンダリに正常に移行できませんでした。この結果、最新の状態情報の発行が遅延し、インシデント初期にプラットフォーム全体について情報が混乱する原因となりました。
データの整合性の問題が解決された後、さらに次の 3 つの問題が発生し、サービス正常性ダッシュボードで正確な情報を提供できませんでした。
1) ダッシュボードのヘッダーに不具合があり、報告事項があるにもかかわらずダッシュボードのページ上部に、すべて正常に機能している旨が表示されていました。インシデント発生中に更新がデプロイされ、誤った表示は修正されました。
2) サービスの一覧表で、各 Azure サービスの状態が正確に表示されませんでした。サービスへの影響の詳細が一覧表では示されず、概要の説明のみが行われました。
3) Virtual Machines に影響が発生している二次的な問題の報告の中で、影響を受けているリージョンがごく一部に限られているという誤った内容が掲示されました。その後、サービス正常性ダッシュボードは更新され、影響を受けている範囲がすべて表示されるようになりました。
コミュニケーション手段の不足 (Twitter、ブログ、フォーラム)
サービス正常性ダッシュボードは状態情報をお伝えする第一の手段ですが、上記の問題により、発生中のサービス中断の問題について Twitter の @Azure アカウントで情報を投稿していました。しかし、このアカウントでのツイートの頻度と内容が十分ではなく、お客様にインシデントの最新の状況とその解決策を適切にお伝えできませんでした。また、Azure ブログの更新も遅れ、サービス中断に関する最新情報をお届けできませんでした。
Microsoft サポートによる対応の遅延
サービス正常性ダッシュボードの不具合は、Microsoft サポートのエコシステムにも影響を及ぼしました。サービス正常性ダッシュボードで掲示される状態情報が不正確であったため、サポートへの電話が通常よりも大幅に増加してしまいました。これは、インシデントの影響を受けたお客様がサービスの正確な情報が得られないために Microsoft サポートに頼らざるを得なかったためです。しかし、お客様からのサポートのお問い合わせが急増した結果、一部のお客様からのお問い合わせへの対応が遅れてしまいました。この問題を解決するために、Azure エンジニアリング チームが Azure サポート チームを支援し、直接対応に当たることでお客様のサービスの回復をお手伝いしました。
改善策
マイクロソフトは Azure プラットフォームのエクスペリエンスの改善に継続して取り組み、下記の点を改善してまいります。
Storage サービスの中断
デプロイメントの手順について、製品の変更を徐々に実施する標準的な手法を、デプロイメント ツールに強制的に適用します。
Virtual Machines のサービス中断
- Windows および Linux の VM における「起動速度低下」の場合の回復性と復旧機能を改善します。
- Storage サービスでのインシデント発生による Windows セットアップのプロビジョニングの失敗に関して、検出と回復機能を改善します。
- 一部のお客様が影響を受けたネットワーク プログラムの不具合について、その原因となったネットワーク サービスを修正します。
コミュニケーション
- ヘッダーの状態情報が不正確となる原因となったサービス正常性ダッシュボードの構成の不具合を修正し、ヘッダーの状態情報が不正確だった原因を解消します。
- ソーシャル メディアによるコミュニケーション手順を新たに組み入れ、複数の手段を使用して効果的に状態情報をお伝えします。
- サービス正常性ダッシュボードとオーサリング ツールの回復性を改善します。
サポート
- Microsoft サポートの自動化ツールおよびインフラストラクチャの回復性を改善します。