Microsoft Azure のステータス履歴に、9 月末、事後レビューが立て続けに 2 件掲載されました。どちらも全世界規模の障害ではありませんが、根本原因はいずれも典型的で、自分のアーキテクチャと照らし合わせる価値があります。

1 件目：Sweden Central の AI サービス（追跡 ID 7QL5-Z50）

2026 年 9 月 29 日 UTC 10:03〜15:58、Sweden Central リージョンの Azure OpenAI、Foundry Agent Service、Foundry Models、Cognitive Services で、断続的なリクエスト失敗、遅延の増加、HTTP 5XX エラーが発生しました。Microsoft が示した根本原因は、メタデータを取得するバックエンドサービスがデータベースのタイムアウトに見舞われ、インスタンスがしきい値に達して再起動を繰り返し、正常な処理能力が減ったことです。10:14 に失敗率の上昇を検知、11:29 にタイムアウトを特定、15:22 にサービスを拡張してリソース上限を引き上げ、15:58 に回復しました。

これは 9 月 3 日の AI サービス障害の記事で取り上げたのと同じ種類のリスクです。アプリケーション自体は正常でも、依存しているモデル API があるリージョンで遅くなったり失敗したりします。

2 件目：5 リージョンのゲートウェイ系サービス（追跡 ID 7Q30-010）

9 月 30 日 UTC 20:30 から 10 月 1 日 UTC 02:15 まで、ExpressRoute Gateway、Azure Firewall、Application Gateway、WAF、VPN Gateway、Azure VMware Solution で、英国南部、フランス中部、北ヨーロッパ、東南アジア、英国西部の接続に問題が生じました。このうち「東南アジア」は Azure のシンガポールリージョンです。初期レビューの根本原因は、リージョンのゲートウェイ管理に最近加えた変更が、無関係な OS の保守作業の進行中に過大な負荷を引き起こし、依存先サービスの制約のため自動スケールできなかったことです。23:05 に OS 保守との関連を特定して一時停止し、01:36 に回復が進み、02:15 に緩和を確認しました。

2 件を並べて読む

  • 「マシンが動いている」は「サービスに到達できる」ではありません。2 件目では多くの仮想マシン自体は正常だったかもしれませんが、手前のゲートウェイ、ファイアウォール、VPN が止まれば利用者は接続できません。ホスト単位の監視だけでは不十分で、外部からアクセス経路全体を確認する必要があります。
  • 変更と保守の重なりは昔からある失敗の型です。どちらか一方だけなら無害でも、重なると壊れます。自分のサーバーでも同じで、アップグレード、再起動、設定変更は時間をずらし、切り戻しの手段を残しておきましょう。
  • 依存関係を図にする。上半期の障害に関する記事で、どのリクエストがどの事業者のどのリージョンを通るのか、障害時に切り替えられるのかを洗い出すよう提案しました。

東南アジアの利用者にサービスしている場合

利用者が主に東南アジアにいて、重要な入口を 1 社の 1 リージョンだけに置いていると、こうした障害のときは待つしかありません。より堅実なのは、別の事業者または別の地域に引き継げる入口を用意し、DNS の切り替えと組み合わせる構成です。拠点の選び方は用途に合った低遅延のデータセンターの選び方で解説しており、当社のシンガポールノードもそうした予備の入口の一つとして使えます。