共用方式為

2012 年 12 月 28 日に米国南部で発生した Windows Azure ストレージのサービス中断についての詳報

  • 發行項

このポストは、1 月 17 日に投稿された Details of the December 28th, 2012 Windows Azure Storage Disruption in US South の翻訳です。

概要

2012 年 12 月 28 日に発生したサービス中断では、Windows Azure ストレージ アカウントの 1.8% に影響が及びました。影響を受けたストレージ アカウントは、米国南部地域の 1 つのストレージ スタンプ (クラスター) 内のものです。マイクロソフトは、今回のサービス中断とそれに関連する問題によってお客様にご迷惑をお掛けいたしましたことを、深くお詫び申し上げます。この問題について、サービス中断の根本的な原因、復旧プロセス、マイクロソフトが得た教訓、およびサービスの改善に向けた取り組みについて、詳細な情報を提供いたします。また影響を受けたお客様には、後述しますとおり、自動的にサービス クレジットを発行いたします。マイクロソフトでは、今回のインシデントから得られた教訓を活かし、サービス品質の向上に全力で取り組んでまいります。

Windows Azure の概要

サービス中断の詳細と発生した事象について説明する前に、まず Windows Azure のコンポーネントに関する追加情報をお伝えします。

Windows Azure は、地理的に異なる地域に配置された異なるデータ センター間で、多数のクラウド サービスを稼働しています。Windows Azure ストレージは、Windows Azure で実行されるクラウド サービスの 1 つです。地域ごとに「スタンプ (英語)」と呼ばれる複数の物理ストレージ サービスが配置され、各ストレージ スタンプには複数のストレージ ノードのラックが配置されています。今回のインシデントでは、米国南部地域の 1 つのスタンプに問題が発生しました。

各ストレージ スタンプには Windows Azure ファブリック コントローラーが配置されています。ファブリック コントローラーは、リソースのプロビジョニング/管理レイヤーであり、ハードウェアの管理を担当します。Windows Azure プラットフォーム上のクラウド サービスに対して、リソースの割り当て、展開、アップグレード、および管理を行います。ストレージ スタンプごとに配置されているため、ある程度のエラーが発生しても単一スタンプ内だけに影響が止まるようになっており、このしくみが今回のインシデントでは有効に機能しました。

ファブリック コントローラーは、ストレージ スタンプのノード管理、ネットワーク構成、稼働状況の監視、サービス インスタンスの起動と停止、およびサービスの展開を実行します。また、ストレージ スタンプはファブリック コントローラーからネットワーク トポロジ情報、ノードの物理レイアウト、およびストレージ ノードのハードウェア構成の各情報を取得します。ストレージ サービスは複数ディスク間でのレプリケーションおよびデータ配置の管理を担当し、またストレージ クラスター内でデータおよびアプリケーションのトラフィックの負荷分散処理を実行します。

ファブリック コントローラーには、ディスクの再フォーマットなどの処理を誤って実行しないように、「ノード保護」と呼ばれる防御機能が実装されています。マイクロソフトのストレージ サービスでは、サービスで使用されるすべてのノードを保護するためにこの機能を活用しています。ストレージ スタンプは常時保護されるようになっていますが、正当な理由により特定のストレージ ノードの保護が無効化される場合があります。その最も一般的な例として、マシンに対する補修 (修理のための撤去) が挙げられます。ノードの修理完了後、そのノードをファブリックに戻す準備を行っている間は保護が無効化されます。準備作業が完了すると、修理されたストレージ ノードの保護は有効化されます。

根本的な原因

今回は下記の 3 つの原因が複合して起こり、サービス中断につながりました。

1. 問題が発生した単一のストレージ スタンプ内において、修理のためにしばらく撤去されていたストレージ ノードを運用環境に戻す際に、一部のノードの保護が有効化されていませんでした。これは構成プロセスにおける人為的なミスによるもので、その結果、当該スタンプのストレージ ノードのうち約 10% が、保護が無効化されたまま実行されていました。

2. 修理から戻ったストレージ ノードの構成エラーを検出する監視システムに不具合がありました。このため警告が行われず、エスカレーションにも失敗しました。

