AgentCore GatewayがInvokeModelに対応、フォールバックルーティングを追加
ゲートウェイがAmazon Bedrockの推論API 2種類を受け付けるようになり、設定した条件に応じてトラフィックを別のモデル提供先に転送できるようになりました。この変更は中国を除く、対応するAWSリージョンで利用できます。
ゲートウェイの推論エンドポイントが、InvokeModelとInvokeModelWithResponseStreamに対応しました。1
ゲートウェイルールでは、代替の宛先と、スロットリング、サーバーエラー、応答タイムアウトなどのフォールバックを開始する条件を指定できます。1
これらの機能は、中国リージョンを除き、AgentCore Gatewayが提供されているすべてのリージョンで利用できます。1
経緯
AgentCore Gatewayの変更点Amazon Bedrock AgentCore Gatewayは、推論エンドポイントでInvokeModel APIとInvokeModelWithResponseStream APIに対応し、エンドポイントが処理できるリクエストの範囲を広げました。1 また、推論リクエストのフォールバックルーティングも利用できるようになりました。主な送信先で処理できない場合、トラフィックを別のモデルやプロバイダーに転送できます。1 この2つは関連する変更です。APIへの対応により既存のBedrock SDK連携からゲートウェイを利用できるようになり、フォールバックにより、指定した問題が発生した際に送信先を切り替える方法を設定できます。1 発表では、今回の追加機能が影響するトラフィック量やユーザー数の数値は示されていません。明示されている範囲は、API機能、ルーティング動作、リージョンでの提供状況です。1
APIの変更は、推論を呼び出す2つの方法、InvokeModelとInvokeModelWithResponseStreamに関するもので、どちらもゲートウェイの推論エンドポイント経由で利用できます。1 すでにAmazon Bedrock SDKを利用している連携では、クライアントコードを書き換えなくても、ゲートウェイを送信先として利用できます。1 説明されているエンドポイントを通じて、クライアント連携を変更せずに、統制された単一のゲートウェイ送信先からモデルプロバイダーに接続できます。1 この点から、API対応とフォールバックの実際的な違いが分かります。前者は既存のSDKクライアントがプロバイダーにアクセスする方法に関わり、後者は主な送信先で設定された問題が発生した場合にリクエストをどこへ送るかに関わります。1
フォールバック動作は、代替送信先を指定した順序で列挙するゲートウェイルールから始まります。1 このルールでは、スロットリング、サーバーエラー、応答タイムアウトなど、主な送信先から切り替える条件も指定します。1 したがって、ゲートウェイのルーティング動作は、順序付けられた代替送信先とルールに入力されたトリガー条件の両方に基づき、指定されていない送信先選択によるものではありません。1 より広い説明では、容量不足や主な送信先に到達できないことも、リクエストを別の場所にルーティングできる状況として挙げられています。1
条件に該当する事象が発生すると、フォールバックはリクエストを主な送信先だけにとどめず、代替のモデルやプロバイダーへ送ります。1 組み込みのサーキットブレーカーは、現在障害が発生している送信先を回避します。これにより、リクエストを稼働中の送信先に早く到達させ、障害中の送信先を試すことで生じる余分な遅延を避けられます。1 このブレーカーは、設定されたフォールバックチェーンと連携します。ルールが代替送信先と条件を定め、ブレーカーが障害中と特定された送信先をスキップします。1 送信先をスキップする目的は、すでに障害が発生している送信先への試行によるレイテンシーを加えずに、正常な送信先へより早く到達することです。1
クライアントから見ると、フォールバックは個別のリクエストと応答の連続としては現れません。内部で再試行が行われても、クライアントは1つのリクエストを送り、1つの応答を受け取ります。1 このクライアント向けの動作は、設定されたチェーン内で再試行や送信先の切り替えを含むことがある内部ルーティング処理とは異なります。1 発表ではフォールバックはクライアントに対して透過的と説明されていますが、内部再試行がないとは述べていません。むしろ、再試行が行われる場合を明示的に想定しています。1 対応APIを使う連携では、リクエスト1回・応答1回という説明の動作に加え、統制されたゲートウェイエンドポイントを通じてモデルプロバイダーにアクセスできます。1
対象となるクライアント連携として説明されているのは、モデルプロバイダーにアクセスするために呼び出し先をゲートウェイにできる、既存のAmazon Bedrock SDK連携です。1 発表によると、そのアクセスにゲートウェイを利用するために、これらの連携のクライアントコードを書き換える必要はありません。1 対応するAPI呼び出しとゲートウェイのルーティング機能は示されていますが、それらを利用する連携、リクエスト、モデル、プロバイダーの数は示されていません。1 したがって、変更の規模は追加された2つのAPIとフォールバック機能によって説明されており、ユーザー数や推論トラフィックの合計は報告されていません。1
発表では、主な送信先でスロットリングが発生した場合、容量が不足した場合、または到達できなくなった場合への自動対応として、フォールバックを紹介しています。1 より具体的な設定方法では、代替ルートを開始する条件として、スロットリング、サーバーエラー、応答タイムアウトが挙げられています。1 これらの説明から、対処するサービス上の問題の種類とルールの役割の両方が分かります。ルールの条件に該当すると、システムはあらかじめ選択された代替送信先に従います。1 発表に関する事実には、公式関係者の氏名や直接の引用は含まれていないため、明示された製品の動作に基づいてのみ変更を説明できます。1
提供状況はリージョン別に説明されており、AgentCore Gatewayが利用可能なすべてのAWSリージョンで、今回の2つの新機能を利用できます。ただし、中国のリージョンは除きます。1 この提供範囲は今回発表された機能に適用されますが、対象リージョンの数は示されていません。1 リージョンに関する条件は、APIとルーティングの説明を読む際に重要です。これらの説明によって、中国を除くという明示された例外がなくなるわけではありません。1 したがって、発表では、中国を除き、AgentCore Gatewayの既存の提供地域を基準に利用可能な範囲を定めており、すべてのリージョンで利用できるとはしていません。1
総合すると、今回の追加により、対応するBedrock SDKクライアントは指定された推論APIでゲートウェイを利用でき、指定条件が発生した場合には設定済みの代替先へルーティングできます。1 サーキットブレーカーと、クライアントに透過的な応答パターンは、複数回のやり取りをクライアントに示すことなく、フォールバック処理が障害中の送信先や内部再試行にどう対処するかを説明しています。1 これらの詳細は変更の運用上の範囲を説明するものであり、可用性、レイテンシー、その他の結果に測定可能な改善があったことを示すものではありません。1 より広い文脈として示されているのは、モデルプロバイダーへのアクセスを統制するゲートウェイです。新しいAPI機能とフォールバック機能は、中国以外でそのゲートウェイが提供されているリージョンに限られます。1
影響
段階を追って外へ広がる影響- 第 1 段階既存のSDK連携
既存のAmazon Bedrock SDK連携では、クライアントコードを書き換えることなく、ゲートウェイを介してガバナンスが適用されたエンドポイントからモデルプロバイダーにアクセスできます。1
事実 - 第 2 段階推論のルーティング
設定された条件に該当する場合、フォールバックによってリクエストを代替モデルまたはプロバイダーにルーティングできます。サーキットブレーカーは、現在障害が発生している宛先をスキップします。1
事実 - 第 3 段階クライアントの利用体験
フォールバックはクライアントからは透過的です。内部で再試行が行われる場合でも、送信されるリクエストは1回、受信する応答も1回です。1
事実 - 第 4 段階想定される運用上の効果
[仮説] InvokeModelへの対応とフォールバックの組み合わせにより、コードを変更せずに可用性の向上やレイテンシーの低減が期待できる可能性があります。ただし、発表では測定された効果は報告されていません。
分析
情報源
各情報源が裏付ける内容この記事は下記の情報源をもとに AI が書きました。各事実は原文と一字一句照合し、推測と分析は区別して示しています。 書き方について