Azure CDN や Azure Front Door でキャッシュパージを実行したところ、なかなか処理が終わらず、最終的に 1 時間タイムアウト…。そんな経験はないでしょうか。本記事では、実際にあった事例をもとに、原因の考え方と切り分け・対処・再発防止策までを、現場目線で詳しく解説します。
Azure CDN／Front Door のキャッシュパージで起きる「1時間タイムアウト」とは
Azure ポータルや Azure CLI から特定の CDN エンドポイントに対してキャッシュ無効化（パージ）を実行した際、以下のような現象が報告されています。
- パージ操作自体は受け付けられるが、完了まで非常に時間がかかる
- 最終的に約 1 時間で「タイムアウト」となり失敗扱いになる
- エラーメッセージ内に
correlationIdやoperationIdが含まれる - 再実行しても同様の事象が断続的または継続的に発生する
過去には、Azure プラットフォーム側の高レイテンシが原因となり、広範囲でパージ処理が遅延・タイムアウトした事例もありました。その際は Azure 側で緩和策が適用され、自然復旧しています。ただし、現在広範囲での障害が発生していない場合でも、特定環境や特定エンドポイントだけでタイムアウトが起こるケースがあります。
そこで重要になるのが、「プラットフォーム側の一過性の問題」なのか、「構成・運用による負荷や設計の問題」なのかを切り分けることです。
キャッシュパージがタイムアウトする主な原因のパターン
まずは、キャッシュパージでタイムアウトが発生する際に考えられる原因を整理しておきます。
| 原因候補 | 概要 | 典型的な現象 |
|---|---|---|
| プラットフォーム側の一時的な遅延／障害 | Azure CDN／Front Door 内部の制御プレーンやバックエンド処理に一時的な問題が発生 | 複数テナント・複数リージョンで同時期に失敗、時間が経つと自然復旧する |
| 全件パージや大量パス指定による負荷 | /* など非常に多くのキャッシュを対象にしたパージで処理時間が極端に長くなる | 小さなパス集合では成功するが、全件パージだけがタイムアウトする |
| パージ処理が非同期であることによるギャップ | バックエンドでは処理が進行しているが、呼び出し元（ポータル／CLI）のタイムアウト上限にかかる | ポータルや CLI は失敗を返すが、しばらく経つと実際にはキャッシュが更新されている |
| エンドポイントの状態や権限の問題 | エンドポイントが停止中、または RBAC 権限不足などにより正常に処理できない | 特定のエンドポイントだけでパージ失敗、アクティビティ ログに権限エラーが記録されている |
このうち、「一時的なプラットフォーム側の問題」＋「全件パージなど重い要求」が組み合わさると、1 時間タイムアウトになりやすくなります。
切り分けのために最初に確認すべきポイント
現場でのトラブルシュートを効率よく進めるには、むやみに再実行を繰り返すのではなく、以下の観点で切り分けを行うことが重要です。
| 確認観点 | チェック内容 | ポイント |
|---|---|---|
| 全件パージか・特定パスか | /* で全パージしているか、/static/* など範囲を絞っているか | 全件パージでのみ失敗するなら「キャッシュ量」や「処理時間」が疑わしい |
| 常時再現か・断続的か | いつ実行しても失敗するのか、時間帯や日によって成功／失敗が変わるのか | 断続的な場合、プラットフォーム側の一時的な負荷や障害である可能性が高い |
| 小規模パスでは成功するか | 数件のパスだけを指定してパージしてみる | 小さなパージが成功する場合は、「対象パスの量」がボトルネックかもしれない |
| 他のプロファイル／エンドポイントではどうか | 別プロファイル、別エンドポイントで同じ操作を試す | 特定エンドポイントだけなら設定・構成由来、複数で同時に起きるならプラットフォーム要因を疑う |
| ポータル／CLI／API で結果は同じか | Azure ポータルと Azure CLI の両方からパージを実行 | クライアント固有の問題（ブラウザやネットワーク）を切り分けられる |
これらを順に確認することで、「自分たちの構成で改善できる範囲」と、「Microsoft サポートにエスカレーションすべき範囲」が明確になります。
すぐできる実務的な対処手順
ここからは、現場ですぐ試せる具体的な対処手順をステップ形式で解説します。
ステップ 1：対象パスを絞ってパージする
最初に試してほしいのが、全件パージ（/*）ではなく、更新対象に絞ったパージです。
- 例：
/static/*、/assets/app.*、/images/logo.pngなど - CSS・JS・画像など、リリースで変更したファイル群に限定してパージする
これにより、パージ対象のキャッシュ数が減少し、処理時間が短くなります。また、「全件では失敗するが、小さなパス集合では成功する」かどうかを確認することで、原因の切り分けにもなります。
ステップ 2：小規模 → 中規模 → 全件の順で段階的に再実行
いきなり本番と同じ規模で再実行せず、以下のような段階的アプローチがおすすめです。
- 数件のファイル（個別パス）だけでパージを実行
- サブディレクトリ単位（
/static/*など）でパージ - どうしても必要な場合のみ、
/*で全件パージを試行
この過程で、どの規模からタイムアウトするかが分かれば、キャッシュ量や構成の見直し、運用フローの改善につなげやすくなります。
ステップ 3：アクティビティ ログで correlationId／operationId を確認
パージが失敗した際に表示されるエラーメッセージには、多くの場合 correlationId や operationId が含まれます。これらは Azure 側で処理を追跡するためのキーです。
- Azure ポータルの「監視」 → 「アクティビティ ログ」を開く
- 時間範囲をエラー発生時刻前後に絞る
- 検索条件やフィルタで
operationNameやリソース名から該当エントリを特定 - 詳細ペインで 相関 ID（correlationId）や 操作 ID（operationId）を控える
この情報は、サポート ケースを起票する際の必須情報になります。トラブルが起きたタイミングごとに、必ず記録しておくと後からの分析が非常に楽になります。
ステップ 4：エンドポイントの状態（Running）を確認
意外と見落としがちなのが、エンドポイント自体の状態です。エンドポイントが 停止中、あるいは構成変更中で安定していない場合、パージの結果が不安定になることがあります。
- Azure ポータルで対象の CDN / Front Door プロファイルを開く
- 対象エンドポイントの状態が Running（実行中） になっているか確認
- 「中断」「無効化」状態の場合は、まず状態を正常に戻す
ステップ 5：RBAC 権限を確認する
パージ操作には、該当リソースに対する十分な権限が必要です。少なくとも、該当プロファイルに対して 共同作成者（Contributor）以上 のロールが付与されているか確認します。
- リソースの「アクセス制御 (IAM)」から自分のアカウントのロールを確認
- 必要に応じて管理者にロールの追加を依頼
- サービス プリンシパルやマネージド ID を用いている場合も同様に確認
権限に問題がある場合は、アクティビティ ログにアクセス拒否系のエラーが残っていることが多いので、併せて確認しておきましょう。
Azure CLI からのパージ実行例とポイント
Azure CLI を使うと、パージ操作をスクリプトや CI/CD パイプラインに組み込みやすくなります。ここでは Azure Front Door（Standard/Premium）と、旧 Azure CDN（Classic）での代表的な例を紹介します。
Azure Front Door Standard/Premium のパージ例
エラーメッセージや URL に /afdendpoints が含まれている場合は、Azure Front Door Standard/Premium の可能性が高いです。CLI では次のようにパージします。
az afd endpoint purge \
--resource-group <リソースグループ名> \
--profile-name <プロファイル名> \
--endpoint-name <エンドポイント名> \
--content-paths '/*' '/assets/*'
ポイントは以下の通りです。
--content-pathsで複数のパスを指定可能（半角スペース区切り）- 先頭の
/を忘れない（例：assets/*ではなく/assets/*） - 全件パージ
/*を指定する前に、なるべく範囲を絞ったパスから試す
Azure CDN（Classic）のパージ例
旧 Azure CDN（Classic）や特定の SKU を利用している場合は、以下のコマンドになります。
az cdn endpoint purge \
--resource-group <リソースグループ名> \
--profile-name <プロファイル名> \
--name <エンドポイント名> \
--content-paths '/*'
CLI の標準出力だけでは、内部的な遅延やエラー内容まで見えないことが多いため、アクティビティ ログや診断ログとセットで確認する運用がおすすめです。
それでも解消しない場合：Microsoft サポートへのエスカレーション
上記の対処を試しても問題が解消せず、かつ広範な障害情報も出ていない場合は、Microsoft サポートへの問い合わせを検討しましょう。その際、次の情報を整理しておくと、調査がスムーズに進みます。
| 項目 | 内容 |
|---|---|
| correlationId／operationId | タイムアウトしたパージ操作の ID をアクティビティ ログから控えておく |
| 再現手順 | どのポータル画面／CLI コマンド／API で、どのようなパラメータを指定したか |
| 影響範囲 | 影響するプロファイル数・エンドポイント数、パスの数、利用リージョン |
| 発生タイミング | 初回発生日時と、その後の再現状況（常時／断続的／時間帯に偏りがある等） |
| 期待値 | 本来どの程度の時間でパージが完了してほしいか、業務影響（SLAなど） |
併せて、Azure ポータルの 「Service Health（サービス正常性）」 に同様の事象に関するアドバイザリやインシデントが出ていないか確認しておくと、サポートとの会話が噛み合いやすくなります。
パージタイムアウトの背景：Azure CDN／Front Door の仕組みをざっくり理解する
原因のイメージをつかむために、キャッシュパージの内部的な流れを簡単に整理しておきます。
- ユーザーがポータル／CLI／API からパージ操作をリクエスト
- Azure の制御プレーンがリクエストを受付け、内部キューに登録
- 世界中のエッジノードに対して「このパスを消してね」という指示が配信される
- 各エッジノードが自分のキャッシュを見て、該当するコンテンツを削除
エッジノードは世界中に多数存在するため、すべてのノードから応答を待っていると、どうしても時間がかかる処理です。そのため、クライアント側には一定時間（たとえば 1 時間）でタイムアウトを返しつつ、裏側では処理が継続している、といったことも起こり得ます。
つまり、「クライアント側のタイムアウト」＝「必ずしもパージが失敗した」ではない点に注意が必要です。タイムアウト後に対象の URL へアクセスしてみると、実際には新しいコンテンツが返ってくる、というパターンもあります。
再発防止に効く運用のコツ
一時的なプラットフォーム要因であれば、時間経過とともに自然復旧することもあります。しかし、毎回「祈りながらパージ」していては運用が不安定です。ここでは、再発防止・影響最小化のための運用上の工夫を紹介します。
キャッシュバスティング（ファイル名バージョニング）を徹底する
もっとも効果的なのは、「そもそもパージにあまり依存しない設計」にすることです。その代表例が、ファイル名にバージョンを埋め込むキャッシュバスティングです。
- 例：
app.css→app.v20250912.cssのようにリネーム - HTML 内の参照を、リリースごとに新しいファイル名へ差し替える
- 古いファイルは TTL 経過後に自然にキャッシュから消えていく
この方式にすると、「新バージョンのリリースで新しい URL に切り替わる」ため、緊急時以外は全件パージを行う必要がほぼなくなります。
TTL（有効期限）のメリハリをつけて設定する
すべてのコンテンツに同じ TTL を設定していないでしょうか。Azure CDN／Front Door では、パスごとに適切な TTL を設定することができます。
| コンテンツの種類 | 推奨 TTL の方向性 | 理由 |
|---|---|---|
| 頻繁に更新される JSON / API レスポンス | 短め（数秒〜数分） | 最新データの反映を優先したい |
| アプリ本体 JS / CSS | 長め（数時間〜数日）＋バージョニング | 変更時にファイル名を変えるため、TTL は長くてよい |
| 大きな画像・フォントなど静的アセット | 長め（数日〜数週間） | 更新頻度が低く、キャッシュヒット率を上げたい |
このように、更新頻度に応じて TTL をメリハリをつけて設定することで、パージ対象も自然と絞られ、タイムアウトのリスクを減らせます。
段階的パージをリリース手順に組み込む
リリース作業のチェックリストに「キャッシュパージ」を入れているケースは多いと思いますが、その内容を少し工夫してみましょう。
- まずは 限定的なパス（変更した JS/CSS、API レスポンスなど）だけをパージ
- 監視ダッシュボードやログでエラー増加がないかを短時間ウォッチ
- 問題なければ、必要に応じてディレクトリ単位のパージを追加
- 全件パージは「どうしても必要な場合のみ」の最後の手段として残す
これにより、もし Azure 側に一時的な遅延があっても、影響範囲を小さく保ちながらリリースを進めることができます。
メトリクス監視とアラートを整備する
Azure Monitor や Application Insights と組み合わせて、次のようなメトリクスにアラートを設定しておくと安心です。
- パージ API の失敗率（サーバーエラー、タイムアウトなど）
- フロントエンド（エッジ）応答時間の急激な悪化
- オリジンへのバックエンドトラフィックの急増
パージがうまくいかずキャッシュが使われない状態になると、オリジン側の負荷が急増することがあります。早めに気づければ、一時的にトラフィックを絞る、スケールアウトするなどの対処が可能になります。
事象発生時は相関 ID を必ず記録する仕組みを作る
毎回手作業でスクリーンショットを撮るのは大変なので、以下のようなシンプルなルールを運用に組み込むと良いでしょう。
- パージ失敗時は、エラーメッセージと時刻をチャットツール（Teams など）に貼る
- アクティビティ ログから相関 ID／操作 ID を確認し、同じスレッドに記録
- サポートケースが必要になったら、そのスレッドをまとめて添付
こうしておくことで、「あのときのエラーの ID が分からない…」というよくある事態を防げます。
実際の事例から学ぶ：一過性のプラットフォーム要因＋自然復旧
冒頭で紹介した事例では、Azure 側で今年前半にパージ処理に関する高レイテンシが発生し、一部テナントでパージのタイムアウトが多発しました。Microsoft による調査とプラットフォームの調整により、最終的には緩和され、現在は同様の広範障害は観測されていません。
この案件では、
- 全件パージ（
/*）でタイムアウトが頻発していた - 同じエンドポイントでも、少数パスのパージは成功することが多かった
- 時間が経つと、同じオペレーションでも成功するようになった
といった状況から、「プラットフォームの一過性の要因」＋「全件パージという重い操作」が組み合わさって問題が顕在化したと考えられます。
最終的には自然復旧したものの、この経験を踏まえ、以下のような運用改善が行われました。
- 通常リリースではファイル名バージョニングを徹底し、全件パージを行わない
- 緊急時のみ特定ディレクトリ単位でパージし、全件パージは最終手段とする
- パージ失敗時の correlationId を必ず記録するルールを作る
- リリース手順書に「段階的パージ」と「監視ダッシュボードのチェック」を追記
このように、一度トラブルを経験しても、運用プロセスを見直して再発防止策を組み込むことで、同じような問題が起きたときの影響を大きく減らすことができます。
まとめ：パージタイムアウトに振り回されない CDN 運用へ
Azure CDN／Azure Front Door のキャッシュパージが 1 時間タイムアウトしてしまう原因は、
- プラットフォーム側の一時的な遅延・障害
- 全件パージや大量パス指定による処理時間の増大
- 非同期処理であるがゆえのクライアント側タイムアウト
- エンドポイント状態や RBAC 権限の問題
といった複数要因が絡み合っていることが多く、一つ一つを丁寧に切り分ける姿勢が求められます。
実務上は、
- 対象パスを絞ったパージを基本とし、全件パージを安易に行わない
- キャッシュバスティング（ファイル名バージョニング）の採用でパージ依存度を下げる
- TTL 設定の見直しにより、更新頻度に応じたキャッシュ戦略をとる
- 段階的パージ＋監視をリリース手順に組み込む
- トラブル時には correlationId／operationId を必ず記録して調査とサポート連携に活かす
といったポイントを押さえることで、パージタイムアウトに振り回されない、安定した Azure CDN／Front Door 運用に近づくことができます。
もし現在進行形で同様の問題に直面している場合は、本記事の手順に沿って切り分けと対処を進めつつ、必要に応じて Microsoft サポートへのエスカレーションも検討してください。そして、問題が落ち着いた後には、ぜひ一度キャッシュ戦略とパージ運用全体を見直し、「次に同じことが起きたときの影響をどこまで小さくできるか」という観点で改善してみてください。
コメント