3. 12 月 28 日午前 7 時 9 分 (太平洋標準時) に、ファブリック コントローラーが当該ストレージ スタンプで新しいプライマリ ノードへの移行を開始しました。新しいプライマリ ノードへの移行は正常なもので、通常のメンテナンスやハードウェアの更新など、さまざまな理由で実施されます。新しいプライマリ ノードの構成が実行されている間、ファブリック コントローラーは既存のクラスターの状態を読み込みます。今回は、ここで発生したバグがファブリック コントローラーに影響し、保護されていないストレージ ノードに対して「準備」処理が誤ってトリガーされました。この準備処理とは、保護されていないストレージ ノードを使用可能な状態にするもので、その中にはノードのドライブに対してクイック フォーマットを実行するという手順が含まれています。ノード保護では、保護されているノードに対してファブリック コントローラーが絶対にフォーマットを実行しないことを保証していますが、残念ながら、当該スタンプ内のアクティブなストレージ ノードの 10% に対して非保護のフラグが誤って設定されたため、準備作業の一環としてフォーマットが実行されました。

ストレージ スタンプ内では、各データは異なる 3 つのフォールト ドメイン (電源、ネットワーク、ラックが異なる) で 3 つのコピーが保持されます。このため、通常はスタンプ内の 2 つのノードで同時に障害が発生してもデータは保持されます。しかし、再フォーマットされたノードがフォールト ドメインすべてに存在したため、一部のデータでは 3 つのコピーすべてが失われました。

ストレージ サービスの復旧

マイクロソフトはノードが再フォーマットされたと判断し、サービス復旧のために 2 つのアプローチを検討しました。

  • 米国南部地域においてインプレースでデータを復元 ( プラン A) - 当該ストレージ スタンプのボリュームおよびすべてのディスクについて、米国南部地域内で可用性を回復します。この場合、データ損失はありません。
  • 米国北部地域への地理的フェールオーバーを実施 ( プラン B) - 当該ストレージ スタンプのお客様を米国南部地域から米国北部地域 (ジオレプリケーション実施先) へフェールオーバー (英語)して可用性を回復します。この場合、以下の事象が発生すると考えられます。
    • ジオレプリケーションは非同期的に実施されるため、Windows Azure の Blob およびテーブルに対する直近の更新が失われます。
    • 現時点では Windows Azure キューの冗長性確保はローカルでのみ実行されるため、当該スタンプのお客様の Windows Azure キューのデータが失われます。
    • 地理的冗長ストレージではなくローカル冗長ストレージをお選びのお客様のデータが失われます。

マイクロソフトはお客様のデータを保護することを最優先し、プラン A を実施しましたが、一定期間内にプラン A が実行できない場合はやむを得ずプラン B を実行することも併せて考えていました。

次に、ストレージ サービスの復旧をインプレースで行う際にマイクロソフトが実施した手順について、また、ジオレプリケーションと地理的フェールオーバーのプロセスの詳細について説明します。

データをインプレースで復元 (プラン A)

非常に限定的なかたちとはいえ、このサービス中断は特異な事態でした。そのため、米国南部地域内でストレージ スタンプを復元するために、マイクロソフトはボリュームのデータをインプレースで復元する方法を設計する必要がありました。この際、効率を考慮し、データを任意のドライブから他のドライブへコピーすることは避けなければなりませんでした。

準備作業の一環として、ファブリック コントローラーにより当該ストレージ ノードのボリュームに対し「クイック フォーマット」が実行されました。このクイック フォーマットでは、初期 MFT (マスター ファイル テーブル) を含む新しいメタデータ ファイルが作成され、一部の初期レコードを除き、MFT の復元には成功しました。MFT の復元作業後、当該ボリュームで「chkdsk /f」を実行し、クイック フォーマットで上書きされた MFT の一部の初期レコードを除くボリューム全体を再作成しました。

