ThousandEyes は、世界のインターネット上の数千に及ぶサービスとネットワークの到達可能性とパフォーマンスを積極的に監視し、そのデータを使用して障害やその他のインシデントを分析しています。2024 年 11 月 25 日に発生した Microsoft の障害に関する以下の分析は、ThousandEyes の広範なモニタリングと、ThousandEyes のグローバル障害検出サービスである Internet Insights に基づいています。この分析で、この障害がどのように展開したかを紹介します。新しい情報を入手次第、追加していきます。
障害分析
11 月 25 日、ThousandEyes は Outlook Online を含む一部の Microsoft サービスに影響を及ぼした長時間にわたる障害を観測しました。この障害は断続的に現れ、主に 2 つのフェーズに分かれて発生したと見られます。当社にて症状を分析した結果、バックエンドの問題が根本原因である可能性が高いことがわかりました。後に Microsoft はその事実を認め、この問題は「1 つの変更によってサーバー経由で大量の再試行リクエストがルーティングされ、サービスの可用性に影響が及んだ」ことに起因していると述べました。
この障害は、次のようなことを ITOps チームに喚起しています。つまり、断続的な問題への対処のベストプラクティス、自社のベースラインパフォーマンスを把握することの重要性、障害の原因を診断する際に利用可能なすべての手がかりを総合的に考慮することが重要である理由です。
これらの重要なポイントについてはこのブログ記事の後半で説明しますが、まず Microsoft の障害がどのように展開したかを詳しく見てみましょう。
Microsoft の障害フェーズ 1：断続的な問題とバックエンドの問題
午前 2 時（UTC）頃に最初に観測されたこの障害は当初、断続的に発生し、影響は少数のリージョンに限定されているかに見えました。この障害はタイムアウトエラー、解決の失敗、またはバックエンドサービスやシステムが利用できないことを示す HTTP 503 ステータスコードなどの症状として現れました。
注目すべき点は、エッジサーバーへの経路に、タイムアウトの原因になり得る有害なネットワーク状況（エッジでのパケットロス率の増加など）が見られなかったことです。これらの兆候を総合的に見ると、バックエンドサービスに影響する問題が原因である可能性が最も高いと考えられます。言い換えると、サービスが応答しなかった間の受信側エラーとサーバー側ステータスコードは、フロントエンドサービスには到達可能だったものの、それに続くコンポーネント、オブジェクト、その他のサービスへのリクエストが部分的に受け入れられなかったことを示していました。この問題は断続的に発生していたため、エンドユーザーには明確に認識されず、頻繁な応答速度の低下として現れました。
Microsoft の障害フェーズ 2：パケットロスが増加し、影響を受けたリージョンも増加
この問題は当初、午前 3 時 5 分（UTC）頃に解消したと思われましたが、午前 7 時（UTC）頃にタイムアウトやサービス利用不能のエラーとして再び発生しました。2 回目の障害は 1 回目よりも多くのリージョンに影響を与えたと見られ、影響を受けたサービス数は周期的なパターン、つまり影響を受けたサーバー数の増減を示しました。これはバックエンドのリクエスト負荷の問題を示している可能性があります。
2 回目の障害が進むと、ThousandEyes は、Microsoft ネットワークのエッジで発生するパケットロスに加え、タイムアウトおよびサービス利用不能のエラーが増加していることを観測しました。観測されたロス率は、Microsoft ネットワークの出口での発生については一定でしたが、前回のサービス中断時と比較して増加していました。ただし、この期間全体を通して、すべての経路とテストで一貫して 100% のロスは発生しませんでした。このロス率の増加は、サービスへの接続時に輻輳が悪化したことと、バックエンドサービスへの到達または接続が不能になったことが重なったこと原因であると考えられます。
午前 9 時（UTC）頃、Microsoft は Exchange Online へのアクセスと Microsoft Teams カレンダーに影響する問題を認めました。同社は、午後 2 時（UTC）頃に 修正を開始したことを発表、この作業には「不健全な状態にある一部のマシンを手動で再起動する」ことも含まれていました。その後まもなく、報告されたエラー数が大幅に増加し、さらに多くのサーバーが影響を受けました。午後 5 時 25 分（UTC）の Microsoft の 報告では、「影響を受けるユーザーの大半で、再起動の進捗が予想よりも遅れている」とのことでした。
Microsoft はその後、根本原因についてさらに詳しい情報を提供し、この問題は「1 つの変更によってサーバー経由で大量の再試行リクエストがルーティングされ、サービスの可用性に影響を与えたことに起因する」と説明しました。
これらの問題に対処するため、Microsoft は最適化を実施し、インフラストラクチャの処理能力の強化を図りました。これらの調整により、サービスは徐々に回復したと思われました。この発表は ThousandEyes の観察結果と一致しています。ThousandEyes には、サービスが応答しなかったタイムアウト関連のエラーや、HTTP 503（サービス利用不能）および 404 エラーが記録されていました。これらのエラーは、フロントサーバーとの通信は確立されているものの、サーバーが要求されたリソースを見つけられなかった、またはリソースに到達できなかったことを意味します。
教訓と結論
Microsoft で発生したような断続的な問題は、パフォーマンスの低下や遅延として現れることが多く、特定するのが困難な場合があります。ITOps チームが最適なベースラインパフォーマンスを明確に把握していれば、障害の兆候となり得るパフォーマンスの逸脱をより容易に検出できるようになります。また、障害を引き起こすのに多くの要素は必要ありません。たった 1 つのコンポーネント、あるいは 1 つの機能の障害や性能の低下によって、サービスデリバリーチェーン全体が停止してしまう可能性があります。
サービス中断が発生した場合には、その原因を効率的に特定することがきわめて重要です。そして、このプロセスで重要なステップは、問題の原因ではないものを特定することです。この知識を、アクセス可能な他のデータポイントと組み合わせることで、障害の原因をより明確に理解できるようになります。それにより次のステップを迅速に決定し、ユーザーとの効果的なコミュニケーションを図ることができます。
[2024 年 11 月 25 日、午後 2 時 PT]
ThousandEyes は Outlook Online を含む一部の Microsoft サービスに影響を及ぼした長時間にわたる障害を観測しました。このインシデントは 11 月 25 日午前 2 時（UTC）頃より、断続的なタイムアウトおよびアプリケーションエラーとして始まりました。インシデントの範囲は、午前 7 時（UTC）頃、さらに午後 12 時 40 分（UTC）に再び拡大したと見られます。このインシデントの発生中、サーバーエラー、タイムアウト、パケットロスを含むさまざまな状況が観測されました。このインシデントは部分的には解消したと見られますが、ThousandEyes は、影響を受けたサーバーへのアクセスを試みる一部のユーザーで現在もこの問題を確認しています。
