OpenAI リアルタイム音声AIの低遅延インフラ設計:UDP・LB・k8s
概要¶
OpenAI のリアルタイム音声 AI(Realtime API)を本番運用する際の低遅延インフラ設計の考察。ロードバランサー(LB)、UDP、Kubernetes(k8s)それぞれの課題と対策を紹介。
詳細¶
OpenAI Realtime API とは¶
WebSocket/WebRTC 接続でリアルタイム音声を双方向ストリーミング:
クライアント (音声入力)
│ WebSocket / WebRTC
▼
OpenAI Realtime API
│
▼
クライアント (音声出力)
特徴:
- 音声 → テキスト → LLM → テキスト → 音声 のパイプラインを低遅延で処理
- 割り込み(Interruption)対応
- 200ms 以下の応答遅延を目標
低遅延インフラの課題¶
1. ロードバランサー(LB)の選択¶
HTTP/WebSocket 向けの課題:
✗ L7 LB(ALB 等): TCP 再確立オーバーヘッドあり
✓ L4 LB(NLB 等): 接続を維持したまま透過的にルーティング
WebRTC(UDP)向けの課題:
✗ 標準 LB は UDP ステートレスなので、パケットが異なるバックエンドに散る
✓ STUN/TURN サーバーで ICE 接続を管理
✓ クライアント IP + ポートでのステッキーセッション
2. UDP と TCP のトレードオフ¶
| 項目 | TCP(WebSocket) | UDP(WebRTC) |
|---|---|---|
| 遅延 | やや高い(再送制御あり) | 低い(再送なし) |
| パケットロス時 | 再送で補填 | パケットロスそのまま(品質低下) |
| NATトラバーサル | 容易 | STUN/TURN が必要 |
| LB 対応 | 容易 | 工夫が必要 |
3. Kubernetes での音声 AI 運用¶
# 音声処理 Pod の設定例
spec:
containers:
- name: voice-processor
resources:
requests:
cpu: "2"
memory: "4Gi"
limits:
cpu: "4"
memory: "8Gi"
# CPU ピン留めで遅延を安定化
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: voice-processor
topologyKey: kubernetes.io/hostname
# WebSocket 対応の Service(NLB)
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
spec:
type: LoadBalancer
sessionAffinity: ClientIP # 同一クライアントは同一 Pod へ
低遅延のための追加施策¶
1. Geographic routing: クライアントに最も近いリージョンへ
→ Route53 Latency-Based Routing / Anycast
2. CPU アフィニティ: 音声処理スレッドを特定 CPU コアに固定
→ NUMA 対応、キャッシュミス削減
3. カーネルパラメータ調整:
net.core.rmem_max=134217728
net.core.wmem_max=134217728
net.ipv4.tcp_fastopen=3
4. PodDisruptionBudget: ローリングアップデート中もセッション維持
なぜ重要か / いつ使うか¶
- 音声 AI サービス開発: OpenAI Realtime API や類似サービスを本番投入する際の設計指針
- 低遅延要件のあるシステム: 200ms 以下が求められるリアルタイム通信全般に応用可能
- k8s + ステートフル接続: WebSocket/WebRTC のような長時間接続を k8s で管理する際の課題解決