タグ: afd

Microsoft Azureで大規模障害発生 ― Microsoft 365やXboxにも影響、原因は構成変更ミス

日本時間2025年10月30日午前1時頃からMicrosoft Azureで大規模な障害が発生しました。これにより、Microsoft Azure、Microsoft 365、Minecraft、XboxなどのMicrosoftが提供する製品やサービスだけでなく、Starbucks、costco、Krogerといった大手企業のシステムにも波及しました。

Microsoftの発表によると、「Azure Front Door（AFD）における誤った構成変更（inadvertent configuration change）」が原因とのことで、この設定変更が DNS ルーティングに影響を与え、Azure Portal や関連サービスにアクセス不能状態を引き起こしたものと見られています。

発生から対応までを時系列に並べると以下のようになります。

  1. 2025年10月30日 午前1時頃（日本時間）
    障害発生を確認
  2. 2025年10月30日 04:19（日本時間）
    「last known good configuration（直前の正常構成）」のデプロイが完了し、ノード復旧を開始し、「今後4時間以内に完全復旧を見込む」と告知
  3. 2025年10月30日 08:20（日本時間）
    Azure側が「recovery to happen by 23:20 UTC（＝8:20 JSTまでに復旧見込み）」と明記
  4. 2025年10月30日 09:40（日本時間）
    最終更新で「AFDサービスが98%以上の可用性を回復し、完全復旧を9:40 JSTに見込む」と発表

日本では、発生した時間自体は深夜ですが、回復に午前9時過ぎまでかかったため、朝一でメールを受信しようとしたらメールが受信できないなどの影響を受けた方もいたかと思います。

クラウド障害のインパクトの大きさ

先日のAWSの障害もDNSに起因するものでした。

AWSで大規模障害 ― マルチAZ構成でも防げなかった理由と今後の対策

DNSで障害が起きるとネットワークを前提としたシステムは非常に脆いことがわかります。加えて、クラウドベンダーが提供して責任を持つ部分であるため、DNSで障害が起きると複数のサービスに影響がおよび、それらのサービスを使用している複数の企業が影響を受けます。

この点については、各企業ごとに対策することが難しい場合が多いです。クラウド上でシステムを運用しているならマルチクラウドという選択肢はあるにはあります。ただし、コストとトレードオフになるため、事業規模によっては選択肢できない場合もあります。

また、IaaSではなくPaaSサービスを利用している場合はそういった選択肢も難しい場合があります。例えば、Microsoft 365で障害が起きた場合、他のベンダーでメールサービスを継続するということは不可能です。インフラを管理しないことに対するトレードオフでもあるので、どうしても障害を起こしたくないのであればインフラを管理する必要がありますが、クラウドベンダー並の可用性を実現できる企業は数えるほどしかないでしょう。

もう一つはこれが誤設定によるものであるという点です。過去に発生した大規模障害においても、誤った設定を適用した場合や操作ミスといった単純ミスによるものであったことがありました。これはMicrosoft Azureに限ったものではなく、他のクラウドベンダーでも起きています。

具体的な内容については公表されていないので想像になりますが、本当にただの凡ミスだったかもしれません。もしかすると、想定していなかった挙動だったのかもしれません。いずれにせよ、本当のところはわからないので一方的に「テストをしていないのではないか」と断ずるのは総計です。実際、DNS周りは想定しない挙動をする場合があるので、本番同等の環境を用意するのは現実的ではないため、テスト環境では問題ないことを確認した上で適用したが、予想しない挙動を示していたのかもしれません。

おわりに

以前のAWSの障害、今回のAzureの障害から言えるのは、

  • 代替の選択肢を持つこと
  • バックアップを3-2-1ルール取得し、復元できることを定期的に確認しておくこと

が重要であるということです。

代替の選択肢を持つというのは、メールの例で言えばメールが唯一の連絡手段になってしまうとメールが使用できなくなったときに業務が完全にとまってしまうので、それ以外の手段を持っておくというです。メールの例でいえば、電話やチャットなど複数の手段があるのが普通だと思いますのでそれほど問題ありません。しかし、空港での搭乗手続きが完全に電子化され、手動での搭乗手続きの手段が失われていたらどうでしょうか？ゲート搭乗機に障害が発生すると運休せざるを得なくなってしまいます。そういった意味では電子化は優れた選択肢である一方でそこに障害が発生したときに、人間の手による代替ができるようになっていることが重要です。

前述の話は機能に障害が発生した場合ですが、データにアクセスできなくなる場合やロストする場合について対策が必要です。古典的な手段ではありますが、現代でも有効な3-2-1ルールに則って、3つのデータコピーを保持し、2種類の異なるメディアに保存し、そのうち1つをオフサイト（地理的に離れた場所）に保管することは非常に有効です。

ただし、いくらバックアップが無事だといってもそこから復元できなければ意味がありません。バックアップを用意していても、いざ復元しようとしたら戻せなかったということは今に始まった話ではなく昔からずっと起きている話です。古くはテープにバックアップしたけどそこから復元できなかったなどということはよくある話ですし、2020年にはバックアップに不備があり障害が起きたときにバックアップから復元できずに売買停止が起きたこともありました。

避難訓練と同じで、災害発生時のマニュアル確認のための訓練やバックアップから復元できるかのリハーサルは義務付けられているものを除くと行っていないケースが多いように思います。日常的にテスト環境を構築するのにバックアップを使っているという場合であればバックアップ自体は使用可能だt思いますが、高度に自動化されている場合は手動でもできるのかといった点や3-2-1ルールに則ってバックアップが完全に失われないかなどを見直すことも重要です。

「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、こういった他社の事例からもしっかりと教訓を得ることは重要です。

参考文献

モバイルバージョンを終了