WebSocket と永続オブジェクトを使用した大規模なリアルタイム AI 推論

2024 年 10 月に、AI Gateway を使用して AI アプリケーションから数十億のログを保存することと、これを行うために Cloudflare の開発者プラットフォームをどのように使用するかについて説明しました。

2024 年 10 月に、AI Gateway を使用して AI アプリケーションから数十億のログを保存する方法と、これを行うために Cloudflare の開発者プラットフォームを使用する方法について説明しました。

AI Gateway はすでに 30 億を超えるログを処理し、急速に成長しており、プラットフォームへの接続数は着実に増加し続けています。開発者がこの規模をより効果的に管理できるように、HTTP/2 キープアライブを実装して永続的な HTTP(S) 接続を維持する代替手段を提供したいと考えました。これにより、AI Gateway への新しい HTTP 接続ごとに繰り返されるハンドシェイクと TLS ネゴシエーションのオーバーヘッドが回避されます。 。私たちは、HTTP/2 の実装には課題が生じる可能性があることを理解しています。特に、多くのライブラリやツールがデフォルトで HTTP/2 をサポートしていない場合や、ほとんどの最新のプログラミング言語で十分に確立された WebSocket ライブラリが利用可能な場合には、課題が生じる可能性があります。

これを念頭に置いて、私たちは Cloudflare の開発者プラットフォームと Durable Objects (はい、また!) を使用して、単一の永続的な接続を確立し、継続的な通信を可能にする WebSocket API を構築しました。

この API を通じて、AI Gateway でサポートされているすべての AI プロバイダーに WebSocket 経由でアクセスできるため、クライアントまたはサーバー アプリケーションと AI Gateway の間で単一の TCP 接続を維持できます。一番いいところは？選択したプロバイダーが WebSocket をサポートしていない場合でも、当社が WebSocket を処理し、優先 AI プロバイダーへのリクエストを管理します。

WebSocket 経由で AI Gateway に接続すると、プロバイダーがサポートするプロトコル (HTTPS、WebSocket など) を使用して推論サービスにリクエストが行われます。接続を開いたままにして、必要なだけ推論リクエストを実行できます。

を希望します。

AI Gateway への接続をより安全にするために、AI Gateway の認証も導入しています。新しい WebSocket API には認証が必要です。必要なのは、「AI Gateway: Run」権限を持つ Cloudflare API トークンを作成し、それを cf-aig-authorization ヘッダーで送信することだけです。

上記のフロー図では:

1.認証されたゲートウェイが有効で、有効なトークンが含まれている場合、リクエストは正常に通過します。

2.認証されたゲートウェイが有効であっても、有効なトークンを含む必要な cf-aig-authorization ヘッダーがリクエストに含まれていない場合、リクエストは失敗します。これにより、検証されたリクエストのみがゲートウェイを通過することが保証されます。

3. Authenticated Gateway が無効になっている場合、cf-aig-authorization ヘッダーは完全にバイパスされ、有効か無効かにかかわらず、トークンは無視されます。

私たちがそれを構築した方法

私たちは最近、AI ゲートウェイのロギング ソリューションを拡張するためにデュラブル オブジェクト (DO) を使用したため、同じ DO 内で WebSocket を使用するのが自然でした。

Cloudflare ワーカーが新しい WebSocket 接続を受信すると、WebSocket クライアントの多様な機能をサポートするために 2 つの方法で認証を実装します。主な方法には、cf-aig-authorization ヘッダーを介して Cloudflare API トークンを検証し、接続するアカウントとゲートウェイに対してトークンが有効であることを確認することが含まれます。

ただし、ブラウザの WebSocket 実装の制限により、「sec-websocket-protocol」ヘッダーによる認証もサポートしています。ブラウザ WebSocket クライアントは標準 API でカスタム ヘッダーを許可しないため、リクエストへの認証トークンの追加が複雑になります。 API キーをブラウザーに保存することはお勧めしませんが、すべての WebSocket クライアントの柔軟性を高めるためにこの方法を追加することにしました。

この最初の検証ステップの後、接続を永続オブジェクトにアップグレードします。これは、接続のすべてのメッセージを処理できるようになることを意味します。新しい接続が完全に受け入れられる前に、ランダムな UUID が生成されるため、Durable Object が受信するすべてのメッセージの中でこの接続を識別できるようになります。接続が開いている間、ヘッダー経由で渡された AI Gateway 設定 (cf-aig-skip-cache (true に設定するとキャッシュをバイパスする) など) が保存され、セッション内のすべてのリクエストに適用されます。ただし、これらのヘッダーは、現在のユニバーサル エンドポイントと同様に、リクエストごとにオーバーライドできます。

仕組み

接続が確立されると、Durable Object は受信メッセージのリスニングを開始します。この時点から、ユーザーは WebSocket 経由で AI Gateway ユニバーサル形式でメッセージを送信できるようになり、既存の HTTP セットアップから WebSocket ベースの通信へのアプリケーションの移行が簡素化されます。

新しいメッセージが Durable Object に到達すると、HTTP Universal Endpoint を強化するのと同じコードを使用して処理され、Workers と Durable Object 間でのシームレスなコードの再利用が可能になります。これは、Cloudflare 上に構築する主な利点の 1 つです。

非ストリーミング リクエストの場合、レスポンスは JSON エンベロープでラップされ、そのリクエストの AI ゲートウェイ ログ ID など、AI 推論自体を超える追加情報を含めることができます。

上記のリクエストに対する応答の例を次に示します。

ストリーミング リクエストの場合、AI Gateway は、開発者にストリームが開始していることを伝えるリクエスト メタデータを含む最初のメッセージを送信します。

この最初のメッセージの後、すべてのストリーミング チャンクが推論プロバイダーから到着すると、リアルタイムで WebSocket 接続に中継されます。これらのストリーミング チャンクのメタデータには、eventId フィールドのみが含まれることに注意してください (この新しいフィールドの内容については、以下で詳しく説明します)。

このアプローチには 2 つの目的があります:

以上がWebSocket と永続オブジェクトを使用した大規模なリアルタイム AI 推論の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。