マイクロサービスの原則を用いてステートフルな AI エージェント API をスケーリングする

AI エージェントが実験的なプロトタイプから本番システムへと移行するにつれ、エンジニアは従来の Web アーキテクチャでは対処が難しいスケーリングの課題に直面しています。人間のユーザーとは異なり、エージェントは複数のサーバーレプリカ間で一貫したコンテキストを必要とする、高速でステートフルなリクエストのバーストを生成します。最近の技術分析では、古典的なマイクロサービスパターン（特にステートレス性、バルクヘッド、スマートエンドポイント）を適用することで、車輪の再発明をせずにこれらの摩擦点を解消できることが示されています。

何が起きたか

多くの最新の AI アプリケーションは、マルチターン会話管理のために OpenAI 互換 API などの構造化されたプロトコルに依存しています。これらのインターフェースは単一レプリカのセットアップではうまく機能しますが、水平スケール時には失敗することがよくあります。典型的な概念実証ベンチマークでは、1 台のマシンで実行されるモノリシックな API は、ゼロのコンテキスト喪失で 800 ターンを処理しました。しかし、同じシステムをロードバランサーの背後にある 3 台のマシンに分散させた場合、インタラクションの 75 パーセントでコンテキストが失われました。モデルは HTTP 200 ステータスコードで応答を続けましたが、リクエストがローカル状態を保持していないサーバーに届いたため、回答に必要な会話履歴が含まれていませんでした。

根本原因は、エージェントトラフィックと標準的な Web トラフィックとの基本的な違いにあります。エージェントループはステートフルですが、各 HTTP リクエストは独立しています。スティッキーセッションや永続的な共有ストレージがない場合、これらのリクエストをレプリカ間に分散させると会話のスレッドが断ち切れます。さらに、エージェントはマックスピードで動作し、ターン間の思考時間がほとんどないワークのバーストを生成します。エラー発生時に積極的に再試行を行うことも多く、これは下流の依存関係への圧力を増幅させる可能性があります。これらの特性により、従来のステートフルな設計では効率的に吸収できない負荷形状が生まれます。

これに対処するため、分析では 2010 年代のマイクロサービス文献の原則を用いて、エージェントフレンドリーな API を再構築することを提案しています。アプリケーションをゲートウェイ、メモリサービス、ツールサービスに分解することで、開発者は障害ドメインを隔離できます。ゲートウェイは状態を保持せずに OpenAI プロトコルを処理し、メモリサービスは会話履歴と監査ログを所有します。この分解により、各コンポーネントは独立してスケーリングでき、特定の並行制御を適用できるようになり、重いツール使用が標準的なチャット補完をブロックしないように保証されます。

仕組み

提案されたアーキテクチャは、ステートレス性、バルクヘッド、収束データストレージという 3 つのコアメカニズムに依存しています。ステートレス性は、会話状態をアプリケーションプロセスから共有ストアへ移動することを保証します。これにより、任意のレプリカが任意の会話の任意のターンを提供できるようになり、セッションスティッキー性が不要になります。バルクヘッドは、システムの一部を隔離してカスケード障害を防ぎます。例えば、通常のチャットリクエストとツールを含むリクエストには、それぞれ異なる並行スロットが割り当てられます。遅いベクトル検索や外部 API 呼び出しがツールパスをブロックした場合でも、標準的なチャットパスは他のユーザーに対して利用可能なままです。

データ収束は、複数の専門的なストアにデータを分割するのではなく、統一されたデータベースエンジンを使用することによって達成されます。多くの AI アーキテクチャでは、開発者はリレーショナルデータ用に Postgres、キャッシュ用に Redis、埋め込み用に別のベクトルデータベースを使用するかもしれません。このアプローチは、特に単一のエージェントターンで会話状態、ツール記録、メモリ事実、冪等性エントリを同時に書き込む必要がある場合に、複雑な整合性の課題を導入します。Oracle AI Database Free のような、1 つのエンジンでリレーショナル、JSON、ベクトルデータをサポートするデータベースを使用することで、これらの書き込みを単一のトランザクションで処理できます。これにより、原子性が保証され、バックアップおよび資格情報管理が簡素化されます。

