Freigeben über

2013年2月22日 (日本時間2月23日) に発生した Windows Azureストレージ サービス中断の詳細について

  • Artikel

このポストは、3 月 2 日に投稿された Details of the February 22nd 2013 Windows Azure Storage Disruption の翻訳です。
(3月3日追記) 一部翻訳表現の変更により修正・加筆しています。

はじめに

2013年2月22日午後12時29分 (太平洋標準時 以下PST) [2月23日 (日本時間 以下JST)] に、全地域でサービス中断が発生したため、HTTPSでWindows Azure ストレージ (BLOB、テーブル、キュー) にアクセスしていたお客様に影響が及びました。2013年2月23日午前00:09 PST [17:09 JST] に、Windows Azure ストレージ (BLOB、テーブル、キュー) を全地域で復旧いたしました。

サービス中断が原因でお客様にご迷惑をおかけしましたことを謹んでお詫び申し上げます。下記のとおり、影響のあったお客様に対して、自主的にサービス クレジットを発行させていただきます。

お客様へのサービスの信頼性を向上するために、サービス中断の根本原因、復旧プロセス、我々の学んだこと、サービス改善策など、より多くの情報を提供させていただきます。

Windows Azureの概要

サービス中断の詳細に入る前に、発生したことの背景をより良くご理解いただくため、最初に、今回の事故に関係するWindows Azureの内部構成要素について情報共有させていただきます。

Windows Azureでは、世界全域にある多数のデータセンターと地理的地域で、多数のクラウド サービスが稼働しています。各地理的地域に、スタンプと呼ばれる複数の物理的ストレージ サービスが配置されています。各ストレージ スタンプは、ストレージ ノードが含まれる複数のラックで構成されています。

Windows Azureファブリック コントローラーは、ハードウェアの管理と、Windows Azureプラットフォーム上のクラウド サービスに対するリソース配分、配置機能や更新機能、管理の提供といった、リソースのプロビジョンニングと管理をつかさどるレイヤです。

Windows Azureは、サービスを稼働するために必要となる証明書を安全に管理するために、シークレット ストアと呼ばれる内部サービスを使っています。この内部管理サービスが、システム内のプラットフォーム証明書、およびお客様の証明書の格納、配布、更新を自動化します。この内部監視サービスが、システム内の証明書の処理を自動化しています。これにより、コンプライアンスとセキュリティのため、担当者はシークレットへの直接的なアクセスを持っていません。

根本原因分析

Windows Azure ストレージは、各BLOB、テーブル、キューに対して、お客様データの送信トラフィックを保護するために、専用のSecure Socket Layer (SSL) 証明書を利用しています。証明書は、お客様アカウント (例: myaccount.blob.core.windows.net) をカバーする全てのサブドメインに対する、HTTPSを介したトラフィックの暗号化を可能にします。内部および外部のサービスは、ストレージ システムとの間の双方向のトラフィックを暗号化するために、これらの証明書を利用します。証明書はシークレット ストアに格納されており、ファブリック コントローラーによってサービスが配置される際に、各 Windows Azure ストレージ ノードのローカルに格納されます。すべての地域およびスタンプで、これらの証明書は同じです。

先週の時点で有効化されていた証明書の有効期限は、以下の通りです。

  • *.blob.core.windows.net    2013/2/22(金) 12:29:53 PST [2/23 05:29:53 JST]
  • *.queue.core.windows.net   2013/2/22(金) 12:31:22 PST [2/23 05:31:22 JST]
  • *.table.core.windows.net   2013/2/22(金) 12:32:52 PST [2/23 05:32:52 JST]

証明書の有効期限に達すると、証明書は無効化され、HTTPSを使っているストレージ サーバーとの接続を拒否されるようになりました。しかし、HTTPトランザクションについては、使用可能な状態にありました。

証明書の有効期限切れがお客様に直接の影響を与えましたが、これらの証明書を維持し監視する手順における問題が、今回の根本原因です。加えて、証明書がすべての地域で同一であり、それらの有効期限が時間的に近かったため、証明書がストレージ システムの単一障害点となりました。

ストレージ サービスの証明書が更新されなかった詳細

