AIP生成AIアプリケーションの運用効率と最適化
eコマース企業がus-east-1でAmazon Bedrockを使用した商品レコメンデーションシステムを運用しています。ホリデーセール期間中、on-demandの容量制限によりThrottlingExceptionが多発し、顧客体験が低下しています。Provisioned Throughputの購入は予算制約上困難です。コード変更を最小限に抑えながら複数リージョンの余剰容量を自動活用してスロットリングを低減する方法はどれですか？
ALambdaに指数バックオフとジッターを実装し、ThrottlingExceptionが発生した際に最大10回リトライする
リトライは一時的な障害への緩和策であり、根本的な容量不足の解決にはなりません。ThrottlingExceptionが続く場合、リトライを繰り返しても同一リージョンのエンドポイントを使用するため、スロットリングは解消されません。
Bus-west-2とeu-west-1にも同じLambda関数をデプロイし、Application Load Balancerでラウンドロビン負荷分散することで複数リージョンの容量を活用する
マルチリージョン展開で容量は分散できますが、Lambda関数の複製・ALBの設定・デプロイパイプラインの更新など大幅なアーキテクチャ変更が必要です。コード変更を最小限に抑えるという要件を満たしません。
CBedrockのクロスリージョンInference Profileを使用し、APIコールのmodelIdをクロスリージョンプロファイルIDに変更する
✓ 正解
クロスリージョンInference Profileにより、単一のAPIコールで自動的に複数リージョンの余剰容量を活用できます。既存コードのmodelIdをプロファイルIDに変更するだけで実装でき、スロットリング問題を効果的に解決します。
DAWS Global AcceleratorをBedrock APIエンドポイントの前段に配置し、地理的に最も近いリージョンへトラフィックを自動ルーティングする
AWS Global AcceleratorはEC2・NLB・ALBなどのサービスを対象とするものであり、Bedrock APIエンドポイントとは統合されていません。BedrockのアクセスにGlobal Acceleratorを使用することはできません。
解説
Amazon BedrockのクロスリージョンInference Profileは、単一APIエンドポイントで複数リージョンに自動分散し、特定リージョンの容量が逼迫した際に他のリージョンの余剰容量を活用します。変更箇所はmodelIdパラメータをクロスリージョンプロファイルID（usプレフィックス付き）に変更するだけで、アーキテクチャの大幅な変更は不要です。
選択肢Aのリトライは容量問題の根本解決になりません。ThrottlingExceptionが発生してもリトライを繰り返すだけで、利用可能な容量自体は増えないため、高負荷時の問題は解消されません。
選択肢BのマルチリージョンLambda+ALBはコード変更を最小限に抑えるという要件を満たさず、Lambda関数の複製やALBの設定など運用複雑性が大幅に増加します。
選択肢DのGlobal AcceleratorはBedrock APIとは統合されていません。BedrockエンドポイントはGlobal Acceleratorの対象サービスではないため、この構成は機能しません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →