Amazon Bedrock と LLM ゲートウェイを用いたレジリエンスパターンの実装

生成 AI ワークロードが実験段階から大規模な本番環境へ移行するにつれ、[大規模言語モデル (LLM)](https://aws.amazon.com/what-is/large-language-model/) の推論に対するレジリエンスパターンの実装は極めて重要です。LLM を活用したアプリケーションがすでに本番稼働している現在、組織は大規模な運用において LLM 推論を高い可用性、応答性、そしてコスト効率で維持する方法を必要としています。静的安定性の確保やバックオフ・リトライの実装といった既存のレジリエンスのベストプラクティスは依然として適用されます。しかし、生成 AI はモデルの可用性、急速に変化するクォータ、複数プロバイダーにわたるトークン制限、および新しくリリースされたモデルとの一貫性維持など、新たな考慮事項をもたらします。[Amazon Bedrock](https://aws.amazon.com/bedrock/) は、クロスリージョン推論といった組み込みのレジリエンス機能を備えたフルマネージド型ファウンデーションモデルを提供しています。 本番環境での推論を設計する際、アーキテクチャ上の意思決定を導くのは通常 4 つの次元です：**可用性**、**応答時間**、**コスト**、そして**スループット**です。可用性とは、モデル、リージョン、またはプロバイダーの障害中も推論を継続して維持することを指します。応答時間は、ユーザーが出力を受け取るまでの速度、具体的には最初のトークン到達時間 (TTFT) および最後のトークン到達時間 (TTLT) として測定されることが多いです。コストは、トークン単位およびリクエスト単位の支出と、ルーティングの決定がこれにどう影響するかを捉えます。スループットは、負荷下でシステムが維持できる同時実行リクエスト数および秒間あたりのトークン数を反映します。 これらの次元は相互に関連しています。例えば、リージョン間ルーティングは可用性とスループットを向上させますが、応答時間が長くなる可能性があります。本記事のパターンは主に**可用性**に焦点を当てており、フェイルオーバー、地理的分散、クォータの分離を通じて推論が稼働し続けることを目指しています。今後の記事では、応答時間の最適化とコスト意識型のルーティングについて詳しく探求していきます。 本記事では、AWS 上で堅牢な生成 AI アプリケーションを構築するための 5 つの実践的なパターンを学びます。これらは、ネイティブの Amazon Bedrock の機能から始まり、LLM ゲートウェイを使用したマルチモデルオーケストレーションへと段階的に進みます。これらのパターンは、予期せぬトラフィック急増時のクォータ枯渇、推論の地理的分散による可用性の最大化、マルチテナント環境におけるノイジーネイバー問題の防止といった、現実世界の課題に対応します。また、インテリジェントなリクエストルーティングを通じてコスト最適化を支援し、特定の要件に基づいて複数のモデルやプロバイダーを使用する柔軟性も提供します。 この「 crawling（這う）、walking（歩く）、running（走る）」アプローチにより、アプリケーションの成熟度と要件に応じてパターンを段階的に導入できます。併せて提供される [GitHub リポジトリ](https://github.com/aws-samples/sample-resilient-llm-inference) には、各パターンの実装を示すコードサンプルが含まれています。 ## 推論レジリエンスパターンへの段階的アプローチ [GitHub リポジトリのこのセクション](https://github.com/aws-samples/sample-resilient-llm-inference?tab=readme-ov-file#testing-all-resilience-patterns)にあるコードサンプルと手順を使用して、ご自身の環境で以下の各パターンをテストすることができます。 ## 前提条件 デモを開始する前に、[前提条件](https://github.com/aws-samples/sample-resilient-llm-inference?tab=readme-ov-file#prerequisites)の手順に従って、適切なソフトウェアがインストールされていることと、AWS アカウントが正しく設定されていることを確認してください。 注記：本記事で示すパターンを実行すると、Amazon Bedrock での推論リクエストや Amazon CloudWatch ログなど、課金が発生する AWS リソースが作成・使用されます。テスト後に継続的な課金を避けるには、「クリーンアップ」セクションを参照してください。 ## パターン 1：Amazon Bedrock を用いたクロスリージョン推論 Amazon Bedrock クロスリージョン推論（CRIS）は、デフォルトで堅牢な推論の基盤を提供するネイティブ機能です。[クロスリージョン推論プロファイル](https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html) を使用することで、スループットの向上、AWS リージョン内でのレート制限（throttling）の発生確率低下、モデルトラフィックの分散が可能になります。CRIS は、トラフィック配分の管理に必要な手作業を不要にし、アプリケーションの可用性を向上させます。これは、可用性、レイテンシ、現在の需要といったリアルタイム要因に基づいて、リクエストをソースリージョンから最適な宛先リージョンへ自動的にルーティングします。これにより、ピーク利用時の予期せぬトラフィックバーストにも対応し、サービスクォータが推論に影響を与える可能性を低減します。 CRIS プロファイルは通常、米国や EU といった特定の地理圏内の商用リージョンに紐付けられており、推論リクエストに対してパフォーマンスとレイテンシの適切なバランスを提供します。このアプローチにより、データ所在（data residency）を地理的境界内に維持したまま、単一リージョンのクォータを超えた集約スループットを実現できます。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/23/ML-19331-1.png) Amazon Bedrock クロスリージョン推論 推論リクエストにおいてより高いレイテンシを許容できる特定のユースケースでは、[グローバル・クロスリージョン推論プロファイル](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html#:~:text=Global%20Claude%20Sonnet%204)を使用するオプションがあります。グローバルプロファイルを使用すると、モデルがグローバル推論のために利用可能な複数の商用リージョン間でリクエストをルーティングできるため、標準的なクロスリージョン推論プロファイルよりもさらに高いスループットを実現できます。 例えば、デモにおいてクロスリージョン推論プロファイルを使用して Amazon Bedrock へ 10 件のリクエストを送信した際、コマンド出力は CRIS がどのようにモデル推論を 3 つの AWS リージョンに自動的に分散させたかを示しています: Region Invocations Percentage us-east-1 1 10% us-east-2 7 70% us-west-2 2 20% *Amazon Bedrock のクロスリージョン推論は、10 件のリクエストを 3 つの AWS リージョンに分散します* ## パターン 2: 複数の AWS アカウントの使用 CRIS は AWS アカウント内でスループットを増幅しますが、追加のスケーリングと分離戦略からも恩恵を受けることができます。AWS アカウントシャーディングは、それぞれが独立したクォータと CRIS プロファイルを持つ複数の AWS アカウント間にリクエストを分散します。 アカウントシャード化は、あるアカウントでの問題が他のアカウントに影響を与えない自然な[障害分離境界](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)を作成するため、ワークロード間の厳格な分離を必要とするマルチチームおよびマルチテナントアーキテクチャにおいて特に価値があります。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/23/ML-19331-2.png) Amazon Bedrock を用いた AWS アカウントシャード化とクロスリージョン推論 アカウントシャード化のデモを実行する際、クロスリージョン推論プロファイルを使用して、設定された 2 つの AWS アカウントそれぞれに 10 件のリクエストを送信します。出力結果は、各アカウントがどのように独立して AWS リージョン間で推論を分散しているかを示しています： Account 1 Region | Invocations | Percentage us-east-2 | 7 | 70% us-west-2 | 3 | 30% Account 2 Region | Invocations | Percentage us-east-1 | 2 | 20% us-east-2 | 3 | 30% us-west-2 | 5 | 50% *CRIS を介して、2 つの AWS アカウントが独立してリクエストをリージョン間で分散* ## LLM ゲートウェイの活用 複雑な本番環境においては、LLM ゲートウェイは、直接 API 呼び出しを行うだけでは実現できないルーティング、フェイルオーバー、ガバナンス機能を提供します。ゲートウェイはアプリケーションと LLM プロバイダーの間でインテリジェントなプロキシとして機能し、統一された抽象化レイヤーを提供することで、複数のベンダーにまたがる多様なモデルを単一の API インターフェイスを通じてアクセス可能にします。この標準化により統合が簡素化されるだけでなく、責任ある AI 対策、監査ログ、自動リトライおよびフォールバックロジック、クォータ管理などの機能が組み込まれ、個々のモデルが利用できなくなった場合でもアプリケーションのレジリエンスを維持するのに役立ちます。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/23/ML-19331-3.png) AWS アカウントおよび外部プロバイダーにわたるリクエストをオーケストレーションする LLM ゲートウェイ ゲートウェイは、複数のモデルやアカウントにまたがるインテリジェントなリクエストルーティングと負荷分散をサポートし、スループットを最大化しながら、レート制限とクォータ管理を実装して各消費者ごとの分離を保証します。これにより、マルチテナント環境における「ノイジー・ネイバー」問題の防止に貢献すると同時に、利用状況分析を通じて包括的なコスト追跡と最適化を実現します。集中型の観測性とモニタリングにより、アプリケーションごとの詳細なインサイトを含む LLM 使用パターンを完全に把握でき、最適化の機会を特定したり、問題を迅速にトラブルシューティングしたりするのに役立ちます。 現在、多くのオープンソースおよび商用の LLM ゲートウェイが存在します。デモでは、これらのパターンを実演するために、ローカルで動作する軽量なオープンソースオプションとして [LiteLLM](https://www.litellm.ai/) を使用しています。大規模展開を行う場合、[AWS のマルチプロバイダー生成 AI ゲートウェイソリューション](https://aws.amazon.com/solutions/guidance/multi-provider-generative-ai-gateway-on-aws/) が参照実装およびアーキテクチャを提供しており、こちらでも LiteLLM を採用しつつ、コンテナ化された [Amazon Elastic Container Service](https://aws.amazon.com/pm/ecs/) (Amazon ECS) または [Amazon Elastic Kubernetes Service](https://aws.amazon.com/pm/eks/) (Amazon EKS) 上でのデプロイ、自動スケーリング、[AWS WAF](https://aws.amazon.com/waf/) による保護、シークレット管理、そして [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) を通じた完全な観測性といった、エンタープライズ向けの機能を追加しています。 ## パターン 3：モデルフォールバック モデル間の自動フェイルオーバーは、プライマリモデルがレート制限に達したりサービス障害を経験したりした場合でも、より高い可用性をサポートします。このパターンは、顧客が定義したプライマリモデルとセカンダリモデルの間でリクエストを自動的にルーティングするように設計されています。フォールバック戦略の焦点がクォータ枯渇ではなく品質とコストの最適化にある場合、[Amazon Bedrock Intelligent Prompt Routing](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-routing.html) がネイティブオプションとして提供されます。これは外部ゲートウェイを必要とせず、各リクエストに対して最も適切なモデルを動的に選択します。プライマリモデルへの呼び出しが失敗した場合、ゲートウェイは自動的にセカンダリモデルを使用してリクエストを再試行し、予期せぬトラフィックの急増時でも高い可用性をサポートします。フォールバック戦略には、コスト最適化とパフォーマンスの考慮も組み込まれており、例えば高コストのモデルをスロットリングし、適切な場合によりコスト効果の高い代替手段にフォールバックするなどです。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/23/ML-19331-4.png) レート制限されたプライマリモデルとより高容量のフォールバックモデルによるフォールバックデモンストレーション デモにおいて、LiteLLM の設定は、1 分あたり 3 リクエストという制限されたレートリミットを持つプライマリモデルと、25 RPM というより高い容量を持つフォールバックモデルを定義しています。クライアントがゲートウェイを通じて 10 の並列リクエストを送信すると、最初の 3 つのリクエストは Amazon Bedrock のプライマリモデルにルーティングされます。プライマリモデルがレートリミットに達すると、LiteLLM は自動的に残りの 7 リクエストをフォールバックモデルへ振り分けます。これにより、10 のリクエストすべてが手動介入やアプリケーションレベルの再試行ロジックなしで正常に完了します。 デモ出力はこのパターンの有効性を確認しており、プライマリモデルのレートリミットにもかかわらず 10 リクエストがすべて正常に完了したことで高い信頼性が示されています。分布状況を見ると、プライマリモデルがクォータに達する前に正確に 3 リストを処理し、残りの 7 リクエストはフォールバックモデルへフェイルオーバーしました。これは、ゲートウェイがインテリジェントなルーティングを通じてサービスの可用性を維持できる能力を示しています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/23/ML-19331-5.png) モデル分布を示すフォールバックデモ出力 ## パターン4：モデル間での負荷分散 負荷分散パターンは、リクエストを複数のモデルインスタンスに分散させることで、リソースの利用率を最適化し、ボトルネックを防ぐ役割を果たします。このアプローチは単に利用率を最大化するだけでなく、必要に応じてモデルインスタンスを追加または削除することで迅速なスケーリングも可能にします。例えば、本番展開前に新しいモデルを評価する際にも、重み付きルーティングやA/Bテスト戦略を実装して、リクエストのほんの一部だけを新しいモデルに割り当て、残りの大部分は実績のあるモデルで処理させることができます。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/23/ML-19331-6.png) プライマリモデル間での負荷分散とフォールバックオーバーフロー 当社の負荷分散デモでは、ゲートウェイがシャッフル戦略を使用して、2つのモデル間で10の並行リクエストを正常に分散しました。ロードバランサーは最初に設定された2つのプライマリモデルそれぞれに3件のリクエストをルーティングし、レート制限に達すると残りの4件を自動的にフォールバックモデルへ転送します。その結果、成功率は100%となり、負荷分散がフォールバック戦略とどのように連携して機能するかを示しています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/23/ML-19331-7.png) 負荷分散デモの出力 ## パターン 5：マルチテナントクォータ分離 マルチテナントクォータ分離パターンは、リクエストを管理するために独自のクォータとレート制限（rate limits）を備えた論理的に隔離された環境を作成します。各消費者に対して独立したレート制限バケットを実装することで、ある消費者からのリクエストが他の消費者のパフォーマンスに悪影響を与える「ノイジーネイバー」課題を防ぐのに役立ちます。各テナントは、他のテナントの使用パターンに関わらず専用クォータを受け取り、公平なリソース割り当てを支援し、消費者間の一貫したサービス品質を維持します。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/23/ML-19331-8.png) 各消費者ごとの独立したレート制限を備えたマルチテナントクォータ分離 このパターンは、複数のアプリケーションがモデルリソースを共有しながらも、予測可能なパフォーマンスと隔離の信頼性を必要とする環境において理想的です。

Amazon Bedrock と LLM ゲートウェイを用いたレジリエンスパターンの実装

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト