2012年2月29日のWindows Azureサービス中断の総括

~ SATO Naoki (Neo) /さとうなおき

次のブログ ポストの日本語訳です。

はじめに

3月1日のポスト (英語 / 日本語) のフォローアップとして、2月29日のサービス中断の根本原因分析 (RCA/Root Cause Analysis) の結果を共有したいと思います。多数のお客様が今回の障害の影響を受けたことを我々は知っており、何が起こったか、どのような問題が見つかったか、我々がこれらの問題をどのように解決する計画があるか、今後、同様の問題を回避するために今回の問題から我々が何を学んだかに関して、透明性を高くしたいと考えています。

改めまして、今回の問題が引き起こした中断、ダウンタイム、ご迷惑についてお詫びいたします。我々は、次に説明するように、影響を受けたお客様に対してサービス クレジットを積極的に発行します。我々は、Windows Azureを改善するために、今回学んだことを使って熱心に作業していますので、ご安心ください。

Windows Azureとサービス中断の概要

Windows Azureは、コンピューティング、ストレージ、ネットワーキング、(サービス バスやSQL Azureなどの) より高レベルのサービスといった、多数の異なるサービスから構成されています。今回の部分的なサービス停止は、Windows Azureコンピューティングと、それに依存しているサービス (アクセス コントロール サービス (ACS)、Windows Azureサービス バス、SQL Azureポータル、Data Syncサービス) に影響を与えました。Windows Azureストレージ、SQL Azureには、影響を与えませんでした。

今回の問題を引き起こしたのは特定のソフトウェア バグでしたが、Windows Azureは多数のコンポーネントから構成されており、今回の中断を複雑化させた、通常の運用との他の相互作用がありました。今回の問題には、2つの段階がありました。第1段階では、初期のソフトウェア バグの検出、対応、修正に集中しました。第2段階では、進行中だった通常のサービス運用との予期せぬ相互作用によって影響を受けた、少数のクラスターに集中しました。今回の問題の技術的詳細を理解するには、いくつかの低レベルWindows Azureコンポーネントの機能の背景が必要です。

ファブリック コントローラー、エージェント、証明書

Windows Azureでは、クラウド アプリケーションは、マイクロソフト データセンター内の物理サーバー上で稼働する仮想マシン (VM) から構成されています。サーバーは約1000台の「クラスター」にグループ化されており、ファブリック コントローラー (FC) と呼ばれるスケールアウト型で冗長なプラットフォーム ソフトウェア コンポーネントによって、各クラスターは独立して管理されています (図1参照)。各FCは、そのクラスター内で稼働するアプリケーションのライフサイクルを管理し、管理下にあるハードウェアの健全性のプロビジョニングと監視を行います。FCは、(サーバーに障害が発生したと判断した際の、健全なサーバー上での仮想マシン インスタンスの起動などの) 自動操作と、(アプリケーションのデプロイ、更新、スケールアウトなどの) アプリケーション管理操作の両方を実行します。データセンターをクラスターに分割することで、FCのレベルで障害を隔離し、ある種のエラーが、そのエラーが発生したクラスター外のサーバーに影響を与えることを阻止します。

図1: クラスターとファブリック コントローラー

Windows AzureのPaaS (Platform as a Service) 機能の一部は、VMによって使われるOSイメージにデプロイされている「ゲスト エージェント」(GA) を介した、VM内で稼働するアプリケーションとの密接な統合を必要とします (図2)。(HTTPSエンドポイントを保護するために、アプリケーションがパッケージに含めるSSL証明書などの) アプリケーションのシークレットをデプロイしたり、VMが健全かどうか、FCが復旧アクションを取るべきかどうかを判断するためにGAに「ハート ビート」したりするためにFCが活用する「ホスト エージェント」(HA)を、各サーバーは持ちます。

図2: ホスト エージェントとゲスト エージェントの初期化

物理/論理ネットワークを送信される際に、証明書などのアプリケーション シークレットが常に暗号化されるように、GAは初期化時に「転送証明書」を作成します。GAのHAへの接続セットアップの間にGAが取る最初の手順は、HAに転送証明書の公開鍵バージョンを渡すことです。すると、HAはシークレットを暗号化できます。GAだけが秘密鍵を持っているので、対象VM内のGAだけがそれらのシークレットを復号できます。

新しい転送証明書の生成が必要となる場合が、いくつかあります。これは、ほとんどの場合、(ユーザーが新規デプロイを開始した際に発生する) VMの新規作成、デプロイのスケールアウト、またはデプロイのVM OS更新のときだけです。第4の場合は、FCが不健全だと見なしたサーバー上で稼働していたVMを、FCが別サーバーで起動するときです。これは、プラットフォームが「サービス復旧」と呼ぶプロセスです。

うるう日バグ

GAが転送証明書を作成するとき、GAは転送証明書に1年間の有効期間を与えます。GAは、世界標準時で現在の日付の午前0時を有効期間の開始日として使い、その日の1年後を有効期間の終了日として使います。うるう日バグは、GAが単純に現在の日付の年に1を加えることで、有効期間の終了日を計算していたことです。これは、うるう日に転送証明書の作成を試みたGAは、有効期間の終了日として、証明書作成の失敗を引き起こす不正な日付である2013年2月29日を設定することを意味します。

前述の通り、転送証明書の作成はGA初期化の第1段階であり、GAがHAに接続する前に必要となります。GAが証明書作成に失敗すると、GAは終了します。HAは、GAからの連絡について25分間のタイムアウトを持ちます。GAがこのタイムアウト時間以内にHAに接続しない場合、HAはVMのOSを再初期化し、再起動します。

クリーンなVM (お客様のコードが実行されていないVM) でHAへの接続が3回連続でタイムアウトした場合、ハードウェアの問題でなければGAがエラーを報告するはずなので、HAはハードウェアの問題が原因だと判断します。すると、HAは、このサーバーに障害が発生しているとFCに報告し、FCは、このサーバーを「人間による調査が必要」(HI/Human Investigate) と呼ばれる状態に移します。HI状態にあるサーバーに対する標準的な自動障害復旧操作の一部として、FCは、障害が発生したサーバーに割り当てられていたすべてのVMを、他のサーバーで起動することで、サービス復旧します。今回の場合、VMが利用可能なサーバーに移動された時、GA初期化の間にうるう日バグが再現し、結果としてサーバーが次々にHI状態に移ります。

次々に起こるソフトウェア バグがクラスター全体の停止を引き起こすことを回避するために、FCはHIしきい値を持ちます。HIしきい値に達すると、本質的にはクラスター全体が類似のHI状態に移ります。この時点で、FCは内部で開始されたすべてのソフトウェア更新を停止し、自動サービス復旧は無効化されます。この状態は、機能低下してはいるものの、問題がさらに進行する前に、制御して問題を修正する機会をオペレーターに与えます。

うるう日バグの発生

うるう日バグは、2月28日 午後4時 (PST) (世界標準時で2月29日 午前0時) に、新規VMのGAが証明書生成を試みた際に、即座に引き起こされました。ストレージ クラスターはGAとともに動作しないため、ストレージ クラスターは影響を受けませんでしたが、通常のアプリケーションのデプロイ、スケールアウト、サービス復旧は、VMの新規作成を引き起こしました。同時に、多数のクラスターでは、FC、HA、GAの新バージョンの展開中でもありました。これによって、これらのクラスターでは即座にこのバグが発生し、ちょうど75分後 (3×25分のタイムアウト) の午後5時15分 (PST) に、サーバーのHIしきい値に達しました。更新中ではなかったクラスターでは、このバグはよりゆっくりと広がっていきましたが、クラスター更新に関する致命的な警告が自動的に更新を停止し、運用スタッフに問題を警告しました。そして、運用スタッフはオンコール (待機中) のFC開発者に通知し、この開発者が原因を調査し、午後6時38分 (PST) にバグを特定しました。

この時までに、1つのVMがオフラインになったアプリケーションがあり、複数のVMがオフラインになったアプリケーションもありましたが、複数のVMを持つほとんどのアプリケーションでは、キャパシティが多少減ったものの、可用性は維持されていました。お客様が、うっかり稼働中のアプリケーションにさらなる影響を与えたり、アプリケーションのスケールアウトを試みて失敗したり、新規アプリケーションのデプロイを試みて失敗したりすることを避けるために、我々は、午後6時55分に世界中のすべてのクラスターで、サービス管理機能を無効化しました。我々は、今回初めてこの手順を踏みました。サービス管理によって、お客様はアプリケーションのデプロイ、更新、停止、スケーリングが可能になりますが、すでにデプロイ済みのアプリケーションの継続的な運用には、サービス管理は必要ありません。しかし、サービス管理を停止すると、お客様は現在デプロイ済みのアプリケーションの修正や更新ができなくなります。

