現場で泣かないための「429 Too Many Requests」攻略：Microsoft Graph APIとCASBの仁義なき戦い
ネットワークの最前線で戦うエンジニア諸君、今日もパケットの荒波を乗りこなしているだろうか。
ゼロトラスト全盛の今、SASEやCASBはもはや「あれば便利」なツールではなく、企業の生命線を守る防波堤だ。特に、Microsoft 365の監査ログをCASBが吸い上げる際、避けて通れないのが「APIレートリミット」という名の壁である。
「なぜかログが歯抜けになる」「監視ダッシュボードが真っ赤に染まる」。その原因の多くは、Microsoft Graph APIから返される無慈悲な 429 Too Many Requests エラーだ。今日は、この泥臭いトラブルをスマートに捌くための「攻めの守り方」を伝授しよう。
—
なぜ「429」は現場のエンジニアを苦しめるのか？
Microsoft Graph APIは、公平なリソース利用のために非常に厳格なスロットリング（帯域制限）を設けている。CASBが広大なテナントのログをポーリングする際、大量のHTTPリクエストを短時間に投げつけると、APIゲートウェイは即座に「お前は喋りすぎだ」と遮断してくる。
ここで重要なのが、429 ステータスコードと共に返される Retry-After ヘッダーだ。多くのエンジニアが見落としがちだが、この値こそが「次にいつなら通信していいか」を教える唯一の救いの手である。
標準的な通信シーケンス
1. Request: CASBが GET /auditLogs/signIns を投げる。
2. Response (429): 「少し落ち着け」という警告と、Retry-After: 30（秒）といった情報が返る。
3. Backoff: クライアント側で待機時間を計算し、その間はリクエストを停止する。
4. Retry: 待機時間経過後に再送。
この「バックオフ制御」を実装していない監視ツールやスクリプトは、ただひたすら再送を繰り返し、ブラックリスト入りする未来しか待っていない。
—
実践：指数バックオフによるエレガントなリトライ
ただ待機するだけでは素人だ。ネットワークの世界では「指数バックオフ（Exponential Backoff）」が定石。リトライのたびに待機時間を倍々に増やしていくことで、サーバー側の負荷を下げつつ、確実に成功率を上げる手法だ。
Pythonの requests ライブラリを使った、現場でそのまま使える実装例を挙げておこう。
import requests
import time
def fetch_logs_with_backoff(url, headers):
max_retries = 5
for i in range(max_retries):
response = requests.get(url, headers=headers)
# 正常終了
if response.status_code == 200:
return response.json()
# 429が発生した場合のハンドリング
elif response.status_code == 429:
# Retry-Afterヘッダーを優先、なければ指数関数的に待機
wait_time = int(response.headers.get("Retry-After", 2 ** i))
print(f"スロットリング発生。{wait_time}秒間待機します...")
time.sleep(wait_time)
continue
else:
response.raise_for_status()
raise Exception("最大リトライ回数を超過しました。")—
CASB運用における3つの鉄則
コードだけでなく、インフラ運用者として意識しておくべき「現場の知恵」を3つ共有する。
1. Retry-After ヘッダーを正しく解釈せよ
API仕様書に書かれている通り、Retry-After は秒数で返ることもあるし、HTTPの日付形式で返ることもある。これを適切にパースするロジックを入れないと、思わぬ長時間待機や、逆に短すぎる再送間隔で再び 429 を食らうことになる。
2. ログ収集の「粒度」と「頻度」を見直す
CASB側の設定でポーリング間隔を極限まで短くしていないだろうか？ 監査ログは数秒の遅延が許容されるケースが多い。監視の目的を再定義し、収集の間隔を広げることで、そもそも 429 を発生させない構成にするのが究極の最適化だ。
3. APIの使用状況を可視化せよ
Microsoft 365 管理センターや Graph Explorer を使い、現在どの程度のクォータを消費しているかを確認する習慣をつけよう。特に大規模テナントでは、CASB以外にも自作の運用自動化ツールがAPIを叩いていて、知らぬ間に競合しているケースが多々ある。
—
最後に：ネットワークは「対話」である
APIとの対話は、人間関係と同じだ。一気に要求を叩きつけるのではなく、相手（Microsoftのサーバー）の状況を推し量り、相手が「今は忙しい」と言えば引き下がり、「準備ができた」と合図があれば進む。
この「謙虚な通信」こそが、堅牢なゼロトラスト環境を構築するエンジニアの条件である。
もし今、ログの欠損に悩んでいるのなら、まずはパケットキャプチャやログを確認し、429 の頻度と Retry-After の値を眺めてみてほしい。そこには、ネットワークという巨大なシステムとの対話のヒントが隠されているはずだ。
諸君のインフラが、今日も安定して稼働することを願っている。現場からは以上だ。
コメント