OpenAI 低遅延音声 AI インフラストラクチャ

OpenAI は、リアルタイム音声 AI のスケーリング課題を解決するために、分割リレー＋トランシーバー アーキテクチャを実装しました。パケットルーティングとプロトコル終端を分離することで、標準的な Kubernetes 環境内で動作しながら、自然な会話に必要な低遅延要件を維持できます。

Kubernetes 上での WebRTC スケーリングの課題

従来の WebRTC 実装は、セッションごとに 1 ポートを割り当てるモデルに依存することが多く、OpenAI の規模（週あたり 9 億人以上のアクティブユーザー）で展開すると重大な運用上のハードルが生じます。このモデルは主に次の 3 つの制約をもたらします。

  • Port Exhaustion（ポート枯渇）: サービスごとに数万の公開 UDP ポートを管理する必要があり、ロードバランサ設定、ファイアウォールポリシー、ロールアウトの安全性が複雑化します。
  • Security Risks（セキュリティリスク）: 大規模な UDP ポート範囲は外部から到達可能な表面積を拡大し、ネットワークポリシーの監査が困難になります。
  • Autoscaling Friction（オートスケーリングの摩擦）: Kubernetes ポッドは頻繁に再スケジュールされますが、各ポッドが大きな安定ポート範囲を予約・広告する必要があるため、弾力性が脆弱になります。

シングルポート・パー・サーバー設計はポート数を削減しますが、"state stickiness"（状態の粘着性）に苦しみます。ICE（Interactive Connectivity Establishment）と DTLS（Datagram Transport Layer Security）はステートフルであるため、特定セッションのパケットは常にそのセッションを所有するプロセスに届く必要があり、接続失敗を防げます。

リレー + トランシーバー アーキテクチャ

これらの矛盾を解消するため、OpenAI はマルチパーティ通話で一般的に使用される Selective Forwarding Unit（SFU）モデルから離れ、トランシーバーモデル を採用しました。このアーキテクチャでは、WebRTC エッジサービス（トランシーバー）がクライアント接続を終端し、メディアを内部プロトコルに変換して推論やオーケストレーションに渡します。

Split Routing and Termination

この設計の核心は Relay（リレー）（ルーティング）と Transceiver（トランシーバー）（終端）を分離することです。

  • The Relay: 公開フットプリントが小さい軽量 UDP 転送レイヤーです。メディアの復号や ICE ステートマシンの実行、コーデック交渉は行わず、パケットメタデータを読み取って宛先を決定し、転送するだけです。
  • The Transceiver: ステートフルな WebRTC エンドポイントです。ICE 接続チェック、DTLS ハンドシェイク、SRTP 暗号鍵、セッションライフサイクルを含む完全なセッション状態を保持します。

First-Packet Routing via ICE ufrag

最初のパケットで外部参照を待たせないように、OpenAI は ICE username fragment (ufrag) を利用します。セッション設定時にトランシーバーはルーティングメタデータを含むサーバー側 ufrag を生成します。

クライアントが最初の STUN（Session Traversal Utilities for NAT）バインディングリクエストを送信すると、リレーは ufrag を解析し、ルーティングヒントをデコードして所有トランシーバーへパケットを転送します。ルートが確立すると、以降の DTLS、RTP、RTCP パケットはインメモリのセッションマップに基づき、リレーが再起動した場合に備えて Redis キャッシュでマッピングを復元できるようにします。

Global Reach and Latency Optimization

OpenAI は「Global Relay」艦隊として地理的に分散したインゲレスポイントを活用し、クライアントから OpenAI への最初のホップを短縮します。これにより、RTT（往復遅延）、ジッター、パケットロスが削減され、トラフィックが OpenAI バックボーンに入る前に最適化されます。

  • Geo-Steered Signaling: Cloudflare のジオおよび近接ステアリングにより、最初の HTTP または WebSocket リクエストが近くのトランシーバークラスタに届きます。
  • Integrated Routing: SDP（Session Description Protocol）応答が Global Relay のアドレスを提供し、ufrag がリレーにメディアを正しいクラスタとトランシーバーへルーティングさせます。

Technical Implementation and Performance

リレーサービスは Go で実装され、カーネルバイパスフレームワークを必要とせずに高スループットを実現しています。主なパフォーマンス最適化は以下の通りです。

  • SO_REUSEPORT: この Linux ソケットオプションにより、複数のリレー ワーカーが同一 UDP ポートにバインドでき、カーネルが受信パケットをワーカー間で分散し、読み取りループのボトルネックを回避します。
  • runtime.LockOSThread: UDP 読み取り goroutine を特定の OS スレッドに固定し、キャッシュローカリティを向上させ、同一フローのパケットが同じ CPU コア上で処理されることでコンテキストスイッチを削減します。
  • Memory Management: 事前確保バッファと最小コピーを使用することで、割り当てオーバーヘッドとガベージコレクションの一時停止を減らします。

Summary of Architectural Gains

バックエンドサービスやクライアントに複雑さを持ち込むのではなく、薄いルーティング層に集約することで、OpenAI は標準的なプロトコルセマンティクスを保ちつつスケーラブルな WebRTC デプロイを実現しました。これにより、ブラウザやモバイルアプリは相互運用性を維持しつつ、推論バックエンドは普通のサービスと同様にスケールでき、WebRTC ピアとしての負荷を回避できます。

Sources