我々は、午後10時 (PST) 前後までに更新されたGAのテスト/展開計画を作成し、午後11時20分 (PST) に更新されたGAコードを準備し、2月29日 午前1時50分 (PST) にテスト クラスターでのテストを完了しました。並行して、我々自身のいくつかのアプリケーションのVMを含む運用クラスターで、修正のテストに成功しました。次に、1つの運用クラスターへのGAの展開を開始し、午前2時11分 (PST) に成功裏に完了しました。この時点で、修正をすべてのクラスターに展開しました。クラスターが更新されるにつれて、クラスターに対するサービス管理機能を復旧し、午前5時23分 (PST) に、クラスターの大部分でサービス管理が復旧したことを発表しました。

2次停止

サービス管理が無効化されていた時、ほとんどのクラスターは、すでにFC、GA、HAの最新バージョンを実行しているか、それらの展開がほとんど完了しているかのどちらかでした。これらのクラスターは、完全に修復されました。しかし、7つのクラスターでは、今回のバグが影響を与えた時に、最新バージョンの展開が始まったばかりでした。ほとんどのサーバーでは古いHA/GAの組み合わせであり、いくつかのサーバーでは新しい組み合わせでしたが、どちらにもGAのうるう日バグが含まれていました (図3)。

図3: HAとGAの異なるバージョンを実行しているサーバー

我々は、部分的に更新された状態にあるこれら7つのクラスターを修復するために、異なるアプローチを取りました。修正された新しいGAとともに新しいHAに更新する代わりに、修正されたGAとともにFC、HAの旧バージョンを復旧しました。我々が取った第1の手順は、古いGAとのバージョン互換性を維持するために、すでに新しいHAに更新済みだったサーバーに、古いHAを配置することで、ソリューションをテストすることでした。サーバー上のVMは成功裏に開始され、健全なように見えました。

通常の状況下では、クラスターにHAとGAの更新を適用する時、アップデート ドメイン (UD) と呼ばれるデプロイの可用性制約を守るため、更新には多くの時間がかかります。標準デプロイ機能を使って古いHAを押し出す代わりに、我々は、テストによって、同時にすべてのサーバー上のHAの旧バージョンを更新する「一斉」更新を選ぶだけの十分な自信がありました。

残念ながら、我々が熱心に修正をデプロイする中で、古いHAとともに作成した更新パッケージが、新しいHA向けに書かれたネットワーキング プラグインを含んでおり、これら2つには互換性がなかったという事実を、我々は見落としていました。ネットワーキング プラグインはVMの仮想ネットワークの構成に対する責任を負っており、このプラグインの機能がないと、VMはネットワーキング機能を持ちません。我々の単一サーバーでのテストは、サーバー上のVMへのネットワーク接続性のテストを含んでおらず、この接続性は機能していませんでした。図4は、互換性のない組み合わせを示しています。

図4: HAとHAネットワーキング プラグインの互換性のない組み合わせを実行しているサーバー

2月29日 午前2時47分 (PST) に、我々は、(これまで健全だったクラスターを含む) これら7つのクラスターとそのすべてのVMに、互換性のないコンポーネントの組み合わせを展開し、これらのクラスターのネットワークからの切断を引き起こしました。アクセス コントロール サービス (ACS)、Windows Azureサービス バスなどの主要サービスが、これらのクラスターにデプロイされていたため、依存しているサービスの喪失のせいで、これらのサービスを使うアプリケーションが影響を受けました。