シークレット ストアの通常の運用として、毎週、管理対象の証明書をスキャンし、有効期限の180日前にチームに警告を通知します。その後、シークレットストアは証明書を所有するチームに対して、通知を送ります。チームが通知を受けた際に証明書を更新し、更新された証明書を、配置がスケジュールされたサービスの新しいビルドに含めたのち、シークレット ストアのデータベース内の証明書をアップデートします。このプロセスは、定期的にWindows Azureで提供されている多くのサービスで月に数百回行われています。

今回のケースでは、シークレット ストア サービスから、Windows Azureストレージ サービス チームに対して、前述のSSL証明書の有効期限が切れる旨の通知が行われました。2013年1月7日に、シークレット ストア内の3つの証明書を更新し、それらをストレージ サービスの次期リリースに追加しました。しかし、ストレージ サービスの本リリースの設定に 「証明書更新のためのリリース (緊急度高)」 としてのフラグ設定が不足していました。その後、より高い優先度のフラグがついたリリース対応のため、時間的に重要性の高い証明書の更新を含んだ今回のストレージ サービスのリリースは延期され、証明書の有効期限切れまでに配置が行われませんでした。加えて、シークレット ストア内の証明書はすでに更新されていたため、チームに追加の警告は行われず、これが警告システムにおける動作に空白を生んでしまいました。

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

今回の問題は、通常の監視によって12:44 PST [2/23 05:44 JST] に検知され、期限切れ証明書が原因であると特定されました。13:15 PST [2/23 06:15 JST] までに、エンジニアリング チームが問題の優先度を決定し、サービスを復旧するための最速のパスを決定するため複数の作業の流れを確立しました。

通常の運用では、ファブリック コントローラーが、各ノードを (「ゴール状態」と呼ばれる) 望ましい状態に維持します。サービスの「サービス定義」で、配置の際の望ましい状態が定義されており、それによって、ファブリック コントローラーが配置を構成するノード (サーバー) のゴール状態を決定します。サービス定義は、ロール インスタンス (それらのエンドポイント、構成、障害・アップデート ドメイン)、および、コード、Virtual Hard Disk (VHD)名、証明書の拇印などの項目への参照を含んでいます。

通常の運用では、サービスは新しい証明書を含むようにビルドを更新し、それから、ファブリック コントローラーが、体系的にアップデート ドメイン毎にすべてのノードでサービスを配置します。このプロセスは、外部のお客様にシームレスなアップデートを提供し、公開されたService Level Agreement (SLA)を順守する形でソフトウェアを更新するために、設計されています。この作業の一部は並行して実行されますが、世界規模のサービスを更新するため多くの時間を要します。

今回のHTTPSサービス中断の間、データにアクセスするためにHTTPを利用しているお客様では、Windows Azure ストレージ サービスは引き続き正常に稼働しており、一時的にHTTPに移行することでHTTPSの問題を迅速に軽減されたお客様もいらっしゃいました。サービスの復旧中も、HTTPを利用しているお客様に影響が及ばないよう細心の注意を払いました。

HTTPSサービスを復旧させるためのいくつかの選択肢を検討した結果、2つのアプローチを選択しました。1) 「各ストレージ サービスのノードでの証明書の更新」、および 2) 「ストレージサービスの更新の完了」です。最初のアプローチは、可能な限り迅速にお客様のサービスを復旧するために最適なものです。

1) 証明書の更新

開発チームが、この修復アプローチを検証しサービスを復旧するために、証明書を更新するために必要となる手動の手順について検討しました。ファブリック コントローラーがノードを「ゴール状態」に戻そうとしてしまうために、このプロセスは複雑なものになりました。18:22 PST [2/23 11:22 JST] までに、証明書を問題なく更新するためのプロセスを開発し、検証しました。過去の障害で学んだ重要なことは、他のサービスに影響を与える複雑な状況や2次障害を防ぐために、前もって修正を十分にテストして検証するための時間を取ることでした。修正のテスト中、運用環境での検証の前に、いくつかの問題を発見し、それらを修正しました。

自動化された更新プロセスの検証後、19:20 PST [2/23 12:20 JST] に米国西部データセンターのストレージ ノードに適用を開始し、20:50 PST [2/23 13:50 JST] に問題なくサービスが復旧しました。続いて、世界中のすべてのストレージ ノードに対して展開しました。22:45 PST [2/23 15:45 JST] にこのプロセスが完了し、大部分のお客様のHTTPSサービスを復旧しました。追加の監視と検証を行い、2月23日午前00:09 PST [17:09 JST]にダッシュボードをグリーン (正常) に変更しました。

