Azure Computer Vision の Read（OCR）で突然 503 Service Unavailable が増え、レイテンシが 1〜2 分まで悪化したら、まず疑うべきはアプリのバグではなく「リージョン側の一時障害・負荷」です。本記事では West Europe で実際に報告された事例をもとに、原因の考え方、切り分け、最短で復旧させる回避策と運用設計をまとめます。
発生した問題の全体像：West Europe の Read が 503 になり、応答が極端に遅くなる
今回の事象は、Azure Computer Vision（Azure Cognitive Services / Image Analysis）のうち、特に West Europe リージョンの「Read（OCR）」系 API が、あるタイミングから急に不安定になった、というものです。単発の失敗ではなく、運用上の体感として「明らかにおかしい」レベルで品質が落ちます。
- レイテンシ：通常は約 5 秒程度だったものが、1〜2 分まで悪化
- 失敗率：体感で 約 2 回に 1 回 503 Service Unavailable
- 関連症状：同じ West Europe の別機能（例：VectorizeText エンドポイント）でも内部エラーが発生
- 波及：複数の利用者が同様の症状を報告（個別環境だけの問題に見えない）
そして重要なのが、North Europe に新規リソースを作ってエンドポイントを切り替えると、遅延なく動作したという報告がある点です。つまり「入力画像の問題」「呼び出し回数が増えた」などではなく、リージョン起因の一時的な障害・負荷を強く示唆します。
| 観点 | 通常時 | 障害・高負荷時に見える症状 | 判断のコツ |
|---|---|---|---|
| 応答時間 | 数秒（例：5秒前後） | 1〜2分など極端に長い | 処理が「遅い」だけでなく、時間帯やリージョンで偏りが出る |
| HTTP ステータス | 2xx / 202（非同期） | 503 が増える（再試行で通ることもある） | 設定ミスより「一時的なサービス側問題」を疑う |
| 影響範囲 | 特定の機能だけ | 同リージョン内の別エンドポイントでも内部エラー | 同じ Cognitive Services の複数機能が一緒に揺れるならリージョン起因の可能性が上がる |
| 回避 | 不要 | 別リージョンへ切替で改善 | North Europe / East US などで正常なら、ローカル要因の線は薄い |
503 Service Unavailable が意味すること：まず「一時的な障害」として扱う
503 Service Unavailable は、ざっくり言うと「サーバー側が今は処理できない」状態です。よくある要因は次の通りです（必ずしも一つに限定されません）。
- リージョン内の一時障害（サービスコンポーネントの不調、障害復旧中など）
- 高負荷・キャパシティ不足（短時間に集中して処理できない）
- 依存先の不調（内部で参照する別サービスが遅延し、連鎖的に 503 になる）
- 保護動作（サービスが自衛的に受付を絞っている状態）
ここで大切なのは、503 は「あなたのコードが間違っている」サインとは限らないということです。もちろん設定ミスが 4xx を返すことはありますが、503 + レイテンシ悪化 + 同リージョンで複数機能に波及という組み合わせは、プラットフォーム側の事情が濃厚になります。
公式対応の整理：Microsoft 側でも同様報告を認識し、最終的に改善した
今回のケースでは、Microsoft 側も「複数の顧客から同様の報告がある」ことを認識しており、製品チーム（PG）に調査依頼を行った旨が案内されています。その後、質問者から「今はかなり改善しており、遅延も解消された」という報告があり、最終的には Microsoft 側の対応で復旧したと見られます。
この流れは、運用者として重要な示唆があります。
- 一時障害は起きる前提で設計・運用する（特に AI 系は負荷影響が出やすい）
- 復旧までの「時間」をゼロにはできないので、アプリ側で吸収できる仕組みが必要
- 障害発生中は「原因究明」より、まず可用性を取り戻す回避策が価値を持つ
最短で状況を把握する切り分け：自分の環境か、リージョン障害か
障害時にやりがちなのが、キーを再生成したり、SDK を入れ替えたり、コードを疑って深掘りしてしまうことです。もちろん必要な場合もありますが、今回のような現象では、まず 「プラットフォーム側」かどうかを高速に切り分けるのが得策です。
| 確認項目 | 確認方法（例） | プラットフォーム側が疑わしいサイン | 自分側が疑わしいサイン |
|---|---|---|---|
| Azure ステータス | Azure status / Service Health で Cognitive Services と該当リージョンを確認 | 障害・性能低下が表示される、または近い時間帯のインシデントがある | ステータスは正常で、自分だけ再現する |
| 別リージョンで同じリクエスト | North Europe / East US などに同サービスを作り、同じ入力で実行 | 別リージョンは安定して速い | どのリージョンでも同様に失敗する |
| 入力データ | 同じ画像・同じ URL で再現するか | 入力に依存せず失敗/遅延する | 特定の画像だけ落ちる（形式、サイズ、破損など） |
| クォータ/制限 | ポータルのクォータ、アプリの呼び出しレートを確認 | 呼び出しが少ないのに 503 が出る | 急増があり 429/制限に近い兆候がある |
| キー/エンドポイント | ポータル上の最新値で簡易 curl を実行 | 正しいはずでも 503/遅延 | 誤ったエンドポイント、キー不一致、リージョン取り違い |
特に「別リージョンに切り替えた瞬間に速く安定した」という結果が出た時点で、優先順位はほぼ決まります。すぐに回避策（リージョン切替）を実施し、並行してステータス確認・サポート連絡に進むのが現実的です。
回避策の本命：別リージョンに新規リソースを作成して切り替える
今回の報告で最も効果が大きかったのが、West Europe から North Europe へ切り替える対応です。エンドポイント例としては、以下のようにドメインが変わります。
- West Europe：
https://westeurope.api.cognitive.microsoft.com/... - North Europe：
https://northeurope.api.cognitive.microsoft.com/...
アプリ設計としては、ここを「コードに直書き」ではなく、環境変数・構成ファイル・Key Vaultなどで差し替え可能にしておくのが鉄則です。障害は「発生するかしないか」ではなく「いつ発生するか」です。
切り替えの実務フロー（止血を最優先する考え方）
- 新リージョンに同等の Computer Vision リソースを作成（例：North Europe）
- 新しいエンドポイントとキーを取得し、アプリ設定に登録
- 同じ入力でスモークテスト（最小限の API 呼び出しで、成功率とレイテンシを確認）
- 段階的にトラフィックを切替（可能なら一部ユーザー/一部ジョブから）
- 監視を見ながら完全切替し、障害中の影響を最小化
「North Europe で正常だった」という事例は、まさにこの止血が効いた形です。復旧を待つ選択肢もありますが、プロダクション影響があるなら、まずは ユーザー体験を戻すことが最優先になります。
| 回避策 | 効果 | メリット | 注意点 | おすすめ度 |
|---|---|---|---|---|
| 別リージョンへ切り替え | 高い（即効性があることが多い） | 復旧待ち不要、安定化が早い | データ所在・レイテンシ・コスト、構成変更の手間 | 最優先 |
| リトライ強化のみで耐える | 中（通る場合は通る） | 構成変更が少ない | 遅延が悪化し続けると詰む。ユーザー体験が悪い | 補助策 |
| 復旧を待つ | 不明（運次第） | 何もしなくてよい | 影響時間が読めない。業務影響が拡大しやすい | 影響が小さい場合のみ |
Azure ステータスページと Service Health で「障害」を見逃さない
障害時に「自分の設定ミスかも」と疑って時間を溶かすのは避けたいところです。そこで有効なのが、Azure status と Service Health（サービス正常性）です。
- Azure status：全体向けの大きな障害・リージョン障害の把握に向く
- Service Health：自分のサブスクリプションに影響があるイベントを追いやすい（影響通知・アラート設計に向く）
見方としては難しくありません。「Azure Cognitive Services」系の項目と、該当リージョン（今回なら West Europe）に 障害 や パフォーマンス低下が出ていれば、原因はアプリ側ではない可能性が高くなります。
「設定ミス」に見える落とし穴：障害と同時にやるべき基本チェック
リージョン障害が濃厚でも、現場では「念のための確認」は必要です。ここを押さえておくと、サポートに連絡する際の情報も揃い、復旧が速くなります。
サブスクリプションとリソース状態
- サブスクリプションが停止・期限切れになっていないか
- Computer Vision リソースが無効化・削除されていないか
- 権限（RBAC）変更で Key Vault や設定参照が失敗していないか
課金・利用制限（クォータ）
- 請求に問題がないか（支払い保留など）
- 呼び出し数・スループットが上限に近づいていないか
- 大量バッチ投入のタイミングと 503 増加が一致していないか
API キーとエンドポイント
- キーを再生成していないか（アプリ側が古いキーを参照していないか）
- エンドポイントが正しいリージョンになっているか
- 最低限の curl で成功するか（SDK の問題切り分け）
とはいえ、今回のように「同リージョンで複数機能が不調」「別リージョンで改善」が揃った場合、ここは “確認” に留め、深追いしすぎないのがポイントです。
すぐ使える確認用リクエスト例：curl で Read の疎通を取る
SDK を疑う前に、まずは最小構成で疎通を取ると切り分けが速くなります。下記はあくまで例です（実際のパスや API バージョンは、利用中の Computer Vision / Image Analysis の仕様に合わせて調整してください）。
# 例：Read (OCR) の非同期開始リクエスト（パスは利用中のAPIに合わせて調整）
curl -sS -D - -o /dev/null -X POST \
"https://northeurope.api.cognitive.microsoft.com/vision/v3.2/read/analyze" \
-H "Ocp-Apim-Subscription-Key: {YOUR_KEY}" \
-H "Content-Type: application/json" \
-d "{\"url\":\"https://example.com/sample.jpg\"}"
レスポンスヘッダーに Operation-Location（または同等のオペレーション URL）が返るタイプなら、次にそれをポーリングして結果を取得します。
# 例：結果のポーリング
curl -sS -X GET \
"{OPERATION_LOCATION}" \
-H "Ocp-Apim-Subscription-Key: {YOUR_KEY}"
障害時は、開始リクエスト自体が 503 になったり、ポーリングがタイムアウトしたり、完了まで異常に時間がかかったりします。同じ入力で West Europe と North Europe を比較すると、原因がどこにあるかがはっきりします。
リトライとタイムアウト設計：503 と “長い遅延” の両方に備える
今回の症状は「503 が増える」だけでなく「成功するが 1〜2 分かかる」が混ざるのが厄介です。つまり、アプリ側は次の 2 点に同時対応する必要があります。
- 503 のような一時エラーはリトライで吸収（ただし無限リトライは禁物）
- 異常に長い応答はタイムアウトで打ち切る（待ち続けるとスレッドやキューが詰まる）
| 設計項目 | 推奨の考え方 | 理由 | やりがちな失敗 |
|---|---|---|---|
| タイムアウト | 「通常時の p95 の数倍」など、根拠を持って決める | 障害時の待ち過ぎはシステム全体を詰まらせる | タイムアウトなしで待ち続け、ワーカー枯渇 |
| リトライ回数 | 少なめから開始し、失敗率と影響を見て調整 | 503 は復旧まで時間がかかることもある | 高回数リトライで自分が負荷を増幅させる |
| バックオフ | 指数バックオフ + ジッター | 同時リトライの集中（スパイク）を避ける | 固定間隔で一斉に叩き続ける |
| 対象ステータス | 503/429/5xx を中心に「一時系」を対象にする | 恒久的な 4xx はリトライしても直らない | 4xx をリトライして無駄に遅くする |
実運用で効く「リトライの落とし穴」対策
- サーキットブレーカー：一定時間 503 が続くなら、その間は呼び出しを抑制して自分のサービスを守る
- キューの保護：OCR ジョブをキューイングする場合、滞留を監視し、閾値で投入量を絞る
- 段階的フォールバック：まず別リージョンへ、次に代替 OCR（簡易）へ、など “段” を用意する
特に「レイテンシが 1〜2 分に伸びる」タイプの障害は、スレッド/コネクション/キューを食い潰します。リトライだけで耐える設計だと、成功しても “遅すぎて使えない” になりがちなので、タイムアウト設計が可用性の一部になります。
監視とアラート：503 が出てから気づくのでは遅い
AI API の障害は「完全停止」より「遅い・不安定」の形で出ることが多く、気づきにくいのが難点です。そこで、次のような監視を入れておくと、障害を早期に検知し、リージョン切替などの判断がしやすくなります。
| 監視項目 | 見るべき指標 | アラート例 | 運用アクション例 |
|---|---|---|---|
| 成功率 | 2xx/202 比率、ジョブ完了率 | 5分移動平均で成功率が急落 | 自動/手動でセカンダリへ切替 |
| エラー率 | 5xx、特に 503 の比率 | 503 が一定件数/割合を超える | サーキットブレーカー発動、投入量制御 |
| レイテンシ | p50/p95/p99、タイムアウト件数 | p95 が通常の数倍に悪化 | タイムアウト短縮、キュー抑制、リージョン切替 |
| 滞留 | キュー長、処理待ち時間 | 滞留が増え続ける | バッチ停止、バックプレッシャー |
監視のコツは「平均」ではなく p95/p99 のような分位を追うことです。今回のように「半分は成功するが、半分は 503」というケースでは、平均だけ見ていると異常が埋もれます。
解決しない場合の最終手段：サポートチケットに載せるべき情報
自分側の設定に問題がなく、Azure status / Service Health からも状況が読み切れない場合は、サポートチケットの起票が現実的な打開策になります。特に Cognitive Services はバックエンドログの調査で一気に進展することがあるため、情報を揃えて投げるのが重要です。
チケットに入れると強い情報（テンプレ化推奨）
- 影響が出ている リソース名 / リソースID / リージョン（West Europe など）
- 発生開始時刻・継続時間（できれば UTC も併記）
- 対象 API（Read / VectorizeText など）、利用している SDK/バージョン、呼び出し方式（同期/非同期）
- 失敗時の HTTP ステータス（503 など）と、返ってくるエラーボディ（可能な範囲で）
- レスポンスヘッダーの Request ID / Correlation ID 相当（取得できるなら非常に有効）
- 再現手順（機密情報を除いた最小構成）と、可能ならサンプル入力
- 「別リージョンでは正常」など、切り分け結果
「どこで」「いつから」「どの API が」「どのくらいの頻度で」「どの ID で失敗しているか」が揃うほど、調査が早くなります。
運用上のポイント：リージョン冗長は “保険” ではなく “前提” にする
今回のように、特定リージョンでだけ不安定になることは珍しくありません。特に業務システムで OCR を中核にしている場合、「復旧を待つ」だけではユーザー影響が大きくなります。そこで、リージョン冗長（フェイルオーバー）を設計に取り込みます。
| 方式 | 概要 | メリット | デメリット | 向いているケース |
|---|---|---|---|---|
| Active/Passive | 普段は主系のみ利用し、障害時に副系へ切替 | コストを抑えやすい、運用が比較的簡単 | 切替の瞬間に手順が必要。副系の劣化に気づきにくい | 月次バッチ/業務処理など、瞬断よりコスト重視 |
| Active/Active | 複数リージョンを常時利用し、分散して処理 | 片系障害でも自動で吸収しやすい。副系の健全性も常に確認できる | コスト増、設計が複雑（データ整合性・ルーティング） | リアルタイム処理、SLA を強く求めるサービス |
| 手動切替のみ | 障害時に運用が設定変更して切替 | 導入が早い | 判断が遅れると影響が拡大。深夜帯に弱い | まずは暫定対応として |
リージョン切替で必ず検討すべき注意点
- データ所在・コンプライアンス：画像や文書を別リージョンへ送ることの社内規定・契約要件（GDPR/社内ポリシーなど）
- ネットワーク遅延：ユーザー拠点とリージョンの距離で、平常時レイテンシが変わる
- コスト：リージョンごとの価格差、二重稼働の費用
- 切替手段：設定値切替で済むのか、ルーティング（Front Door / Traffic Manager 等）が必要か
「障害時に切り替えられる」だけでは足りません。日常的に副系も疎通確認し、いざという時に “確実に動く” 状態を維持しておくことが、運用の品質を決めます。
復旧後にやっておくと次回が楽になるチェックリスト
Microsoft 側で復旧したあとも、何も残さないと次回また同じ混乱が起きます。復旧後は次の観点で “仕組み化” しておくと、障害対応が短時間で終わるようになります。
- ランブック化：リージョン切替の手順、戻し手順、連絡先、判断基準を文書化
- 設定の外出し：エンドポイント/キーをコードに直書きしない（即時切替できる構成へ）
- 監視の閾値見直し：p95 レイテンシと 503 率に基づいてアラート基準を調整
- ポストモーテム：影響時間、影響件数、暫定対応、恒久対応を整理
- 副系の定期テスト：週次/日次で簡易 OCR を投げて健全性を確認
よくある質問：Azure Computer Vision の 503 とレイテンシ悪化
503 が出たら、リトライだけで解決しますか？
一時的に通る場合もありますが、今回のようにレイテンシが 1〜2 分まで伸びるケースでは、リトライだけだと処理待ちが増えて全体が詰まるリスクがあります。タイムアウト設計と、必要なら別リージョンへの切替をセットで考えるのが安全です。
同じ West Europe の別機能も落ちています。何を意味しますか？
同じリージョン内で複数のエンドポイント（例：VectorizeText など）に波及しているなら、個別 API の問題より、リージョン側の負荷・障害の可能性が高まります。まずは Azure status / Service Health 確認と、別リージョンでの再現テストが近道です。
別リージョンに切り替えたら、後で West Europe に戻すべきですか？
状況次第です。復旧後に West Europe が安定しているなら戻す選択肢はありますが、「また同じことが起きる」前提で、戻しも含めて手順化しておくのが重要です。戻す場合も、いきなり全量ではなく、段階的に切り戻して監視しながら進めると安全です。
結局、最短で復旧するコツは何ですか？
①別リージョンで同じリクエストを試す → ②正常なら即切替で止血、この順番が最短です。原因究明は大切ですが、ユーザー影響が出ている間は「まず使える状態に戻す」ことが価値になります。
コメント