我々は修正済みのHAパッケージを迅速に作成し、午前3時40分 (PST) に再度テストしました。今回は、VMの接続性とVMの健全性の他の側面を確認しました。これら7つのクラスターに対する影響を考え、我々は午前5時40分 (PST) から修正を一斉に展開することを選択しました。午前8時 (PST) までにクラスターの大部分は再び運用可能になっていましたが、多数のサーバーが多様な遷移の結果として不正な状態にありました。その日の間中、開発者と運用スタッフは猛烈に作業し、これらのサーバーを手動で復旧し、検証しました。クラスターとサービスがオンラインに復旧したので、3月1日 午前2時15分 (PST) に、我々はサービス ダッシュボードを更新し、すべてのWindows Azureサービスが健全になったという、問題に対する最後の更新を掲載しました。

サービスの改善

問題が発生した後、我々は時間を取って、今回の問題と、我々がエンジニアリング、運用、情報伝達を改善できる方法を分析しました。できる限り学ぶために、我々は根本原因分析を行い、続いて、今回の問題のすべての側面の分析も行いました。クラウド コンピューティングの3つの真実は、ハードウェアには障害が発生し、ソフトウェアにはバグがあり、人間は間違いを犯すことです。我々の仕事は、お客様のために堅牢なサービスを提供するために、これらの予測できない問題のすべてを軽減することです。これらの問題を理解し解決することで、我々は、お客様に提供しているサービスを改善し続けます。

分析は、4つの主要領域に編成されており、問題のライフサイクルの各部分と、それに先立つエンジニアリング プロセスを見ていきます。

  • 防止 – システムがどのように障害を回避し、障害を隔離し、障害をから復旧するか
  • 検出 – どのように障害を迅速に表面化させ、復旧を優先するか
  • 応答 – 問題が発生している間、どのようにお客様をサポートするか
  • 復旧 – どのように復旧時間を削減し、お客様への影響を軽減するか

防止

  • テスト – 初期の停止の根本原因は、不正確な日付/時間値の操作によるソフトウェア バグでした。時間関係のバグを検出するために、我々はテストを改善する措置を講じつつあります。また、この種の、あるいは類似のコーディング問題を検出するために、コード分析ツールを拡張しつつあり、すでにコード ベースのレビューを行いました。
  • 障害の隔離 – ファブリック コントローラーは、ゲスト エージェント (GA) のバグによってGAの操作が失敗した時、ノードを「人間による調査が必要」(HI/Human Investigate) 状態に移しました。ファブリック コントローラーは、GAではなくハードウェアに障害が発生しているという、間違った想定をしました。我々は、これらの障害を識別し、障害がシステムにさらに伝播する前に障害を隔離する措置を講じつつあります。
  • グレースフル デグラデーション (正常な機能低下) – 今回の問題が発生している間、お客様のすでに稼働中のサービスを保護するために、我々はサービス管理を止める措置を講じましたが、これによって、サービスの継続的な管理もできなくなりました。我々は、サービスのある側面を無効化しつつも、他の側面を稼働させ可視化させたままにできるように、より細かい粒度で制御できるようにする措置を講じつつあります。

検出

  • フェイル ファスト – 75分間の長いタイムアウトの後まで、GAの障害は表面化しませんでした。我々は、このような場合にフェイルファストし、これらの障害を警告し、復旧を開始するように、エラーをより良く分類するための措置を講じつつあります。

