2018 年 9 月 4 日に発生した VSTS のサービス停止に関する事後分析


執筆者: Visual Studio Team Services

このポストは、2018 9 10 日に投稿された Postmortem VSTS 4 September 2018 の翻訳です。

 

2018 9 4 日の VSTS サービス停止の事後分析

2018 9 4 ()VSTS (現在の名称は Azure DevOps) で大規模なサービス停止が発生し、米国中南部リージョン (VSTS をホストする全世界の 10 リージョンの 1 ) をホストとするお客様に影響がありました。また、サービス間の依存関係により、このサービス停止の影響が世界中のお客様に拡大しました。VSTS のサービス復旧には Azure データセンターの復旧が必要であったため、米国中南部リージョンの VSTS サービスがすべて復旧するまでに 21 時間以上を要しました。VSTS のサービス復旧後には、データベースがオフラインになるというインシデントも発生し、米国中南部リージョンで Release Management サービスが 2 時間ほど影響を受けました。また、Azure ストレージ アカウントの復元中にも断続的に障害が発生し、Git および Package Management のユーザーの一部に影響が出ました。

まず、影響のあったリージョンをホストとしているお客様には、長時間にわたって VSTS サービスが停止しご迷惑をおかけしましたことをお詫び申し上げます。また、世界中のお客様にも影響が及んでしまい、誠に申し訳ございませんでした。今回のインシデントはこれまでに例のないもので、マイクロソフトが 7 年間 VSTS を提供してきた中で最長のサービス停止となりました。まる 1 日、またはそれ以上にわたって生産性が失われることになったチームの皆様には、Twitter、メール、電話でご連絡を差し上げました。お客様の信頼にお応えできなかったことは誠に残念であり、重ねてお詫び申し上げます。

発生の経緯

今回のインシデントは、テキサス州南部の米国中南部データセンター付近で生じた落雷などを含む激しい嵐により発生しました。嵐による電圧低下が電力供給区域全体に拡大し、冷却システムにも波及しました。データやハードウェアの整合性確保を目的としたデータセンターの自動プロシージャが起動し、クリティカルなハードウェアで所定の電源停止プロセスが開始されました。その結果、米国中南部リージョンの VSTS サービスが停止しました。データセンターに対する影響の詳細については、Azure Status (英語) を参照してください。

米国中南部リージョンには、複数のスケール ユニット (SU) で複数の VSTS サービスがホストされています。2018 9 4 9 45 (UTC)/2018 9 4 18 45 (日本時間)、データセンターの電源停止プロセスにより、米国中南部リージョンの VSTS SU がすべて停止しました。

米国中南部リージョンでホストされていた VSTS 組織の他に、Marketplace など、このリージョンでホストされていた全世界の VSTS サービスの一部もこの影響を受けました。これにより、拡張機能 (VS 用や VS Code 用など) の取得不能、全体的な速度低下、ダッシュボード機能でのエラー、米国中南部リージョンに保存していたユーザー プロファイルへのアクセス不能などの現象が世界中で発生しました。

さらに、米国でホストされていた VSTS 組織では Release Management サービスと Package Management サービスが使用できなくなりました。Hosted macOS を使用したビルド/リリース パイプラインのキューでも障害が発生しました。この他、VSTS のステータス ページでは最新情報が表示されなくなりました。これは、このページが米国中南部リージョンのデータを使用していることと、最新情報をお客様にお伝えするための内部ツールを米国中南部リージョンでホストしていることが原因です。

Azure データセンターの復旧後、VSTS のサービスも復旧に向かいました。ほぼすべてのサービスが自己回復しましたが、2 つのサービスは手動での再起動が必要でした。

サービスの回復後、Azure の復旧作業中に GitRelease ManagementPackage Management のユーザーの一部でも問題が発生しました。VSTS のインシデントは、2018 9 6 0 5 (UTC)/2018 9 6 9 5 (日本時間) に収束しました。

VSTS サービスが他のリージョンにフェールオーバーされなかった理由

私たちは、お客様のデータの損失だけは避けたいと考えています。マイクロソフトのデータ保護戦略 (英語) では、Azure SQL Database のポイントインタイム リストア (PITR) バックアップAzure の geo 冗長ストレージ (GRS) によって 2 つのリージョンにデータを保存することに重点を置いています。これにより、データ主権に関する要件を満たしながら、同一地域内にデータが複製されるようになります。GRS ストレージ アカウントへのフェールオーバーは、Azure Storage チームのみが決定します。仮に今回のサービス停止中に Azure Storage でフェールオーバーが実行されていたとしても、データ損失が発生するくらいならば、VSTS チームは復旧まで待機することを選んだでしょう。