初期 MFT レコードにはボリュームのディレクトリ構造のルートが含まれていましたが、この部分はデータが失われていました。そこで「chkdsk /f」の実行時に、ボリューム内で "発見された" ディレクトリの中から親ディレクトリが特定できなかったファイルの配置が実行されました。発見されたディレクトリ内の各ファイルはエクステント (英語) (お客様のデータが格納されているファイル) を示していました。これらのファイルの命名規則にはチェックサムが含まれており、そこから元のファイルの完全なパスがわかります。これにより各エクステントの完全なパスを正確に突き止めることができるため、元のディレクトリ構造を完全に復元することと、復元されたエクステントを "発見された" ディレクトリから適切な場所に移動することが可能でした。

各ストレージ ノードにはジャーナル ドライブ (英語) のディスクが 1 台あり、この復元には更に多くの作業が必要でした。ジャーナル ドライブは、ストレージ ノードが多数の書き込み先ドライブの中の 1 台に対して書き込みを実行する間に、ストレージ ノードへの書き込みを高速でコミットし、その書き込みをユーザーに通知するために使用されます。ジャーナル ボリュームに関しては、復元に使用するジャーナルをコピーするために、ボリューム内のジャーナル ファイルのシグネチャを検索するツールを作成する必要がありました。

インシデント発生から 32 時間経過後、テスト環境において、ストレージ ノードから切り離したボリュームを上記の手法で完全に復元できることが確認されました。これを受けて、プラン A を続行することが決定されました。

この解決策を運用環境に適用する前にテストを実施したところ、事態はより複雑で、復元にはさらなる時間を要することが判明しました。ボリュームの復元を実施するには、ボリュームのロックが必要でした。ボリュームがロックされていることをファブリック コントローラーが検知した場合、そのノードは不良であると判断され、再起動されます。これが、ボリューム復元のために「chkdsk /f」を実行する際の問題点となりました。したがって、データ復元中は、ノードをファブリック コントローラーのサービス管理処理の対象から外して、ノードを保護状態に置く必要がありました。

修理から戻ったノードを復帰させる際に、ファブリック コントローラーはすべてのディスクが機能することを想定しています。そもそもノード上のディスクに障害があるからストレージ ノードを修理し復帰させるわけですから、1 台または複数のディスクに障害があるノードを復帰させるというのは問題です。通常、ファブリック コントローラーは動作中のストレージ スタンプに対して障害のあるノードをオンラインに復帰させることを許可しません。この問題を解決するために、当該ストレージ スタンプのファブリック コントローラー用に修正プログラムを作成し、障害が発生しているディスクを持つノードの復帰を許可しました。

2012 年 12 月 30 日午後 2 時 (太平洋標準時) までにすべてのツールおよびプロセスの検証が終了し、運用環境のストレージ スタンプの完全復元を開始しました。

ストレージの復元はすべてのストレージ ノードで手順どおり実行され、ダブル チェックを経た後、ファブリック コントローラーの管理下に戻されました。その後、当該ストレージ スタンプの全パーティションが読み込まれ、2012 年 12 月 30 日午後 9 時 32 分 (太平洋標準時)、当該ストレージ スタンプは稼働しお客様のトラフィックの処理を開始しました。

マイクロソフトではストレージ スタンプ内のエクステントの完全なリストを常時保持しており、すべてのエクステントを完全に復元しました。さらに、当該ストレージ スタンプ内のエクステントに対してすべてのチェックサムが検証され、データ復元の際にデータ損失がまったくなかったことが確認されました。

地理的冗長ストレージおよび地理的フェールオーバー ( プラン B)

今回の問題について、なぜ被害範囲が完全に判明した時点ですぐにサービスの地理的フェールオーバーを実施しなかったのかというご質問をお客様から多数いただきました。これにお答えする前に、まず地理的冗長ストレージの概要をご説明します。

地理的冗長ストレージの概要

ジオレプリケーションの構成は、ストレージ アカウント作成時に実行されます。お客様がストレージ アカウントの作成先として選択した地域が「プライマリ」となり、お客様のデータの地理的レプリケーションの実施先が「セカンダリ」となります。セカンダリ地域は、プライマリ地域に応じて自動的に決定されます。詳細については、こちらのページ (英語) を参照してください。

