AIP生成AIアプリケーションの運用効率と最適化
ある企業がAmazon Bedrock（Claude 3 Sonnet）を使用した社内ヘルプデスクチャットボットを運用しています。トラフィック分析により、平日9〜18時は毎分600〜900リクエスト、それ以外の時間帯は毎分30リクエスト以下という安定したパターンが判明しました。現在はオンデマンド推論を使用しており、ピーク時にスロットリングエラーが頻発し、コストも増大しています。スロットリングを解消しつつコストを最小化するアーキテクチャとして最も適切なものはどれですか？
ABedrock Provisioned Throughputを時間単位で購入し、ピーク時のみ利用してオフピーク時はオンデマンドに切り替える
✓ 正解
平日9〜18時のみピークとなるパターンに対し、時間単位（no-commitment）のProvisioned Throughputをピーク時のみ購入してオフピーク時はオンデマンドに切り替えることで、スロットリングを解消しつつコストを最小化できる。
BLambda の同時実行数上限を引き上げ、オンデマンド推論のリクエストを Amazon SQS でバッファリングして平準化する
SQSでリクエストをバッファリングして平準化しても、BedrockモデルへのRPM制限は変わらないためスロットリングは解消されない。また非同期処理への変更により応答遅延も増大するため不適切。
CAmazon ElastiCache を導入して直近のレスポンスをキャッシュし、同一クエリのBedrock呼び出しを削減する
ヘルプデスクチャットボットは問い合わせ内容が多様で同一クエリが繰り返されにくいためキャッシュヒット率が低く、スロットリング問題の根本的解決にはならない。ElastiCacheの導入・運用コストも余分なオーバーヘッドになる。
DBedrock Provisioned Throughputを1ヶ月単位で最大ピーク（900 req/min）に対応するMU数でコミット購入し、24時間稼働させる
1ヶ月単位でコミットすると平日18時以降や週末のオフピーク時も課金が継続するため、ピーク時間帯のみ時間単位PTを利用する案と比べてコストが大幅に増大し、コスト最小化を達成できない。
解説
Bedrock Provisioned Throughput（PT）は時間単位（no-commitment）と月/6ヶ月単位のコミットを選択できる。ピークが平日9〜18時に限定されるため、時間単位PTをピーク時のみ購入し、オフピーク時はオンデマンドに切り替えることが最もコスト効率が高い。
選択肢BのSQSバッファリングはリクエストを平準化できても処理スループット上限は変わらずスロットリング解消にはならず、遅延も増加します。
選択肢CのElastiCacheによるレスポンスキャッシュはヘルプデスク用途のように問い合わせ内容が多様な場合キャッシュヒット率が低く、スロットリング問題の根本的解決策にはなりません。
選択肢Dの月次コミットはオフピーク時間帯も継続課金されるためコストが増大し、最小化にはなりません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →