AIP生成AIアプリケーションの運用効率と最適化
あるグローバル企業が Amazon Bedrock の Claude を使った対話型アシスタントを単一リージョン（us-east-1）のオンデマンド推論で運用しています。昼のピーク時間帯に瞬間的なリクエスト集中が起き、ModelNotReadyException やスロットリングが散発し、一部ユーザーで応答失敗が発生します。トラフィックは予測しづらくスパイク状で、定常的な需要は中程度です。プロビジョンド契約による固定費は避けたいという制約のもとで、可用性とスループットを高める最適な対応はどれですか。
Aクロスリージョン推論（推論プロファイル）を有効化し、複数リージョンに呼び出しを自動分散してオンデマンド容量を拡張する
✓ 正解
クロスリージョン推論は推論プロファイルにより呼び出しを複数リージョンのオンデマンド容量へ自動ルーティングし、スパイク時の利用可能キャパシティを拡張してスロットリングや ModelNotReadyException を緩和します。固定費なしの従量課金のままで、予測困難なスパイク型に最適です。
Bプロビジョンドスループットを最大ピークに合わせて購入し、すべてのトラフィックを専有モデルユニットで処理する
ピークに合わせてプロビジョンドスループットを購入すれば容量は確保できますが、ピーク基準のモデルユニットを常時保持するため固定費が高額になり、「固定費は避けたい」という制約に明確に反するため不適切です。
CSQS で全リクエストをキューイングし、コンシューマーが順次 InvokeModel を呼ぶことでスパイクを平準化する
SQS によるキューイングはバックエンド負荷の平準化には有効ですが、対話型アシスタントにキューを挟むと応答遅延が大きくなりリアルタイム対話の体験を損ないます。さらにオンデマンド容量自体は増えないため根本解決になりません。
Dより小さいモデルにダウングレードして1リクエストあたりのレイテンシーを下げ、単位時間あたりの処理件数を増やす
小さいモデルへのダウングレードは1件あたりのレイテンシーは下げられても、オンデマンド容量の上限やスロットリングという根本原因は解消されず、出力品質の低下も招きます。可用性向上策として適切ではありません。
解説
Amazon Bedrock のクロスリージョン推論は、推論プロファイルを指定することで単一リクエストを複数リージョンのオンデマンド容量にマネージドで自動ルーティングし、スパイク時に利用可能なキャパシティを拡張してスロットリングや ModelNotReadyException を緩和します。追加の固定費が発生せず従量課金のままで、予測困難なスパイク型トラフィックに対する可用性・スループット向上策として最適です。
選択肢Bのプロビジョンドスループットをピークに合わせて購入する方式は確実に容量を確保できますが、ピークに合わせた固定費が常時かかり「固定費は避けたい」という制約に明確に反します。
選択肢Cの SQS によるキューイングはスループットを平準化できますが、対話型アシスタントにキューを挟むと応答が大幅に遅延し、リアルタイム対話の要件を損ないます。容量自体も増えません。
選択肢Dのモデルダウングレードはレイテンシー改善にはなり得ますが、オンデマンド容量の上限やスロットリングの根本原因を解消せず、出力品質も低下するため適切な解決策ではありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →