ブラジルで発生したMicrosoft Azure障害の原因はタイプミス

Azure DevOpsが10時間以上停止

ブラジルのMicrosoft Azure DevOpsで発生した障害は、アップデートコードのタイプミスが原因でした。

5月24日（水）、Azure SQL Serverが誤って削除された後、Microsoft Azure DevOpsが12:10～22:31（UTC）にオフラインとなりました。

ステータスアップデートの報告で、MicrosoftのプリンシパルソフトウェアエンジニアリングマネージャーのEric Mattinglyは次のように述べています。「スプリント222では、非推奨のMicrosoft.Azure.Management.パッケージを、サポートされているAzure.ResourceManager.NuGetパッケージに置き換えるためにコードベースのアップグレードを行いました。NuGetパッケージに置き換えました。」

「これは、APIコールを交換する機械的な変更の大規模なプルリクエストにつながりました。このプルリクエストの中には、スナップショット削除ジョブのタイポバグが隠されており、Azure SQL Databaseを削除するコールを、データベースをホストするAzure SQL Serverを削除するものにすり替えていました。」

DevOpsエンジニアは、問題の探求や改善のテストのために定期的にデータベースのスナップショットを取得し、毎日実行されて古いスナップショットを削除するバックグラウンドシステムに依存しています。

Sprint 222は、当初は問題なく内部で稼働していましたが、顧客環境に展開した際に、削除バグを誘発するほど古いスナップショット・データベースにアクセスすることになりました。

データベースではなくサーバーを削除してしまったため、このコードは、スケールユニットの17個の本番データベースをすべて削除してしまい、顧客からのリクエストを処理できなくなりました。同社によると、この障害によるデータの損失はなかったといいます。

Azureは20分以内にこの問題に気づいたにもかかわらず、問題の解決には10時間以上かかったようです。Mattingly氏によると、これはAzureのエンジニアが問題解決にあたったことや、Geo-zone-redundantバックアップが利用可能になる前にデータベースが作成されたため、一部のデータベースをペアリージョンにコピーする必要があり、数時間かかったことが一因といわれています。

Mattingly氏によると、遅延の最終的な原因は、Azureのサーバーに関する一連の問題の結果であり、w3wpプロセスが繰り返し実行され、そのたびに約90分かかるウォームアップタスクを実行したため、Webサーバーのヘルスプローブが失敗したことでした。

「このプロセスは、すべてのWebサーバーで時間をずらして実行されるため、それが終わる頃には、ロードバランサーに戻った1つか2つのサーバーだけが、顧客のトラフィックを受け持つようになっていました。そして、そのサーバーが過負荷になり、また同じことが繰り返されました。障害の終盤には、すべてのWebサーバーがウォームアップしてロードバランサーに正常に入るように、リソース利用機能でスケールユニットへのトラフィックをすべてブロックしました。その結果、ユーザーには速度制限と使用量のエラーが発生しました。すべてのデータベースが正常な状態になった後、徐々にユーザーのブロックを解除し、お客様のトラフィックを通常レベルまで引き上げました」とMattinglyは述べています。

マイクロソフトは、今後このような事態が発生しないよう、いくつかの調整を実施しました。

今年1月、マイクロソフトはMS 365、Outlook、GitHub、Teamsなどに影響を及ぼす広範囲な障害に見舞われました。この障害は5時間続き、最終的には広域ネットワーク（WAN）ルーターのIP変更によって解明されました。

この記事は海外Data Centre Dynamics発の記事をData Center Cafeが日本向けに抄訳したものです。