Amazon Bedrock と LLM ゲートウェイを使用したレジリエンスパターンの実装
この投稿では、AWS 上でレジリエントな生成 AI アプリケーションを構築するための5つの実用的なパターンを学びます。これらは、ネイティブの Amazon Bedrock 機能から LLM ゲートウェイを使用したマルチモデルオーケストレーションへと進みます。これらのパターンは、予期しないトラフィック急増時のクォータ枯渇、推論の地理的分散による可用性の最大化、マルチテナント環境におけるノイジーネイバー問題の防止などの現実的な課題に対処します。
大規模言語モデル（LLM）推論のレジリエンスパターンを実装することは、生成 AI ワークロードが実験段階から本番環境に移行するにつれて重要になります。LLM を活用したアプリケーションが現在本番環境で稼働しており、組織は LLM 推論を高可用性、応答性、コスト効率よく維持する方法を必要としています。既存のレジリエンスのベストプラクティス（静的安定性やバックオフとリトライの実装など）は引き続き有効です。しかし、生成 AI は、モデルの可用性、急速に変化するクォータ、複数プロバイダーにわたるトークン制限、新しくリリースされたモデルとの一貫性維持など、新たな考慮事項を導入します。Amazon Bedrock は、クロスリージョン推論などのレジリエンス機能を組み込んだ、完全マネージド型の基盤モデルを提供します。
本番環境向けに推論を設計する場合、通常4つの次元がアーキテクチャ上の意思決定を導きます：可用性、応答時間、コスト、スループットです。可用性とは、モデル、リージョン、またはプロバイダーの障害時に推論を維持することを指します。応答時間は、ユーザーが出力を受け取る速度をカバーし、多くの場合、最初のトークンまでの時間（TTFT）と最後のトークンまでの時間（TTLT）で測定されます。コストは、トークンあたりおよびリクエストあたりの支出と、ルーティングの決定がそれに与える影響を捉えます。スループットは、システムが負荷下で処理できる同時リクエスト数と1秒あたりのトークン数を反映します。
これらの次元は相互に関連しています。例えば、クロスリージョンルーティングは可用性とスループットを向上させますが、応答時間が増加する可能性があります。この投稿のパターンは主に可用性に焦点を当てています：フェイルオーバー、地理的分散、クォータ分離によって推論を運用し続けることです。今後の投稿では、応答時間の最適化とコスト認識型ルーティングについて詳しく説明します。
この投稿では、AWS 上でレジリエントな生成 AI アプリケーションを構築するための5つの実用的なパターンを学びます。これらは、ネイティブの Amazon Bedrock 機能から LLM ゲートウェイを使用したマルチモデルオーケストレーションへと進みます。これらのパターンは、予期しないトラフィック急増時のクォータ枯渇、推論の地理的分散による可用性の最大化、マルチテナント環境におけるノイジーネイバー問題の防止などの現実的な課題に対処します。また、インテリジェントなリクエストルーティングによるコスト最適化をサポートし、特定の要件に基づいて複数のモデルとプロバイダーを使用する柔軟性を提供します。
このクロール・ウォーク・ランのアプローチにより、アプリケーションの成熟度と要件に応じてパターンを段階的に採用できます。付属の GitHub リポジトリには、各パターンを実演するコードサンプルが含まれています。
推論レジリエンスパターンの段階的アプローチ
GitHub リポジトリのこのセクションのコードサンプルと手順を使用して、独自の環境で以下の各パターンをテストできます。
前提条件
デモを開始する前に、適切なソフトウェアがインストールされ、AWS アカウントが正しく設定されていることを確認してください。
注意：この投稿のパターンに従うと、Amazon Bedrock 推論リクエストや Amazon CloudWatch ログなど、AWS リソースを作成して使用し、費用が発生します。テスト後の継続的な課金を避けるには、クリーンアップセクションを参照してください。
パターン1: Amazon Bedrock クロスリージョン推論の使用
Amazon Bedrock クロスリージョン推論（CRIS）は、デフォルトでレジリエントな推論の基盤を提供するネイティブ機能です。クロスリージョン推論プロファイルを使用すると、スループットを向上させ、AWS リージョン内でスロットルされる可能性を減らし、モデルトラフィックを分散できます。CRIS は、トラフィック分散の手動管理を排除し、アプリケーションの可用性を向上させます。可用性、レイテンシー、現在の需要などのリアルタイム要因に基づいて、リクエストをソースリージョンから最適な宛先リージョンに自動的にルーティングします。これにより、ピーク使用時の予期しないトラフィックの急増に対応し、サービス割り当てが推論に影響を与える可能性を減らします。
CRIS プロファイルは通常、米国や EU などの特定の地域内の商用リージョンに結びついており、推論リクエストにパフォーマンスとレイテンシーの適切なバランスを提供します。このアプローチは、地理的境界内でデータレジデンシーを維持しながら、単一リージョンの割り当てを超える総スループットを増加させます。
推論リクエストのレイテンシーが高くても許容できる特定のユースケースでは、グローバルクロスリージョン推論プロファイルを使用するオプションがあります。グローバルプロファイルを使用すると、リクエストをモデルが利用可能な複数の商用リージョンにルーティングしてグローバル推論を行うことができ、標準のクロスリージョン推論プロファイルよりもさらに高いスループットを提供します。
例えば、デモでクロスリージョン推論プロファイルを使用して Amazon Bedrock に10件のリクエストを送信すると、コマンド出力は CRIS がモデル推論を3つの AWS リージョンに自動的に分散したことを示します：
| リージョン | 呼び出し数 | パーセンテージ | |------------|------------|----------------| | us-east-1 | 1 | 10% | | us-east-2 | 7 | 70% | | us-west-2 | 2 | 20% |
パターン2: 複数の AWS アカウントの使用
CRIS は単一の AWS アカウント内でスループットを倍増させますが、追加のスケールと分離戦略からメリットを得ることができます。AWS アカウントシャーディングは、独立した割り当てと CRIS プロファイルを持つ複数の AWS アカウントにリクエストを分散します。
アカウントシャーディングは、あるアカウントの問題が他のアカウントに影響を与えない自然な障害分離境界を作成し、厳格なワークロード分離を必要とするマルチチームおよびマルチテナントアーキテクチャにとって特に価値があります。
アカウントシャーディングのデモを実行すると、クロスリージョン推論プロファイルを使用して、設定された2つの AWS アカウントのそれぞれに10件のリクエストを送信します。出力は、各アカウントが独立してリージョン間で推論を分散する方法を示します：
アカウント1 | リージョン | 呼び出し数 | パーセンテージ | |------------|------------|----------------| | us-east-2 | 7 | 70% | | us-west-2 | 3 | 30% |
アカウント2 | リージョン | 呼び出し数 | パーセンテージ | |------------|------------|----------------| | us-east-1 | 2 | 20% | | us-east-2 | 3 | 30% | | us-west-2 | 5 | 50% |
LLM ゲートウェイの使用
複雑な本番シナリオでは、LLM ゲートウェイは直接 API 呼び出しでは不可能なルーティング、フェイルオーバー、ガバナンス機能を提供します。ゲートウェイは、アプリケーションと LLM プロバイダー間のインテリジェントなプロキシとして機能し、統一された抽象化レイヤーを提供するため、単一の API インターフェースを介して複数のベンダーのさまざまなモデルにアクセスできます。この標準化により、統合が簡素化されると同時に、責任ある AI の保護、監査ログ、自動リトライとフォールバックロジック、クォータ管理などの機能が組み込まれ、個々のモデルが利用できなくなった場合でもアプリケーションの回復力を維持できます。
ゲートウェイは、複数のモデルとアカウントにわたるインテリジェントなリクエストルーティングと負荷分散をサポートし、コンシューマーごとの分離を備えたレート制限とクォータ管理を実装してスループットを最大化し、マルチテナント環境でのノイジーネイバー問題を防ぐのに役立ちます。また、使用状況分析を通じて包括的なコスト追跡と最適化を提供します。集中型の可観測性とモニタリングにより、LLM 使用パターンを完全に可視化し、アプリケーションごとの詳細な洞察を提供して、最適化の機会を特定し、問題を迅速にトラブルシューティングできるようにします。
現在、多くのオープンソースおよび商用 LLM ゲートウェイが利用可能です。デモでは、LiteLLM を軽量なオープンソースオプションとしてローカルで実行し、これらのパターンを実演しています。大規模にデプロイする場合、AWS マルチプロバイダー生成 AI ゲートウェイソリューションは、LiteLLM も使用するリファレンス実装とアーキテクチャを提供しますが、Amazon Elastic Container Service（Amazon ECS）または Amazon Elastic Kubernetes Service（Amazon EKS）でのコンテナ化されたデプロイメント、自動スケーリング、AWS WAF 保護、シークレット管理、Amazon CloudWatch による完全な可観測性などのエンタープライズ機能を追加します。
パターン3: モデルフォールバック
モデル間の自動フェイルオーバーは、プライマリモデルがレート制限に達したり、サービス中断が発生した場合でも、高い可用性をサポートします。このパターンは、顧客が定義したプライマリモデルとセカンダリモデル間でリクエストを自動的にルーティングするように設計されています。フォールバック戦略がクォータ枯渇ではなく品質とコストの最適化に重点を置いている場合、Amazon Bedrock Intelligent Prompt Routing はネイティブオプションを提供します。外部ゲートウェイを必要とせずに、各リクエストに最も適したモデルを動的に選択します。プライマリモデルへの呼び出しが失敗した場合、ゲートウェイは自動的にセカンダリモデルを使用してリクエストを再試行し、予期しないトラフィックの急増時でも高い可用性をサポートします。フォールバック戦略には、コスト最適化とパフォーマンスの考慮事項も組み込まれています。例えば、高コストモデルをスロットルし、適切な場合にはよりコスト効率の高い代替モデルにフォールバックします。
デモでは、LiteLLM 構成は、制限的なレート制限（1分あたり3リクエスト、RPM）を持つプライマリモデルと、より高い容量（25 RPM）を持つフォールバックモデルを定義します。クライアントがゲートウェイを介して10件の同時リクエストを送信すると、最初の3つのリクエストは Amazon Bedrock のプライマリモデルにルーティングされます。プライマリモデルがレート制限に達すると、LiteLLM は自動的に残りの7つのリクエストをフォールバックモデルに転送します。10件のリクエストは、手動介入やアプリケーションレベルのリトライロジックなしで正常に完了します。
デモ出力はこのパターンの有効性を確認し、プライマリモデルのレート制限にもかかわらず10件のリクエストが正常に完了したことを示しています。分布は、ちょうど3件のリクエストがクォータに達する前にプライマリモデルによって処理されたことを示しています。残りの7件のリクエストはフォールバックモデルにフェイルオーバーし、インテリジェントなルーティングを通じてサービス可用性を維持するゲートウェイの能力を示しています。
パターン4: モデル間の負荷分散
負荷分散パターンは、リクエストを複数のモデルインスタンスに分散してリソース利用を最適化し、ボトルネックの防止に役立ちます。このアプローチは利用率を最大化するだけでなく、必要に応じてモデルインスタンスを追加または削除することで迅速にスケーリングできます。例えば、新しいモデルを完全にデプロイする前に評価する場合、重み付けルーティングや A/B テスト戦略を実装して、新しいモデルにリクエストのごく一部のみを向け、大部分は引き続き実績のあるモデルを使用できます。
負荷分散デモでは、ゲートウェイはシャッフル戦略を使用して10件の同時リクエストを2つのモデルに正常に分散します。ロードバランサーは最初に、設定された2つのプライマリモデルにそれぞれ3件のリクエストをルーティングし、レート制限に達すると、残りの4件のリクエストは自動的にフォールバックモデルにリダイレクトされます。結果は100%の成功率であり、負荷分散がフォールバック戦略とどのように連携するかを示しています。
パターン5: マルチテナントクォータ分離
マルチテナントクォータ分離パターンは、マルチテナント環境でのリクエストを管理するために、独自のクォータとレート制限を持つ論理的に分離された環境を作成します。コンシューマーごとに独立したレート制限バケットを実装することにより、このパターンは、あるコンシューマーからのリクエストが他のコンシューマーのパフォーマンスに悪影響を与える「ノイジーネイバー」問題の防止に役立ちます。各テナントは、他のテナントの使用パターンに関係なく専用のクォータを受け取り、公平なリソース割り当てをサポートし、コンシューマー全体で一貫したサービス品質を維持します。
このパターンは、複数のアプリケーションがモデルリソースを共有する環境に最適です。