Azure Storage には、サービス停止時の対処方法として、復旧を待機するか、または読み取り専用のセカンダリ コピーのデータにアクセスするかの 2 つの選択肢が用意されています。読み取り専用ストレージを使用した場合、コードのチェックインやビルド出力の保存ができなくなるため (その結果デプロイできなくなるため)Git TFVC、ビルドなどの重要なサービスは使用できなくなります。また、バックアップ データベースにフェールオーバーした場合、バックアップが復元されると、バックアップ時の時間差によりデータ損失が発生してしまいます。

現在マイクロソフトでは、データセンターでの障害発生時の対応を改善するために、可用性ゾーンの使用を第一に進めています。そのうえで、非同期レプリケーションが実現性を調査しています。

同一リージョン内の可用性ゾーン

リージョン内の 1 つまたは複数のデータセンターに影響を及ぼす障害はたくさんありますが、それらは Azure に最近導入された可用性ゾーンで対応できます。可用性ゾーンは 2018 3 月に一部のリージョンで一般提供を開始し、現在では 5 つのリージョンで提供しています。そのドキュメントに記載されている説明を抜粋してご紹介します。

可用性ゾーンとは高可用性を提供するサービスで、アプリケーションとデータをデータセンターの障害から保護します。可用性ゾーンは Azure リージョン内の一意の物理的な場所であり、それぞれのゾーンは独立した電源、冷却手段、ネットワークを備え、1 つ以上のデータセンターで構成されます。回復性を確保するために、可用性ゾーンが有効なリージョンすべてに個別のゾーンが最低 3 つ存在しています。可用性ゾーンはリージョン内で物理的に分離されているため、データセンターで障害が発生した場合でもアプリケーションとデータが保護されます。ゾーン冗長サービスによって複数の可用性ゾーンにアプリケーションとデータが複製されるため、単一障害点への対策となります。

可用性ゾーンは、今回米国中南部リージョンが影響を受けた落雷などのインシデントからの保護を目的として設計されています。データセンターが互いに近接しているため、待機時間の短さと高帯域幅の接続によって、1 つのリージョン内での同期レプリケーションを実現しています。たとえば、Azure SQL Database ゾーンをまたいでノードを展開できます。可用性ゾーンを使用すれば、リージョン全体でサービスが停止しない限り、そのリージョンの VSTS サービスは継続されます。

リージョン間での同期レプリケーション

リージョン間で同期レプリケーションを行うには、永続データ書き込みの呼び出しに対して応答を返す前に、両リージョンの永続データに変更をすべてコミットする必要があります。変更がコミットされたデータが両リージョンに確保され、フェールオーバーしてもデータ損失が発生しないため、一見するとこの手法は理想的なように思われます。

しかし、リージョン間の同期レプリケーションは、実際には容易ではありません。たとえば、米国中南部リージョンのペアは米国中北部リージョンですが、たとえ光の速さで通信しても、一方のデータセンターから他方のデータセンターに到達し元のデータセンターに応答が返されるまでには一定の時間を要します。ラウンド トリップの待ち時間は、書き込み処理のたびに積み上がっていきます。米国中南部リージョンと米国中北部リージョン間のラウンド トリップ時間は、約 70 ミリ秒です。一部の主要サービスにとってこれは長過ぎであり、さまざまな要因からマシンの速度低下やネットワーク障害につながります。異なる 2 つのリージョンそれぞれに一連のサービスが存在し、書き込みを行うたびに両方のサービスでデータが正常にコミットされて応答が返されなければその書き込みは成功しないため、速度低下や障害が発生する可能性は倍になります。そのため、可用性を犠牲にする (セカンダリへの書き込みのコミットを待機している間は処理を保留する) か、次善の策として非同期レプリケーションを行うしかありません。

リージョン間での非同期レプリケーション

すべての書き込みを両リージョンに常に同期的にコミットするという要件を緩和するとしたら、セカンダリ リージョンへのデータ書き込みを非同期で実行することになります。これは、同期書き込みに代わる次善の策です。非同期コピーを高速で実行できれば、通常の条件下では、プライマリとセカンダリに同時にデータが書き込まれる同期レプリケーションと実質的に同等の効果が得られます。