地理的冗長ストレージでは、お客様のデータはプライマリ地域とセカンダリ地域の 2 か所に格納されます。この 2 つの場所は数百キロメートル以上離れており、最高レベルの耐久性が実現されています。Windows Azure の Blob およびテーブルは、すべてジオレプリケーションが実施されます。ただし、現時点ではキュー データはジオレプリケーションの対象外です (英語)。地理的冗長ストレージでは、お客様のデータのコピー (レプリカ) をプライマリ地域とセカンダリ地域の 2 か所に 3 つずつ、合計で 6 つ保持します。これにより、各データ センターでドライブやノード、ラックの不良、およびネットワークや電源の問題などの一般的なハードウェア障害が発生した場合でも復旧が可能です。また、大規模災害の際には、セカンダリのデータ センターにジオレプリケーションでコピーされていたデータが提供されます。ジオレプリケーションでは非同期レプリケーションが使用され、バックグラウンドで実行されるため、ストレージ アカウントの更新パフォーマンスには影響しません。2 つの拠点間では、更新内容のジオレプリケーションに関する通信のみが行われ、復旧のための通信は行われません。この点は重要です。つまり、プライマリ地域のスタンプからセカンダリ地域のスタンプに即座にフェールオーバーを実行する必要がある場合、ジオレプリケーションによるセカンダリ地域へのコミットが完了したデータはすべて耐久性が確保されますが、ジオレプリケーションが実行されていない直近の更新によるデータ損失だけは、お客様のアプリケーションで処理する必要があるのです。

フェールオーバープロセス

フェールオーバーとは、ユーザーのストレージ アカウントをプライマリ地域からセカンダリ地域に移動し、その移動先をプライマリ地域とするプロセスです。

現在運用されているジオレプリケーションでは、フェールオーバーはストレージ アカウント単位ではなくストレージ スタンプ単位で実施されます。つまり、地理的フェールオーバーを実施する場合は、1 つのストレージ スタンプ内のすべてのお客様を旧プライマリ地域のストレージ スタンプからセカンダリ地域 (新たなプライマリ地域) のストレージ スタンプにフェールオーバーする必要があります。お客様のデータ損失を最小限に抑えることが目標であるので、プライマリ地域に大規模災害が発生し数日以内での復旧が不可能な場合を除いて、フェールオーバーは実施しません。

今回のサービス中断で地理的フェールオーバーを実施しなかった理由

ジオレプリケーションは非同期的に実施されるため、米国南部地域から米国北部地域へのフェールオーバーを実施していた場合、ストレージ アカウントに対する直近の更新は想定されるとおり失われていたと考えられます。今回問題が発生したストレージ スタンプでは、同ストレージ スタンプ内のすべてのお客様のアカウントで、8 GB の直近のデータ更新が失われたであろうと見積もっています。さらに、Windows Azure キューに対してはジオレプリケーションが実施されません (このサービスは 2013 年に開始予定です)。このため、フェールオーバーを実施していた場合、問題が発生したストレージ スタンプ内のストレージ アカウントでは Windows Azure キューのデータがすべて失われていたと考えられます。また、ローカル冗長ストレージをお選びのお客様は、全データが失われることになります。

お客様からは、可用性よりもデータの耐久性を優先してストレージ スタンプの復元をインプレースで行ってほしいという声と、可用性を重視してフェールオーバーを早急に実施してほしいという声をいただきました。マイクロソフトでは、数日以内に米国南部地域内でデータを損失することなくインプレースでプライマリ ストレージ スタンプを復元できると判断したため、データの耐久性を優先しました。

サービスの改善点

今回のインシデント発生後、十分な時間をとり、この問題について分析し、技術、運用、コミュニケーションの各視点から改善可能な点を検討しました。今回の教訓を最大限に活かし、より信頼性に優れたプラットフォームをお客様にご利用いただくため、根本的な原因を分析し、インシデントについてあらゆる面からの考察を行いました。