システムは、サービスレベルでの並行制限を強制するためにセマフォを使用します。例えば、ゲートウェイはチャット用に 24 スロット、ツール用に 8 スロットを割り当てる場合があります。リクエストが届くと、続行する前にスロットを取得する必要があります。これにより、ツール呼び出しの洪水がすべての利用可能なリソースを枯渇させるのを防ぎます。さらに、SELECT ... FOR UPDATE とバージョン列のようなデータベースレベルの機能は、異なるレプリカからの競合更新を直列化し、同じ会話内の同時ターンが互いの状態を上書きしないようにするのに役立ちます。

主要な詳細

• モノリスにおけるコンテキスト喪失: ステートフルなモノリシック API を 1 レプリカから 3 レプリカへスケールすると、HTTP レスポンスが成功しているにもかかわらず、ベンチマークで 75 パーセントのコンテキスト喪失率が発生しました。
• エージェントトラフィックの 4 つの特性: 会話は長いがリクエストはステートレスであること、ツール呼び出しは予測不可能にファンアウトすること、エージェントは積極的に再試行すること、そして負荷がバースト的でマシンペースであること。
• バルクヘッドによる隔離: チャットとツールの並行プールを分離することで、遅いツール実行が標準的なチャットリクエストをブロックするのを防ぎ、システム全体のレジリエンスを向上させます。
• 収束データストレージ: リレーショナル、JSON、ベクトルデータのすべてを単一のデータベースで使用することで、単一のエージェントターンに対して複数の専門的なデータストアを管理する際の整合性オーバーヘッドを回避します。
• スマートエンドポイント、ダミーパイプ: OpenAI chat-completions プロトコルは安定したトランスポート層として機能し、ルーティングやメモリエンジニアリングなどのインテリジェンスはアプリケーションロジックに実装されます。
• トランザクション安全性: データベーストランザクションにより、会話状態、ツール監査、メモリ埋め込みがアトミックに書き込まれることが保証され、再試行中の部分的な更新を防ぎます。

なぜ重要なのか

AI 製品を開発するソフトウェアエンジニアにとって、これらのアーキテクチャシフトを理解することは信頼性のために重要です。システムが健全に見えるものの、コンテキスト欠落により誤った回答を提供するサイレント障害は、デバッグが難しく、ユーザーの信頼を損ないます。ステートレスな設計と共有ストレージを採用することで、チームは会話の連続性を犠牲にすることなく、アプリケーションを水平スケールできます。このアプローチはまた、ロードバランサーでの複雑なセッションアフィニティ設定の必要性を排除するため、運用も簡素化します。

さらに、バルクヘッドと収束データの使用は、運用の複雑さを減らし、負荷下でのパフォーマンスを向上させます。ベクトル検索などのリソース集約的なタスクを隔離することで、コアなチャット機能が応答性を維持できるようにします。データ型を単一のデータベースエンジンに統合することで、複数のシステム間でのアプリケーションレベルの調整が必要なくなり、レイテンシとデータ不整合のリスクが軽減されます。これらのパターンにより、開発者は脆弱なカスタムソリューションに頼る代わりに、確立されたエンジニアリング原則を使用して堅牢でスケーラブルなエージェントシステムを構築できます。

実施できること

• 状態と計算の分離: 会話履歴とエージェントメモリをアプリケーションメモリから、すべてのレプリカからアクセス可能な共有かつ永続的なストレージシステムへ移動します。
• バルクヘッドの実装: セマフォや同様の並行制御を使用して、チャット補完やツール実行など、異なるタイプのリクエストのリソースプールを分離します。
• データ層の収束: トランザクション管理を簡素化し、整合性リスクを減らすために、単一のエンジンでリレーショナル、JSON、ベクトルデータをサポートするデータベースを検討します。
• 標準プロトコルの採用: OpenAI 互換 API をトランスポート層として使用し、既存の SDK やツールを活用しながら、プロトコルをシンプルかつ安定に保ちます。
• コンテキスト喪失のテスト: 本番デプロイの前に、サイレントなコンテキスト喪失の問題を特定し修正するために、リクエストを複数のレプリカに分散させるベンチマークを実行します。
• 楽観的並行制御の使用: 同じ会話状態に対する同時更新を安全に処理するために、バージョン列とデータベースレベルのロックを実装します。