全体のまとめ

マイクロソフトは今後の計画として、可用性ゾーンを使用してリージョン内の障害に対応することにしており、VSTS で可用性ゾーンを使用できるようにするための作業を開始しました。可用性ゾーンは現在 5 つのリージョンでサポートされています。今後は提供地域が拡大される予定ですが、米国中南部リージョンを含め、VSTS サービスをホストしているリージョンの一部では可用性ゾーンがまだサポートされていません。サポートされている地域にサービスを移行する必要がありますが、それには時間がかかります。現時点で可用性ゾーンがサポートされていない地域については、データ主権の要件に準拠する必要があることから、VSTS サービスの移行は行いません。このため、これらの地域の VSTS サービスは、今回の米国中南部リージョンのようなインシデントが発生すると、サービスが停止する可能性があります。

速さが求められるサービスすべてにおいてリージョン間の同期レプリケーションを完全に実現し、フェールオーバーを実行してもデータ損失が一切発生しないようにすることは不可能です。マイクロソフトの目標は、優れたパフォーマンスと高可用性という相反する目的をバランスを取りながら両立させることです。

リージョン レベルで発生する障害への対応は難しい問題です。今のところ、リージョン間でのデータの非同期レプリケーションは実現性を調査している段階です。Azure SQL Database では、アクティブ geo レプリケーションを採用しています。Azure Storage では、すべての書き込み処理でプライマリ リージョンとセカンダリ リージョンの両方に非同期でデータを書き込んでおり、フェールオーバー時にはセカンダリ リージョンのセカンダリ コピーを使用できます。通常は Azure Storage の標準の SLA が適用されますが、GRS ではその SLA は適用されません。となれば、フェールオーバー時にコンピューティングなどのリソースをペアとなるデータセンターにプロビジョニングするか、または常にウォーム スタンバイ状態で待機させておくことが必要になります。

以上のことから、データ損失が発生するにしても、どのタイミングで他のリージョンにフェールオーバーするかという問題を解決する必要があります。基本的には、データ損失を許容していただくかどうかの選択をお客様に強いることは避けたいと考えています。多少のデータ損失が発生してでも大規模なチームの生産性を迅速に回復したいというお客様もいれば、復旧に長時間かかってもデータ損失がまったく発生しないようにしたいというお客様もいらっしゃいます。また、このような状況では、サービス停止がどの程度続くかについて詳細な情報を得られないまま意思決定を下さなければならないという問題もあります。復旧までの時間を正確に予測することは非常に困難であり、また楽観的な予想を立ててしまいがちです。

いずれにせよお客様のご要望にお応えするためには、サービスが停止した場合にそのリージョンの組織をフェールオーバーするかどうかをお客様にお選びいただけるようにするしかありません。マイクロソフトでは、そのような選択肢の提供方法について調査を開始しており、セカンダリが最新状態であるかを通知する方法や、プライマリ データセンターが復旧した場合に手動での調整が可能かどうかについても検討しています。その結果しだいで、リージョン間の非同期フェールオーバーを実装するかどうかが決まります。調査はまだ始まったばかりであり、今のところ実現性は不明です。

その他の問題

今回のインシデントで発生したその他の問題について、簡単に説明します。

影響の拡大: 米国中南部リージョンのサービスの一部は、他のリージョンの VSTS サービスに機能を提供しています。米国中南部リージョンの Release Management (RM) サービスは、米国全土の RM ユーザーのメイン ホストとなっています。Marketplace サービスは単一インスタンス サービスで、VSVSTSVS Code のユーザーに拡張機能を提供しています。先に述べたように、これらのサービスについては、可用性ゾーンをサポートするリージョンへの移行を進めてまいります。

