Azure Front Door＋Azure CDN で配布している約 80MB の .exe（30–60MB の .msi 含む）が、EU では高速だが米国からのみ極端に遅く、最終的に 504（Gateway Timeout）で失敗した――2025年9月15日 15:00 UTC 頃に起きた実例をもとに、原因の見立て、Microsoft による復旧の要点、そして再発時の影響を最小化するための設計・運用の具体策をまとめます。
事象の要約と結論
- 配布対象：およそ 80MB の .exe、30–60MB の .msi を Azure CDN ＋ Front Door 経由で配信。
- 症状：EU からは正常だが、米国では平均 0.9MB/s 前後までスループットが低下し、長時間の転送後に 504（Gateway Timeout）。小さなファイルは問題なし。
- 発生時刻：2025年9月15日 15:00 UTC 頃に顕在化。
- 最終結論：Microsoft 側でインフラ障害として認識・対処され Issue mitigated（復旧済）。利用者側で緊急の設定変更は不要。
ただし、CDN/Front Door はグローバル・大規模な分散システムのため、同種の事象は将来もゼロにはなりません。以降では、早期検知・迅速切り分け・一時回避・再発時の影響極小化に効く実装・運用ノウハウを、手順と設定例まで落として解説します。
発生状況の詳細
| 観測地点 | ファイル種別 | 平均速度 | 失敗率 | 備考 |
|---|---|---|---|---|
| EU（複数ロケーション） | .exe / .msi（30–80MB） | 過去平均 14MB/s 付近 | ほぼ 0% | 安定して完了 |
| 米国（複数ロケーション） | .exe / .msi（30–80MB） | 0.9MB/s 前後 | 高い（504 発生） | 小さなファイルは正常 |
小さなファイルが正常で大容量のみ失敗というパターンは、長時間転送を伴う経路のどこか（エッジ、ミドルボックス、オリジンまでの区間、あるいは一部地域の POP クラスタ）での輻輳・タイムアウト・キュー詰まりが疑われます。本件は Microsoft により復旧済みですが、切り分けの観点は今後も有効です。
今回の対応と公式ステータス
- Microsoft 公式見解：インフラ障害として認識・裏側で対処。Issue mitigated（復旧済） の連絡あり。
- 利用者側の恒久的設定変更：不要（復旧後は通常性能に回復）。
とはいえ、同種の事象に備えて 監視・冗長化・最適化・回避策 をあらかじめ整えておくことで、ビジネス影響を大幅に抑制できます。
再発防止・運用対策（サマリ）
| 目的 | 推奨アクション |
|---|---|
| 障害の早期把握 | Azure Status / Service Health で Front Door・CDN のインシデント監視。 アラートを構成してメール・Teams に通知。 |
| 地理的冗長 | マルチリージョンのオリジン（例：US West ＋ EU North）を構成し、ヘルスプローブで自動フェイルオーバー。 複数 CDN プロファイルやサードパーティ CDN と組み合わせるハイブリッドも検討。 |
| 大容量転送最適化 | Range Requests（分割ダウンロード） を前提に設計。 Front Door の Caching Rules を調整し、適切な TTL／キャッシュキー／圧縮設定を適用。 |
| 障害時の一時回避 | 地域別の直接オリジン URL または SAS 署名付き Blob を案内し、Front Door を一時バイパス。 |
なぜ「米国のみ」で遅延・504になり得るのか
- 地域限定の POP/ネットワーク事象：特定 POP/クラスタや経路（ピアリング・トランジット）が輻輳・劣化し、長時間フローが切断。
- 長時間転送とタイムアウト：大容量のみ影響が顕著。一定以上の時間/アイドルを検知すると、途中経路で切断され 504 として表面化。
- エッジキャッシュのパーシャル性：最初のミスヒットでオリジンからのフェッチに時間がかかると、小分けに取得する途中でタイムアウトしやすい。
- HTTP/2/HTTP/3 の相互運用：QUIC/HTTP/3 の一部経路品質が悪いとフォールバックが発生、ハンドシェイクの繰り返しで体感が悪化。
今回のケースは Microsoft 側の障害であり復旧済みですが、上記のようなメカニズムを理解しておくと、現場での判断が早くなります。
復旧後に必ずやるべき検証チェックリスト
| チェック | 方法 | 合格基準 |
|---|---|---|
| 米国からの実効速度 | 主要ロケーション（東/中/西）から同一ファイルを計測 | 過去平均（目安 14MB/s 前後）に回復 |
| HTTP エラー率 | Front Door/CDN のメトリクスとログを確認 | 5xx が平常水準（ほぼ 0%） |
| Range Requests | ヘッダ Accept-Ranges: bytes の有無、部分取得の成功 | 部分取得が安定し、結合後ハッシュ一致 |
| キャッシュ健全性 | キャッシュヒット率、ミス後の再試行時間 | ヒット率が目標域、ミス時もタイムアウトなし |
監視と早期検知の設計（Azure Monitor／Service Health）
アラート設計の考え方
- サービス健全性：Front Door / CDN のインシデント通知を購読し、メール・Teams に直結。
- 体感メトリクス：ダウンロード時間（P90/P99）、失敗率（5xx）、米国サブセットのスループットを定常監視。
- ログ基盤：Front Door Access Log / CDN Access Log を Log Analytics に集約。KQL で地域別の異常を自動検知。
地域別 5xx 検知の KQL 例
// Front Door Standard/Premium
FrontDoorAccessLog
| where TimeGenerated > ago(1h)
| summarize errors = countif(ToClientStatusCode >= 500),
total = count()
by ClientCountryOrRegion
| extend errorRate = todouble(errors) / todouble(total)
| where ClientCountryOrRegion in ("United States","Canada") and errorRate > 0.01
// Azure CDN (Microsoft) - AzureDiagnostics 経由の代表例
AzureDiagnostics
| where TimeGenerated > ago(1h)
| where Category == "CDNAccessLog"
| summarize errors = countif(toint(httpStatusCode_s) >= 500),
total = count()
by clientCountryOrRegion_s
| extend errorRate = todouble(errors) / todouble(total)
| where clientCountryOrRegion_s == "United States" and errorRate > 0.01地理的冗長とトラフィックステアリング
Front Door の オリジングループ に US West と EU North を登録し、ヘルスプローブ（HTTP 200/特定パス）で可用・優先度制御します。米国系 POP が劣化しても、オリジン単位の自動切替や優先度変更で回避余地が生まれます。加えて、DNS ベースのトラフィックステアリング（例：複数 CDN を Anycast＋DNS で振り分け）を組み合わせると、広域障害のときも配信経路の選択肢を確保できます。
| パターン | 構成 | 利点 | 留意点 |
|---|---|---|---|
| Front Door 内冗長 | US/EU の複数オリジン＋ヘルスプローブ | シンプル、同一運用面 | Front Door 自体の広域障害には弱い |
| マルチ CDN | Front Door ＋ 第三者 CDN を DNS で切替 | ベンダーロック解消、地域特性に強い | コスト増、キャッシュ二重化の整備が必要 |
大容量転送の最適化：Range Requests を前提にする
大容量ファイルは Range Requests（部分取得） を使う前提にします。クライアントが Range: bytes=0- 等で分割要求し、CDN は部分的にキャッシュ。長時間の単一フローよりも耐障害性が高く、途中エラーでも再開が容易です。
テストコマンド例（再開・部分取得）
# Windows PowerShell（部分取得して結合）
$u = "https://cdn.example.com/downloads/app.exe"
Invoke-WebRequest -Uri $u -Headers @{"Range"="bytes=0-10485759"} -OutFile part1.bin
Invoke-WebRequest -Uri $u -Headers @{"Range"="bytes=10485760-20971519"} -OutFile part2.bin
cat part1.bin,part2.bin -Encoding Byte > app.exe
# curl（HTTP/3 と HTTP/2 の比較、レジューム）
curl -L --http3-only -o app.exe $u
curl -C - -L --http2 -o app.exe $u
# aria2c（並列 16、本番はサーバ負荷を見て調整）
aria2c -s16 -x16 --file-allocation=none $uヘッダ確認
# Range が有効か（Accept-Ranges）
curl -I https://cdn.example.com/downloads/app.exe
# 期待: Accept-Ranges: bytes, Content-Length: <実サイズ>Front Door / CDN のキャッシュ・ルール設計（実践）
- TTL：安定版バイナリは長め（数日～数週間）。頻繁な差し替えがある場合は、
?v=等のバージョン付けと合わせて調整。 - キャッシュキー：SAS を使う場合、署名等の Query がキャッシュキーに乗るとヒット率が落ちます。必要なキーだけ を含める、またはクエリを無視する方針を明確化。
- 圧縮：.exe/.msi は元々バイナリ圧縮されていることが多く、圧縮は効果薄。不要なら圧縮対象から除外。
- WAF：ダウンロード専用パスは WAF ルールの偽陽性を避ける調整（特にファイル拡張子ベースのブロック）。
Front Door Rules Engine の例（疑似表記）
IF Path matches "/downloads/*" AND FileExtension IN (".exe",".msi",".zip")
THEN
Cache: Override TTL 7d
Cache key: Ignore query string except ["v"]
Compression: Off
Origin group: "multi-region"
Response header: "Accept-Ranges: bytes" (透過)障害時の一時回避：オリジン直リンク／SAS の使い分け
Front Door/エッジ経路に問題がある場合、US 向けに一時的な直リンク を配布して影響を最小化できます。Azure Blob の SAS を用いると、期限付き・権限限定の配布が可能です。
Azure CLI での SAS 生成例
# 有効期限を短くし、読み取り専用に限定
az storage blob generate-sas \
--account-name mystorage \
--container-name downloads \
--name app.exe \
--permissions r \
--expiry 2025-09-16T23:59:00Z \
--https-only
# 返却された SAS を組み合わせた URL を告知（例）
[https://mystorage.blob.core.windows.net/downloads/app.exe?sv=...&sig=](https://mystorage.blob.core.windows.net/downloads/app.exe?sv=...&sig=)...注意点として、直リンク配布は キャッシュを経由しないためオリジン負荷と帯域コスト が増えます。対象地域と期間を絞り、完了後は速やかに通常経路へ戻しましょう。
オリジン多重化とヘルスプローブの作り方
- Front Door に US West・EU North 等のオリジンを登録。
- オリジングループを作成し、優先度（Priority） と 重み（Weight） を設定。
- ヘルスプローブは HTTP 200 を返す軽量パスを用意（例：
/healthz）。 - フェイルオーバー時に セッション継続の影響がない 静的配布であることを確認。
この構成により、一部地域でのオリジン到達性/性能劣化にも自動的に対応できます。
HTTP タイムアウトと 504 の見極め
| 現象 | 主な起点 | 対処の方向性 |
|---|---|---|
| 504（Gateway Timeout） | エッジからオリジン、または中継の応答遅延 | 経路/POP 事象の切り分け、再試行/部分取得、フェイルオーバー |
| 502（Bad Gateway） | オリジンが不正応答／中継のプロトコル不整合 | オリジンログ精査、プロトコル/ヘッダ調整 |
| 499/408（Client Closed/Request Timeout） | クライアント側切断・アイドル超過 | クライアントのレジューム実装、ダウンロードマネージャ推奨 |
計測の実務：米国内の速度を継続監視する
- 基準作り：過去 30～90 日の P50/P90/P99 を米国東・中・西で分離し、正常値（例：P50≒14MB/s）を確立。
- 可視化：Azure Monitor Workbook に速度・エラー率のトレンドを集約。ホットスポットを地図プロット。
- アラート：P90 がしきい値（例：5MB/s）を一定時間下回ったら通知。5xx の急増と合わせて相関を見る。
「小さなファイルは問題なし」から分かること
小さなファイルの成功は、名前解決・TLS 終端・WAF 基本動作が正常であることを示します。問題は 長時間持続するフロー に偏るため、Range 分割・再開 による耐性向上が最も効果的です。また、CDN エッジのミスヒット時にオリジンまでの取得が遅いと顕著になるため、初回ヒット率の向上（配布直後のプリウォーム、段階的リリース）も効きます。
配布パス設計と命名のベストプラクティス
- バージョン固定のパス：
/downloads/app/1.2.3/app-1.2.3.exeのように、同一 URL の再発行を避ける。 - 長期キャッシュ＋短期無効化：長期 TTL ＋ キャッシュバスティングにより、配布時のみ新規取得を発生させる。
- 整合性検証：ハッシュ（SHA-256）を別パスで提供し、部分取得結合後の検証を促す。
運用 Runbook（テンプレート）
- 検知（0–5分）：アラート受信、ダッシュボード確認。対象は「米国」「大容量パス」。
- 宣言（5–10分）：影響範囲・ユーザー影響・暫定回避策（SAS/直リンク）を内部合意。
- 切替（10–20分）：トラフィックの比率調整、地域限定の回避策公開。
- 連携（並行）：Microsoft サポート窓口への連絡（既知障害の有無、ステータス問い合わせ）。
- 観測（継続）：P90 速度と 5xx を 15 分粒度でモニタ。復旧時に順次通常経路へ戻す。
- 事後（復旧後）：ポストモーテム作成、ダッシュボード・アラート・Runbook の改善。
FAQ（よくある質問）
Q. Range を使えば必ず速くなりますか？
A. 速度向上は副作用で、主目的は回復力（レジューム・再試行の粒度）の向上です。並列数や分割サイズはサーバ負荷を見ながら調整してください。
Q. HTTP/3 を強制すべきですか？
A. クライアント・ネットワークによっては QUIC が不利なケースもあります。HTTP/3 を優先しつつ、HTTP/2/1.1 へのフォールバックを確保するのが無難です。
Q. 圧縮は有効ですか？
A. .exe/.msi は圧縮効果がほぼありません。代わりに キャッシュ設計と Range を重視してください。
設定の総点検チェックリスト
| 項目 | 望ましい状態 | 補足 |
|---|---|---|
| Range Requests | Accept-Ranges: bytes が返り、部分取得成功 | レジューム前提のクライアントを案内 |
| キャッシュ TTL | 安定版を長期化、更新はバージョン付与で制御 | 初回のプリウォームも検討 |
| キャッシュキー | 不要なクエリを除外、SAS はキーを最小化 | ヒット率改善 |
| オリジン冗長 | US/EU の複数オリジン＋ヘルスプローブ | 優先度と重みで制御 |
| アラート | 米国の速度/5xx のしきい値を監視 | P90/P99 を基準化 |
| 回避手段 | 直リンク/SAS の手順と承認フローを文書化 | 期限付きで配布 |
今回のケースでの最終メッセージ
まとめ：2025年9月15日 15:00 UTC 頃に観測された「米国からの大容量ダウンロードが極端に遅く 504 となる」事象は、Azure Front Door/CDN 側の一時的な障害であり、Microsoft により復旧済み（Issue mitigated）です。利用者側の恒久的な設定変更は不要でした。
一方で、配布サービスの信頼性を高めるには、監視の徹底・マルチリージョン冗長・Range 前提の最適化・一時回避手段の常備が決定打です。本記事のチェックリスト・KQL・ルール例を採り入れて、次のインシデント時にも 検知 → 切り分け → 回避 → 復旧確認 を素早く回せる運用に仕上げてください。
参考：実務で役立つテスト手順（テンプレ）
1) ネットワーク経路の簡易確認
# DNS 解決と到達確認
nslookup cdn.example.com
ping -n 1 cdn.example.com
# TCP/443 のオープン確認（Windows）
Test-NetConnection cdn.example.com -Port 4432) スループットの確認（米国内の拠点別）
# ダウンロード時間の計測（PowerShell）
$u = "https://cdn.example.com/downloads/app.exe"
$sw = [System.Diagnostics.Stopwatch]::StartNew()
Invoke-WebRequest -Uri $u -OutFile app.exe
$sw.Stop()
"ElapsedSeconds=" + $sw.Elapsed.TotalSeconds3) 504 発生時の即応
- Service Health を確認（既知インシデントの有無）。
- US 西/中/東の 3 地点で再現性を確認。
- Range 分割で再試行（並列数は控えめ）。
- 必要に応じて US 限定で SAS 直リンクを告知。
- 復旧後に通常経路へ戻す（アナウンス含む）。
運用における注意点（再掲）
- レジューム前提のダウンローダ（組み込み/公式ツール）を提供すると、ユーザー体験が安定します。
- 配布直後は キャッシュのミスヒットが増える ため、ピーク前のプリウォームが効果的です。
- WAF/ボット対策の誤検知により .exe がブロックされないかを必ず検証します。
- SAS 配布は 短期・限定 を徹底し、期限切れとアクセス制御を厳格に。
最終チェック（サイト公開前）
- 米国 3 拠点での速度（P90）と成功率が基準に復帰している。
- Front Door/CDN のアラートが有効で、通知系（メール/Teams）が動作する。
- ダウンロードページにレジューム可の注意書き（推奨クライアント）が明記されている。
- 障害時の回避導線（ステータス表示や直リンクの切替手順）が用意されている。
以上を満たしていれば、今回と同種の地域限定障害が発生しても、ユーザー影響を最小限に留めつつ迅速に復旧まで運べます。
コメント