[更新履歴]
- 7/12 10:45 (日本時間) Post Incident Review (PIR) の「どのように対応したのか」を一部修正しました。
- Azure Service Health を通じた最初の通知の時間に誤りがあり、2023 年 7 月 6 日 23:19 UTC (2023 年 7 月 7 日 08:19 JST) に変更しました。
- 7/11 15:45 (日本時間) Post Incident Review (PIR) の抄訳を追記いたしました。
- 7/10 10:00 (日本時間) ブログ公開
こんにちは、Azure Monitoring サポート チームの横山です。
7/7 に発生した障害 XMGF-5Z0 について記載いたします。
この度は弊社 Azure の障害によりご不便ご迷惑をおかけし、大変申し訳ございませんでした。
発生した事象と時間帯
事象の発生したリージョン
直接影響を受けたサービス
副次的に影響を受けたサービス
影響を受けなかったサービス
よくあるご質問
Post Incident Review (PIR) の抄訳
最後に
発生した事象と時間帯
日本時間 7/7 8:15 - 18:00 の間、Azure Monitor 関連サービスにおけるデータの取り込みに欠損ならびに遅延が発生いたしました。
具体的には、問題のある構成により過剰な数の処理が発生しいたしました。これにより、ログの取り込みを行う Azure 基盤側のサービスが高負荷状態に陥り、内部で利用する認証情報の取得に失敗する事象が発生いたしました。
Azure 基盤側のサーバー増強を行い、滞留していた処理と新規の処理を適切に処理できるよう対処いたしました。
根本原因ならびに今後の恒久対策については現在も弊社開発にて調査、検討中です。(7/10 10:00 (日本時間) 現在)
なお、最新の状況は以下よりご確認いただけます。
https://app.azure.com/h/XMGF-5Z0/ (Azure ポータル)
https://azure.status.microsoft/ja-jp/status/history/ (Azure の状態ページ)
発生したリージョン
東日本、西日本を含む以下のリージョンで事象が発生いたしました。
Global; Australia Central; Australia Central 2; Australia East; Australia Southeast; Brazil South; Brazil Southeast; Canada Central; Canada East; Central India; Central US; Central US EUAP; East Asia; East US; East US 2; East US 2 EUAP; France Central; France South; Germany North; Germany West Central; Japan East; Japan West; Jio India Central; Jio India West; Korea Central; Korea South; North Central US; North Europe; Norway East; Norway West; Qatar Central; South Africa North; South Africa West; South Central US; South India; Southeast Asia; Sweden Central; Sweden South; Switzerland North; Switzerland West; UK South; UK West; West Central US; West Europe; West India; West US; West US 2; West US 3
直接影響を受けたサービス
- Log Analytics エージェント、Azure Monitor エージェント、Container Insights、データ コレクタ API、ログ インジェスト API を利用した Log Analytics ワークスペースへのデータ取り込み
- Microsoft Sentinel コネクタを利用した Log Log Analytics ワークスペースへのデータ取り込み
- Application Insights (ワークスペース ベース) へのデータ取り込み
- リソースの診断設定を利用した Log Analytics ワークスペース、ストレージ アカウント、イベント ハブへのデータ取り込み
副次的に影響を受けたサービス
- Log Analytics ワークスペースへのクエリを利用したログ アラート ルール
- Log Analytics ワークスペースをスコープとしたメトリック アラート ルール
- Log Analytics ワークスペースからストレージ アカウント、イベント ハブへのデータ エクスポート
影響を受けなかったサービス
- Log Analytics ワークスペース、Sentinel、Application Insights (ワークスペース ベース) に取り込まれたデータの参照
- Application Insights (クラシック) へのデータ取り込み
- Windows Azure Diagnostics (WAD)、Linux Azure Diagnostics (LAD) を利用したストレージ アカウントへのデータ取り込み
- 各種リソースのプラットフォーム メトリック
- プラットフォーム メトリックを利用したメトリック アラート ルール
よくあるご質問
Q. 影響を受けたサブスクリプションの確認方法はあるか？
A. 以下に追跡 ID: XMGF-5Z0 が表示される場合、影響を受けております。
[Azure ポータル] - [サービス正常性] - [サービス正常性の履歴]
Q. データの欠損はあるか？
A. はい、今回の障害によりデータの欠損は発生していた可能性がございます。
Q. データの欠損を確認する方法はあるか？
A. もし、取り込み元のログ (イベント ログや Syslog) をお客様にて確認できる場合は、対象の取り込み先のデータと比較することで可能です。残念ながら、マイクロソフトから欠損したデータを確認することはできません。
Q. 欠損したデータの復旧は可能か？
A. いいえ、欠損したデータの復旧を行うことはできません。
Q. 今回の障害による返金はあるか？
A. いいえ、Azure Monitor 各種サービスへのデータ取り込みに関しては SLA (Service Level Agreements) が定められていないため、今回の障害による返金はございません。
Post Incident Review (PIR) の抄訳
下記に公開されている PIR の抄訳を記載いたしました。
https://azure.status.microsoft/ja-jp/status/history/ (Azure の状態の履歴)
何が起こったのか
2023 年 7 月 6 日の UTC 23:15 から 7 月 7 日の UTC 9:00 (日本時間 2023 年 7 月 7 日 08:15 から 7 月 7 日 18:00) まで、Azure Monitor Log Analytics と Microsoft Sentinel の一部のデータの取り込みが失敗しました。
さらに、診断設定を介して収集したプラットフォーム ログは、Log Analytics、ストレージ、Event Hub、マーケットプレイスなどの顧客向けの宛先に一部のデータをルーティング (データを送信) することに失敗しました。
これらの失敗は、Microsoft 内のサービスのデプロイによるものであり、予想よりもはるかに高い呼び出し量を引き起こすバグが原因で、テレメトリ コントロール プレーンのリソースを使い果たしました。これによりすべてのリージョンの顧客が影響を受けました。
Sentinel 内の Security Operations Center (SOC) の機能、つまり、ハンティング クエリ、カスタム クエリを含むブック、削除されたログ データを含む範囲のインパクト テーブルをクエリしたノートブックが部分的または空の結果を返す可能性がありました。
Event テーブルや SecurityEvent テーブルが影響を受けた場合、相関するインシデントの調査は部分的または空の結果を示す可能性がありました。
残念ながら、この問題はお客様の Azure リソースの一つ以上に影響を与えました。
私たちはこの Post Incident Review (PIR) を提供して、何が間違っていたのか、どのように対応したのか、Microsoft が何を学び、どのように改善しているのかをまとめます。
何がうまくいかなかったのか、そしてその理由は
2023 年 7 月 3 日 UTC に Azure Container Apps サービスのコード デプロイメントが通常の Safe Deployment Practices (SDP) を介して開始され、最初に Azure の canary とステージング リージョンに展開されました。
このバージョンには、サービスが正常に起動しないようになってしまう、誤った構成が含まれていました。この誤った構成のため、サービスのブートストラップ コードは例外をスローし、自動的に再起動されました。これにより、ブートストラップ サービスが 5 から 10 秒ごとに再起動するループに陥りました。
ブートストラップ サービスが再起動されるたびに、それは構成情報をテレメトリ エージェントに提供し、サービス ホストに構成情報をインストールしました。
構成情報がテレメトリ ホストに送信されるたびに、テレメトリ ホストはこれを設定の変更と解釈し、したがって自分たちも現在のプロセスを終了して自動的に再起動しました。
アプリケーション ホストごとに、エージェント テレメトリ ホストの三つの別々のインスタンスが、5 から 10 秒ごとに再起動を繰り返していました。
テレメトリ エージェントの起動ごとに、エージェントはすぐにテレメトリ コントロール プレーンに接続し、テレメトリ構成の最新バージョンをダウンロードしました。
通常、このアクションはエージェント上でキャッシュされる設定であるため、数日に一度行うものです。
しかし、Container Apps サービスのデプロイメントが進行するにつれて、数百のホストがテレメトリ コントロール プレーンから 5 秒から 10 秒ごとにスタートアップ構成情報を要求するテレメトリ エージェントを持つようになりました。
Container Apps チームは、2023 年 7 月 6 日 UTC にデプロイメントの欠陥を検知し、本番環境にリリースされる前に当初予定していたデプロイメントを停止しました。
そして誤った構成を修正するために canary とステージング リージョンでサービスの新しいデプロイメントを開始しました。
しかし、誤った構成情報のビルドを受け取ったサービスからの各リクエストが集約された結果、テレメトリ コントロール プレーンのリソースを使い果たしました。
テレメトリ コントロール プレーンはグローバル サービスであり、Azure の全パブリック リージョンで稼働しているサービスに使用されています。
テレメトリ コントロール プレーンのリソースが枯渇すると、テレメトリの取り込みに関与する他のサービス、たとえば ingestion front door や内部でサービス間のデータをルーティングするパイプライン サービスなどが、テレメトリ コントロール プレーンに対する操作が拒否されたりタイムアウトしたりするようになり、失敗を始めました。
テレメトリ コントロール プレーンを単一の障害点とする設計は既知のリスクであり、その設計を見直すための改善プロジェクトが Azure Monitor において既に計画されていました。
しかしながら、その変更が行われる前にこの問題が発生しました。
どのように対応したのか
2023 年 7 月 6 日 12:30 UTC (2023 年 7 月 6 日 21:30 JST) までにゆっくりとテレメトリ コントロール プレーンへの影響が増大し、それが問題を引き起こすまで検出されませんでした。
問題が検出されたとき、テレメトリ コントロール プレーンへの負荷を発生させている原因は不明でしたが、私たちはテレメトリ コントロール プレーンに対する追加の負荷が発生していると疑い、以下のアクションを実行しました。
2023 年 7 月 6 日 14:53 UTC (2023 年 7 月 6 日 23:53 JST) - 内部でインシデント ブリッジ (インシデント対応チーム) が作成されました
2023 年 7 月 6 日 15:56 UTC (2023 年 7 月 7 日 00:56 JST) - ガベージ コレクター サービスの約 500 インスタンスを削除し、テレメトリ コントロール プレーンへの負荷を軽減しました
2023 年 7 月 6 日 16:09 UTC (2023 年 7 月 7 日 01:09 JST) - Node Diagnostics サーバーの削除を開始し、テレメトリ コントロール プレーンへの負荷を軽減しました。サーバーを削除するこの処置はその後 10 時間にわたって続けられました。
2023 年 7 月 6 日 20:20 UTC (2023 年 7 月 7 日 05:20 JST) - 異常に高いトラフィックの原因が特定され、関連するチームが支援に呼び出されました。
2023 年 7 月 6 日 23:00 UTC (2023 年 7 月 7 日 08:00 JST) - 異常なトラフィックがテレメトリ コントロール プレーンにヒットするのを防ぐために、IP アドレス ブロックが展開されました。
2023 年 7 月 6 日 23:15 UTC (2023 年 7 月 7 日 08:15 JST) - キャッシュ データが失効したため、お客様への影響が始まりました。
2023 年 7 月 6 日 23:19 UTC (2023 年 7 月 7 日 08:19 JST) - 影響を受けたサブスクリプションを持つお客様に対して、最初の通知を Azure Service Health を通じて送信しました (追跡 ID XMGF-5Z0 で送信)。
2023 年 7 月 7 日 01:30 UTC (2023 年 7 月 7 日 10:30 JST) - 追加の負荷を処理するためにテレメトリ コントロール プレーンに 3 つの追加クラスターが追加され、既存のクラスターの再起動を開始し、バックログの接続をクリアしました。
2023 年 7 月 7 日 02:45 UTC (2023 年 7 月 7 日 11:45 JST) - テレメトリ コントロール プレーンにさらに 3 つのクラスターが追加されました。
2023 年 7 月 7 日 05:21 UTC (2023 年 7 月 7 日 14:21 JST) - より詳細なお客様へのアップデート通知が送信されました。
2023 年 7 月 7 日 09:00 UTC (2023 年 7 月 7 日 18:00 JST) - コントロール プレーン API に対するコール エラー レートとコール レイテンシが通常のレベルで安定したため、インシデントの解消が宣言されました。
このようなインシデントをどのようにして減らすか、または影響を軽減するか
私たちはお客様の信頼を獲得し、またただ正しいことを言うだけでなく、正しいことを実践することで維持されるべきだと理解しています。
データ保持は、すべてのクラウド サービスを担当する各エンジニアを含む、Microsoft クラウドの基本的な責任です。私たちはこのインシデントから学び、以下の改善に取り組んでいます。
- 私たちは、テレメトリ コントロール プレーンのサービスが追加の容量で稼働していることを確認しました。 (完了)
- API 呼び出しの中で異常な失敗パターンを示す特定のメトリックについて、追加のアラートを作成します。 (予定完了 : 2023 年 7 月)
- コントロール プレーンに新たなポジティブ キャッシングとネガティブ キャッシングを追加することで、バッキング ストアへの負荷を軽減する予定です。 (予定完了 : 2023 年 9 月)
- コア テレメトリ コントロール プレーン API に追加のスロットリングとサーキット ブレーカー パターンを導入します。 (予定完了 : 2023 年 9 月)
- 長期的には、テレメトリ コントロール プレーンを使用して内部向けサービスと外部向けサービスを分離します。 (予定完了 : 2023 年 12 月)
このようなインシデントをどのようにして影響を軽減することができますか
お客様はこのインシデントの影響を防止することはできませんでした。また、インシデント発生中の影響を緩和することもできませんでした。
一般的には、Azure の Well-Architected フレームワークとその対話的 Well-Architected レビューの指針を用いて、アプリケーションの信頼性を評価することを考慮してみてください :
https://learn.microsoft.com/ja-JP/azure/well-architected/resiliency/
最後に、組織内の適切な人々が将来のサービス問題について通知を受けるようにすることを検討してください。
これは Azure サービス正常性のアラートを設定することで行えます。これらのアラートは、電子メール、SMS、プッシュ通知、Web フックなどをトリガーすることができます : https://aka.ms/ash-alerts
どのようにしてインシデント レポートをより有用にすることができますか
この PIR を評価し、3 問の調査を使用してフィードバックを提供することができます : https://aka.ms/AzPIR/XMGF-5Z0
最後に
もし、本ブログに記載の内容以外について追加のご質問やご不明点がございましたら、大変お手数ではございますが、事象を受けたサブスクリプションからお問い合わせをご発行ください。
なお、以下についてはお問い合わせを新規ご発行いただいても回答いたしかねますので、予めご了承ください。
- XMGF-5Z0 に記載されている障害の詳細、ならびに、Azure Monitor に関する内部実装
- 根本原因や恒久対策について (XMGF-5Z0 を介して開発からアップデートがございますので、そちらをお待ち下さい。弊ブログも開発からの情報公開後、アップデートいたします。)
改めまして、この度は弊社 Azure 障害によりご不便ご迷惑をおかけし、大変申し訳ございませんでした。
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。