分析作業は、下記の 4 つの分野に整理され、各分野のインシデント ライフサイクル、およびそれに先立つ技術的プロセスに注目しました。

  • 検出 – 障害を早急に発見し優先的に復旧作業を実施する方法
  • 復旧 – 復旧時間を短縮する方法とお客様への影響を軽減する方法
  • 予防 – システム障害を回避する方法、またシステムを障害から分離し復旧する方法
  • 対応 – インシデント発生中のお客様のサポート

検出

修理完了後ストレージ ノードへの復帰作業を行う際に発生する可能性がある構成エラーの検出について、監視システムを修正しました。

復旧

マイクロソフトにとって、お客様が耐久性と可用性のどちらを優先するかを選択できること、またお客様が高い回復力を持つアプリケーションを構築できるようにすることは大きな課題です。この課題について、下記の機能を将来的に実装するための取り組みを進めています。

  • キューのジオレプリケーション – Windows Azure ストレージ アカウントのキュー データのジオレプリケーション対応を計画しています。
  • ジオレプリケーション実施先のストレージアカウントに対する読み取り専用アクセス - セカンダリ地域のお客様のストレージ アカウントへ読み取り専用でアクセス可能にすることを計画しています。
  • ジオレプリケーション実施先のストレージアカウントへのお客様の手によるフェールオーバーの実施 – 個々のお客様のビジネス ニーズに応じてデータの耐久性よりもサービスの可用性を優先できるようにすることを計画しています。お客様がストレージ アカウントのフェールオーバーをトリガーできる API を提供する予定です。

予防

ストレージ ノードが準備状態で実行される原因となったファブリック コントローラーのバグは修正しました。マイクロソフトは運用プロセスを見直し、適切なトレーニングが実施されているかどうか、またプロセスの改善が継続的に実施されているかどうかを確認します。

対応

2012 年 12 月 28 日午前 7 時 30 分 (太平洋標準時) から午前 9 時 (太平洋標準時) 頃にかけて、プライマリ サービスの正常性ダッシュボードが使用不能になりました。これは、問題が発生したストレージ スタンプ内のデータが正常性ダッシュボードで使用されていたためです。今回のサービス中断に関連したダッシュボードの更新は、午前 8 時 45 分 (太平洋標準時) に 1 回目が施行されましたが、失敗に終わりました。フェールオーバー サイトは午前 8 時 45 分 (太平洋標準時) に有効化され、午前 9 時 1 分 (太平洋標準時) に正常化しました。

マイクロソフトでは、Windows Azure サービス ダッシュボードについて既に複数レベルのフェールオーバー プロシージャを改良し、類似するインシデントが発生した場合でも影響を軽減できるようにしました。

マイクロソフトが知り得た情報は、Windows Azure ダッシュボードへリアルタイムに掲載するように努めます。

マイクロソフトでは、引き続き Windows Azure プラットフォームの改良に取り組み、今後同様の状況が発生しても、運用中のあらゆるサイトでインシデントが発生しないように対策を講じてまいります。これらの改良のうちの多くは、修正、監視と警告の改善、プラットフォーム全体の回復力を対象としたものですが、サービス中断中にお客様とのコミュニケーションをさらに密に、かつ迅速に提供するための機能も改善いたします。これにより、問題解決予定時刻 (ETA) のさらなる可視化にもつながります。

サービス クレジット

マイクロソフトでは、今回のサービス中断により、お客様に多大なる影響が及んだことを認識しています。このインシデントにおける事態の特殊性と発生期間を考慮し、影響を受けたすべてのお客様に、該当月請求期間の全ストレージ容量とストレージ トランザクション料金に対して、請求金額の 100% のサービス クレジットを発行いたします。

サービス クレジットは自動的に適用され、問題が発生した月の翌月の請求期間に反映されます。ご質問がございましたら、Windows Azure のサポートまでお問い合わせください。

まとめ

Windows Azure チームでは、今後数週間、引き続き今回の問題およびお客様に対する影響について見直しを行い、サービスの改善に向けてあらゆる措置を講じてまいります。マイクロソフトは今回のサービス中断によってお客様に影響が及んだことについて深く反省し、お客様のビジネス ニーズを満たす、可用性の高いサービスを提供するために全力での取り組みを継続いたします。