【ITニュース解説】Serverless AI Orchestration Architecture Teardown and Latency Optimization

サーバーレス技術は、必要な時にだけコンピューターリソースを使い、使わないときは費用がかからないため、人工知能、特に生成AIのような新しい技術を動かすのに非常に人気がある。必要な処理量に応じて自動で規模を拡大できる利点もある。しかし、このサーバーレス環境でAIを単純に動かそうとすると、いくつかの問題に直面することがある。例えば、サーバーレスのプログラムは一度処理が終わるとすぐに状態を忘れてしまうため、前の会話の内容を覚えておくのが難しい。また、AIの応答時間は予測できないほど長くなることがあるため、通常の同期的な通信方法では途中で接続が切れてしまうこともある。さらに、AIが使うデータベースを初めて起動する際の待ち時間も、全体の応答速度を遅くしてしまう原因となる。この記事では、これらの問題を詳しく分析し、サーバーレス環境でAIエージェントを効率的に動かすための新しいアーキテクチャを紹介する。

提案されるアーキテクチャの基本的な流れは次のようになる。まず、利用者のリクエストは、CloudflareやAWSのようなエッジゲートウェイと呼ばれる入り口に届く。ここからリクエストは直接AIを動かすプログラムには送られず、メッセージキューと呼ばれる一時的な保管場所に非同期に送られる。メッセージキューには、たとえばSQSやCloudflare Queuesのようなサービスが使われる。その後、オーケストレーターワーカーと呼ばれるプログラムがメッセージキューからリクエストを取り出し、処理を開始する。このオーケストレーターワーカーは、特定の情報を一時的に保存するためにKVセッションストアと連携する。オーケストレーターは、さらにサブエージェントと呼ばれる専門のAIプログラム（例えば、情報を検索するAIや、外部ツールを実行するAIなど）に指示を出す。サブエージェントは、必要なデータを取得するためにベクターデータベースと通信したり、別のシステムで作業を実行したりする。これらのサブエージェントからの結果は、集約ストリームに集められ、最終的にクライアントに対してSSE（Server-Sent Events）という技術を使って、リアルタイムに分割して応答が送られる。

サーバーレスの関数は、一つのイベントを処理し終えるとすぐに終了し、以前の状態を記憶していない。これを「ステートレス」という。しかし、AIエージェント、特に会話を続けるチャットボットのようなものは、これまでの会話履歴や推論の途中で得た情報を覚えておく必要がある。この状態を保持するために、従来のリレーショナルデータベースを使うと、AIが次の行動を決めるたびにデータベースから過去の会話を全て読み込み直す必要が生じる。AIが5回から10回も連続で推論を繰り返すような場合、データベースからの読み込みだけで全体の応答時間が2秒以上もかかってしまうことがある。この問題を解決するために、「デカップリングされたキーバリューストア」という方法が提案される。これは、サーバーレス関数にはセッションを識別するための最小限のIDだけを渡し、会話履歴や推論の途中経過といった複雑な情報は、RedisやCloudflare KVのような高速なキーバリューストアに保存するという考え方だ。これにより、関数は必要なときにキーバリューストアから必要な情報だけを素早く取得できる。そして、一連の処理が完了し、クライアントに結果が返された後で、その実行履歴を分析用のストレージに非同期で保存する。これにより、クライアントへの応答速度を落とさずに、重要なデータを永続的に記録できる。

ベクターデータベースは、AIが情報を検索する際に使われる特別なデータベースだ。従来のベクターデータベースでは、サーバーレスのプログラムがデータベースと通信するために、TCPというプロトコルを使った永続的な接続を確立する必要がある。しかし、サーバーレス環境ではプログラムが使われていないとすぐに停止してしまうため、新しいリクエストが来るたびにデータベースとの接続を最初から確立し直す「コールドスタート」という現象が頻繁に発生する。この接続の確立には、TCPハンドシェイクやTLS暗号化の交渉などで約150〜250ミリ秒かかる。さらに、接続プールが飽和したり、プログラム自体の起動にも約200〜400ミリ秒かかったりするため、これらの合計でかなりの遅延が発生してしまう。この問題を解決するためには、ベクターデータベースとの通信を従来のTCPプロトコルから、HTTP REST APIというWebで一般的に使われる通信方法に切り替えることが効果的だ。HTTP REST APIを利用すると、接続プールの問題を解消でき、サーバーレスのプログラムがセマンティックな文脈（意味的な情報）を45〜60ミリ秒という短時間で取得できるようになる。これにより、RAG（Retrieval Augmented Generation）という、外部情報を参照してAIが回答を生成する際のコールドスタートによるオーバーヘッドを40%以上削減できる。

複雑なAIの推論処理では、複数のAIエージェントが連携して動作する必要がある。しかし、これらの処理を同期的に、つまり前の処理が終わるまで次の処理を待つ形でHTTP通信を使って連結すると、問題が発生しやすい。大規模な言語モデル（LLM）の応答時間は予測不能で、800ミリ秒で終わることもあれば、20秒以上かかることも珍しくない。このようなAIエージェントを同期的に次々と呼び出すと、途中のどこかで応答が遅延した際に、HTTPのゲートウェイタイムアウト（HTTP 504エラー）が連鎖的に発生し、システム全体が停止してしまう危険性がある。この課題を解決するためには、同期的なHTTPトリガーを「非同期メッセージブローカー」に置き換える方法が有効だ。メッセージブローカー、具体的には前述のメッセージキューを使うことで、利用者のリクエストの受信と実際の処理の実行を切り離すことができる。APIゲートウェイは、利用者のプロンプト（指示）を受け取ると、処理の追跡IDをすぐに返して応答を完了させる。この応答は50ミリ秒未満で完了する。これにより、クライアントはすぐに最初の応答を受け取り、システムが応答していることを知ることができる。次に、メッセージキューはリクエストを一時的に保存し、同時に処理できるリクエストの数を制限することで、大規模言語モデルが処理できる上限を超えてしまわないように制御する。ワーカーノードは、メッセージキューからプロンプトを取り出し、必要なツール呼び出しを実行し、処理の進捗状況や生成されたテキストをSSE（Server-Sent Events）やWebSocketといった技術を使って、クライアントに少しずつリアルタイムでプッシュしていく。これにより、クライアントはAIが応答を生成している間も待たされていると感じにくくなる。

サーバーレスAIアーキテクチャを実際に運用する際には、いくつかの重要な原則がある。まず、プログラムの実行部分とデータの保存部分を明確に分離することが重要だ。次に、外部のデータベースなどと通信する際には、TCP接続プールではなく、HTTP RESTエンドポイントのような、よりサーバーレスに適した通信方法を優先して使うべきだ。また、AIモデルのスループット（処理能力）には限界があるため、メッセージキューのような仕組みを使って、処理できるリクエストの数を適切に制限するバックプレッシャー機能を実装する必要がある。最後に、複数のAIエージェントに処理を委譲する際には、非同期のメッセージファンアウトという方法を使い、同時に複数のエージェントに指示を送り、それぞれの結果を待ち受けるような設計にすると良い。これらのポイントを押さえることで、安定して高性能なサーバーレスAIシステムを構築できる。