レジリエントな API（バックオフ・レート制限・フォールバック・ルーティング）｜基礎を学ぶ

このレッスンで学ぶこと 対応試験ドメイン D2 タスク 2.4.3・2.4.4（レジリエントな API 統合）。基盤モデル呼び出しのスロットリング・障害に耐える設計を、AWS SDK の指数バックオフ+ジッター、Amazon API Gateway のレート制限、フォールバックモデル/リージョンへのルーティング、AWS X-Ray による可観測性の観点で判断できるようになります。

解説

基盤モデルの呼び出しは、スロットリング（ThrottlingException）・一時的エラー・リージョン障害などに直面します。本番品質の GenAI API には、これらに耐えるレジリエンス設計が必須です。試験では「どの障害に、どの仕組みで備えるか」が問われます。

指数バックオフとジッター（再試行）

一時的なスロットリングやエラーには、すぐ再試行せず待ち時間を指数的に伸ばしながらリトライします。さらにジッター（ランダムなゆらぎ）を加えて、多数のクライアントが同時に再試行して再びスロットルされる「リトライ津波」を防ぎます。AWS SDK は標準でリトライ機構を持ち、retries の max_attempts と mode（standard/adaptive）で制御できます。

レート制限（自分が出す側 / 受ける側）

レート制限には 2 つの向きがあります。考え方は下記のとおりです。

向き	目的	仕組み
受ける側（自 API への流入制御）	自分の GenAI API を守る	Amazon API Gateway のスロットリング・使用量プラン
出す側（Bedrock への呼び出し制御）	上流クォータを超えない	クライアント側レート制限、キューによる平滑化、プロビジョンドスループット

API Gateway のスロットリングと使用量プランで、クライアントごとの呼び出し量に上限を設けてバックエンドと上流の FM を守ります。

フォールバックとルーティング

特定モデルがスロットルされたり一時的に使えないとき、別モデルや別リージョンへフォールバックして可用性を保ちます。AWS Step Functions の Catch/Retry で「主モデルで失敗したら代替モデルへ」というフォールバックを宣言的に組めます。Amazon Bedrock のクロスリージョン推論を併用すれば、リージョン単位の容量逼迫にも耐えられます。

可観測性（AWS X-Ray）

レジリエンス施策が効いているかは、可観測性なしには判断できません。AWS X-Ray で分散トレースを取り、どの呼び出しが遅いか・どこでリトライやフォールバックが発生したかを可視化します。これにより、ボトルネックや障害の伝播を特定できます。

コード例（SDK のリトライ設定）

boto3 の標準リトライ（指数バックオフ）を設定する最小例です。

Python

import boto3
from botocore.config import Config

cfg = Config(retries={"max_attempts": 5, "mode": "adaptive"})
bedrock = boto3.client("bedrock-runtime", config=cfg, region_name="us-east-1")

resp = bedrock.converse(
    modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
    messages=[{"role": "user", "content": [{"text": "要約して"}]}],
)

試験で問われるポイント

バックオフにはジッターを足す。固定間隔の即時リトライや、ジッターなしの一斉リトライは「リトライ津波」を起こすアンチパターン。指数バックオフ + ジッターが正解
レート制限の向きを区別。自 API への流入制御は Amazon API Gateway のスロットリング/使用量プラン、上流 Bedrock クォータ超過の防止はクライアント側制御やキュー平滑化
フォールバックは別モデル/別リージョン。Step Functions の Catch/Retry や Bedrock クロスリージョン推論で可用性を確保
可観測性は X-Ray。リトライ・フォールバックが効いているか、どこが遅いかを分散トレースで可視化。CloudWatch メトリクスと併用
スロットリングは「無限リトライ」ではなく「バックオフ + 上限 + 必要なら回路ブレーカー/フォールバック」で扱う

サービスの使い分け早見表

やりたいこと	使うもの	混同しやすいもの
一時エラー/スロットルの再試行	AWS SDK の指数バックオフ + ジッター	即時・固定間隔リトライ（津波を招く）
自 API への流入を制限	Amazon API Gateway スロットリング/使用量プラン	クライアント側レート制限（出す側の制御）
主モデル障害時の切替	フォールバック（Step Functions Catch/Retry、別モデル/リージョン）	単なるリトライ（同じ宛先を再試行するだけ）
呼び出しの遅延/障害を可視化	AWS X-Ray（分散トレース）	CloudWatch 単体（メトリクスは取れるがトレースは X-Ray）

まとめ

レジリエントな FM API は、指数バックオフ + ジッターでスロットルに耐え、Amazon API Gateway のレート制限で自 API と上流クォータを守り、AWS Step Functions の Catch/Retry や Amazon Bedrock クロスリージョン推論で別モデル/別リージョンへフォールバックし、AWS X-Ray で施策の効果を可視化します。即時・一斉リトライや単なる無限リトライはアンチパターンとして区別するのが試験の要点です。

次のステップ

次のクイズレッスンで、バックオフ・レート制限・フォールバック・可観測性の使い分けを問うシナリオ問題に挑戦しましょう。