応答

  • サービス ダッシュボード – Windows Azureサービス ダッシュボードは、個別のサービスの健全性をお客様に伝達する主要な機構です。しかし、サービス ダッシュボードでは断続的に可用性の問題が発生し、サービス ダッシュボードは全体としての状況の要約を提供できず、お客様が必要とし期待する粒度の詳細と透明性を提供できませんでした。
    • 断続的な可用性 – このダッシュボードは、どちらか一方のシステムの壊滅的な障害に対処するために、Windows AzureとMicrosoft.comという、2つの異なる内部インフラ上で稼働しています。また、地理的に固有の問題に対処するために、ダッシュボードは地理的レプリケーションもされています。しかし、並外れた大量の負荷と、発生したフェイルオーバー/負荷分散によって、ダッシュボードでは断続的な可用性の問題が発生しました。我々はこれを修正し、将来、より堅牢なサービスを確実にするための措置を講じました。
    • 状況の要約 – サービス ダッシュボードは、サブリージョンのレベルで60以上の個別のサービスの健全状態の情報を提供しています。これは個別のサービスの状態の理解には有益ですが、要約情報が欠落していることで、お客様が状況を総合的に理解することが難しくなっていました。迅速に停止の範囲と深刻度の包括的な理解を得るために、お客様はダッシュボード上に要約表示を求めています。我々は、この修正を行う措置を講じつつあります。
    • 詳細と透明性 – 1時間ごとに更新が掲載されたものの、状態の更新はしばしば一般的だったり、過去数時間に提供された情報を繰り返したりしていました。お客様は我々に、問題を解決するために行われている具体的な作業に関する、更なる詳細と新情報を提供するよう求めています。我々は、停止を解決するために講じている措置に関する更なる詳細と透明性、および、これまでの前進と後退に関する詳細を提供することを約束します。
  • 顧客サポート – 今回の問題が発生している間、我々は並外れて多い問い合わせを受け、期待されるよりも長い待ち時間を引き起こしました。停止の問題の際の多数の問い合わせを処理するようにスタッフを配置していますが、サービス ダッシュボードの断続的な可用性と、他の伝達経路を介した更新の欠如が、問い合わせ件数の増加の一因となりました。我々は、顧客サポートのスタッフ配置の必要性を再評価し、より幅広い一連の経路を介した、より透明性のある伝達を提供するための措置を講じつつあります。
  • 他の伝達経路 – かなりの数のお客様が我々に、問題発生時にお客様に伝達するために、ブログ、Facebookページ、Twitterアカウントをより良く使うことを求めています。また、問題発生後に、より迅速に電子メールを介した公式の情報伝達を提供することも求めています。我々は、情報伝達を全体的に改善し、これらの経路を介してより積極的に情報を提供する措置を講じつつあります。また、特定のサービスに関する問題を診断するために、お客様とサポートにより粒度の細かいツールを提供する措置も講じつつあります。

復旧

  • 内部ツール – 今回の問題を解決するために、我々はいくつかの内部ツールを開発し修正しました。我々は、復旧を早めるのを助け、中間状態からの復旧をより予測可能にするために、ツールへの投資を継続します。
  • 依存性の優先順位 – また、我々はお客様への影響を軽減するため、ACSやWindows Azureサービス バスといった、すべてのWindows Azureインフラ サービス確実にが最初に復旧されるように、依存性が間違いなく復旧に組み込まれるよう、プロセスを調査しています。
  • 可視性 – 我々は、復旧手順に対するより良い可視性をどのように提供でき、進行中の中間的な進捗に対する可視性をどのようにお客様に提供できるか、調べています。

サービス クレジット

マイクロソフトは、今回の停止が多数のお客様に重大な影響を与えたことを認識しています。我々は、我々のサービスの品質と我々のSLA (サービス レベル合意) を重んじており、引き続きお客様を大事にしています。今回の問題の並外れた性質のため、我々は、Windows Azureコンピューティング、アクセス コントロール、サービスバス、キャッシングのすべてのお客様に、お客様のサービスが影響を受けたかどうかに関係なく、影響を受けたこれらのサービスの請求月全体に対して、33%のクレジットを提供することを決定しました。これらのクレジットは積極的に適用され、影響を受けた請求期間の次の請求期間で反映されます。追加の質問があるお客様は、更なる情報に関してサポートにお問い合わせください。

結論

我々は、ここまで概略を説明した問題のすべてを完全に理解するために、時間を費やし続け、今後数日から数週間にわたって、我々のサービスを改善するために、問題を解決し軽減するための措置を講じます。お客様自身のサービスがWindows Azureに依存していることを我々は知っており、我々はお客様とともにSLAを真摯に受け止めています。問題が発生した時には、我々はお客様に対して透明性を高くし続けるよう努力します。また、エンジニアリング、運用、情報伝達、顧客サポートを向上し、お客様に対するサービスを改善するために、今回の学びを活用します。

Bill Laing and the Windows Azure Team

関連情報

 

 

2012/03/12 追記

Unknown's avatar

Published by SATO Naoki (Neo) /さとうなおき

Azure Technologist at Microsoft

2 thoughts on “2012年2月29日のWindows Azureサービス中断の総括”

  1. Pingback: Windows Azure サービス中断の話 « ブチザッキ
  2. Pingback: Microsoft Azure（クラウドサービス）が水曜日に長時間停止！ | ITnews online 日本語 Blog

Leave a comment