2) 更新の完了

証明書の更新と並行して、更新された証明書を含むストレージ サービスの完全な更新を計画し、世界規模で展開しました。この更新によって、すべてのストレージ ノードが最終的な正しい「ゴール状態」になり、システムが一定した正常状態にあることを確認しました。2月22日午後23:00 PST [2/23 16:00 JST] からこの作業を開始し、2月23 日午後19:59 PST [2/24 12:59 JST] に終了し、設計されている通り、この作業がお客様の可用性SLAに影響を与えることはありませんでした。

サービスの改善

問題の発生後、私たちは常に時間をとって、今回の問題と、エンジニアリング、運用、コミュニケーションを改善する方法について分析を実施します。できるだけ多くのことを学ぶために、根本原因分析を行い、お客様のために我々のプラットフォームの信頼性を改善するべく、問題のすべての観点から分析を実施します。

この分析作業は、4つの主要領域で構成されており、問題のライフサイクル、およびそれに先行するエンジニアリング プロセスのそれぞれの部分に対して焦点を当てています。

  • 検知 – どのように問題を迅速に表面化し、復旧を優先順位付けするか
  • 復旧 – どのように復旧時間を削減し、お客様への影響を削減するか
  • 回避 – どのようにシステムが障害を回避し、隔離し、復旧するか
  • 対応 – 問題発生時にどのように私たちのお客様をサポートするか

検知

  • 運用環境で証明書の期限切れが起きないことを保証するために、シークレット ストアだけでなく運用環境のエンドポイントも含むように、証明書期限切れの監視範囲を拡張します。

復旧

  • 復旧プロセスは正確に機能したものの、配置メカニズムの性能や信頼性の改善を継続します。
  • 重要な証明書の更新を行うための特別なメカニズムを導入し、これらメカニズムを定期的に試行します。これにより、このような障害に対してより迅速な対応ができるようになります。

回避

  • 運用環境に配置されている、期限切れになりつつある証明書の検知を改善します。3か月以内に期限切れとなる運用環境の証明書に対して運用イシンシデントを作成し、サービスに影響をあたえうる事故と同様に扱って追跡します。
  • 証明書更新を含んでいるサービスのビルドを追跡し正しく優先順位付けするように、関連する手動プロセスを自動化します。早速、証明書に関連するすべての手動プロセスを検証しました。
  • 期限切れの見落としが広範囲な同時発生事故にならないよう、証明書を調査し、サービス、地域、時間による証明書の分割機会を探します。システムの見直しを継続し、単一障害点に対処していきます。

対応

  • Windows Azureサービス ダッシュボードの複数レベルのフェールオーバー手順は想定どおりに機能し、障害期間中は59の進捗報告がされ、お客様に対して重大な更新を提供しました。ただし、問題や更新に対する次回の情報提供のより正確な見込み時刻（ETA）を提供できるよう、引き続き改善していきます。
  • 我々の把握している情報をリアルタイムにWindows Azure ダッシュボードに掲載することで、お客様とのコミュニケーションの改善に努めてまいります。

サービスクレジット

今回のサービス中断の影響を受けたお客様に、多大なるご迷惑をおかけしたことの重大性を理解しています。今回の事故の規模と期間を考慮し、影響を受けたお客様には自主的にSLAクレジットを提供させていただきます。クレジットは、影響を受けた全てのサービスを対象にします。サービス停止時にお客様が次のサービスを実行していた場合は、影響を受けた請求期間のこれらのサービスに関連するご利用料金に対して 25% のサービス クレジットを発行します。

  • ストレージ
  • モバイル サービス
  • サービス バス
  • メディア サービスWeb サイト

 

また、影響を受けたお客様には、請求期間のすべてのデータ転送使用料金に対しても 、25% のクレジットを発行します。ご不明な点がございましたら、サポートまでお問い合わせください。

結論

Windows Azureチームは、上記に報告させていただいた調査結果を継続して見直し、引き続きサービス向上に必要な手段を講じてまいります。この中断がお客様に影響を与えたことを心からの後悔をもってお詫び申し上げます。お客様に可用性の高いサービスを提供できるよう、引き続き最大限の努力をさせて頂きます。