パフォーマンスの低下: ユーザー プロファイルの提供を担当する「ユーザー サービス」というサービスがあり、それぞれのユーザーは世界各地に複数存在するユーザー サービス インスタンスのいずれか 1 つに割り当てられています。今回、インシデント発生中に米国中南部リージョンのユーザー サービスを呼び出すサービスの停止が遅れました。通常は、この呼び出しをラップしているサーキット ブレーカーが開いてすばやく停止し、グレースフル デグラデーションを適用したエクスペリエンスが提供されますが、あいにく URL パターンが異なることからユーザー サービス インスタンスの呼び出しすべてをこのブレーカーがラップしているため、失敗率が低すぎてブレーカーが開きませんでした (米国中南部リージョンへの呼び出しだけが失敗し、ほとんどの呼び出しは成功していました)。その結果、他のリージョンのお客様も、ユーザー プロファイルが米国中南部リージョンでホストされている場合は Web UI の速度が著しく低下しました。そこで、インシデント発生中のパフォーマンスに対する影響を排除するために、サーキット ブレーカーを手動で開き、すべてのユーザーのプロファイル エクスペリエンスを停止させました。現在マイクロソフトでは、このユーザー サービスの呼び出しに関連するサーキット ブレーカーの仕様を見直し、対象とする範囲が特定のインスタンスに限定されるよう変更しています。この他、ユーザー設定を取得する処理が過度に再試行されたことにより、インシデント発生中にユーザー エクスペリエンスに速度低下が見られました。

ダッシュボードのエラー: 拡張機能の URL を取得する Marketplace サービスへの重要度の低い呼び出しが原因となって、他のリージョンのユーザーのダッシュボードでエラーが発生しました。この部分はグレースフル デグラデーションでのテストが実施されていなかったため、ダッシュボードのフォールト挿入テストのスケジュールを組み、早急にテストを開始してまいります。

サービスのステータス表示が不正確に: 米国中南部リージョンの Azure Storage への依存のせいで、インシデント発生直後の数時間は、サービスのステータスを更新できませんでした。これを受けて、既に新しいサービス ステータス ポータルの構築に動いています。リージョン内でのサービス停止に対する回復性を向上させるだけでなく、サービス停止中の通信方法を改善し、お客様がご自身の組織のステータスをもっと容易に確認できるようにしてまいります。また、インシデントの初期に発生していた Azure AD の問題により、コミュニケーション ツールで使用される資格情報の取得にも問題が発生していました。

サービス開始時の問題: 復旧時に、サービスをホストしている仮想マシン (VM) の一部は実行されていましたが、受信負荷に十分に対応できませんでした。VM の正常性を監視する VssHealthAgent というプロセスを確認したところ、VM が正常ではないと判断されたため、ロード バランサーから 1 つずつ切り離して診断情報を収集し、再起動してロード バランサーに再度組み入れました。この一連の手順は、切り離す VM 1 回に 1 台のみ、メモリ ダンプの収集は 1 時間に 1 回以下と定められていますが、今回のインシデントですべての AT が長時間にわたって過負荷状態となったため、タイミングに関する問題が発生しました。これにより、ロード バランサーに VM が再び組み入れられた後すぐにメモリ ダンプ収集プロセスが再実行されました。このバグは既に修正が完了し、今回のようなパフォーマンス低下状態が継続している間にインスタンスがロード バランサーから切り離される回数が制限されるようになりました。この問題の影響は小規模なものでしたが、自動軽減策に固有の問題の一事例として記録されました。

今後のステップ

マイクロソフトでは今回のインシデントで得られた教訓を基に、次のような改善を行っています。

  1. 可用性ゾーンがサポートされている地域では、リージョン内でのデータセンターの障害に対する回復性を持たせるために、Azure 可用性ゾーンに対応しているリージョンにサービスを移行します。
  2. リージョン間での非同期レプリケーションが実現可能かどうかを検討します。
  3. マイクロソフト自身の組織を使用して、VSTS サービスのリージョン間でのフェールオーバーの訓練を定期的に実施します。
  4. 内部ツールの冗長性を強化し、複数リージョンで使用できるようにします。
  5. Marketplace への呼び出しの失敗がダッシュボードの利用不能につながるというダッシュボードの不具合を修正しました。
  6. サービス間の呼び出しのサーキット ブレーカーを見直し、対象範囲を是正します (ユーザー サービスの呼び出しの問題で発覚)
  7. 今回のインシデントで発覚した、現行のフォールト挿入テストの欠陥を見直します。

今回のインシデントにより非常に長い時間にわたってサービスが停止したことを改めてお詫び申し上げます。

今後ともマイクロソフトのサービスをご利用くださいますよう、よろしくお願い申し上げます。

Buck Hodges (@tfsbuck)

Azure DevOps 担当エンジニアリング ディレクター

 

Comments (0)

Skip to main content