AV Chaos Monkey

ビデオ会議システムの負荷テストのための分散型カオスエンジニアリングプラットフォーム。H.264/Opusストリームで1500以上のWebRTC参加者をシミュレートし、ネットワークカオススパイクを注入して、劣化条件下でのシステムの回復力を検証します。

アーキテクチャ

メディア処理パイプライン:
- FFmpegが起動時に入力ビデオをH.264 Annex-BおよびOgg/Opusに変換
- NALリーダーがH.264ストリーム（SPS/PPS/IDR/スライス）を解析
- OpusリーダーがOggコンテナから20msのオーディオフレームを抽出
- フレームはメモリにキャッシュされ、全参加者間で共有（ゼロコピー）
- 参加者ごとのエンコードに比べてCPU使用量を約90%削減
コントロールプレーン:
- HTTPサーバー（:8080）がREST APIを介してテストライフサイクルを管理
- スパイクスケジューラがカオスイベントを分散（均等/ランダム/前寄せ/後寄せ/レガシー）
- ネットワークデグレーダーがカオスを適用: パケットロス（1-25%）、ジッタ（10-50ms）、ビットレート低減（30-80%）、フレームドロップ（10-60%）
- ロードされたカオス設定が参加者プールに適用される
参加者プール:
- ポッド間で自動パーティション分割: participant_id % total_partitions = partition_id
- 各参加者がRTPストリームを生成（PT=96 ビデオ、PT=111 オーディオ）
- 参加者IDがRTP拡張ヘッダー（ID=1）に埋め込まれる
- プールサイズ: 1-100（ローカル）、100-500（Docker）、500-1500（Kubernetes）
Kubernetes自動構成:
- ポッドがポッド名からパーティションIDを自動検出: orchestrator-3 → PARTITION_ID=3
- ポート割り当て: base_port + (partition_id × 10000) + participant_index
- 例: パーティション0は5000-14999、パーティション1は15000-24999
- StatefulSetで10レプリカ、各レプリカが約150参加者を処理
- リソース: 1-4 CPU、2-4Gi メモリ/ポッド
- ホストマシンのスペックに基づいて自動設定
UDPリレーチェーン（Kubernetesのみ）:
```
オーケストレーターポッド (10×) → UDP :5000 → udp-relay ポッド (Python)
→ 長さプレフィックス付きTCP :5001 → kubectl port-forward 15001:5001
→ tools/udp-relay (Go) → UDP :5002 → 受信側
```
- 理由: kubectl port-forwardはTCPのみサポートしており、UDPはサポートしない
- クラスタ内リレー: Pythonスクリプトが全ポッドからのUDPを集約し、2バイト長さプレフィックス付きTCPとしてストリーム
- ローカルリレー: GoツールがTCPストリームをUDPパケットに変換
- 1500参加者ストリームを1つの接続に集約
WebRTCインフラ:
- Coturn StatefulSet: 初期レプリカ3、HPAが負荷に応じて1-10にスケーリング（約500参加者/レプリカ）
- coturn-lb Service: TURNトラフィックをレプリカ間でロードバランス
- webrtc-connector: オプションのプロキシレイヤー（Deployment + HPA 2-10レプリカ）、SDPシグナリングを処理
- Dockerモード: ローカルテスト用の単一Coturnコンテナ
- ポート: 3478（TURN）、49152-65535（リレー範囲）
- 認証情報: webrtc/webrtc123
クライアント統合:
- UDPレシーバー: リレーチェーンを介して全参加者からの集約RTPストリームを受信
- WebRTCレシーバー: TURNサーバーを介したSDP交換により1:1のWebRTC接続を確立
- どちらもテスト対象のビデオ通話システム（SFU/MCU/Mesh）に転送
可観測性スタック（オプション）:
- Prometheus: すべてのオーケストレーターポッドの/metricsエンドポイントを5秒ごとにスクレイピング
- Grafana: 事前構成されたダッシュボードでメトリクスを可視化（admin/admin）
- 公開メトリクス: 参加者数、送信パケット数、送信バイト数、アクティブスパイク数、パケットロス率、ジッタ、MOSスコア
- アクセス: Prometheusは:30090、Grafanaは:30030（NodePort）
- オーケストレーターポッドは自動検出用にアノテーション付き: prometheus.io/scrape: "true"

基本概念

参加者シミュレーション

各仮想参加者が実際のメディアストリームを生成:

ビデオ: 実際のビデオファイルからのH.264 NALユニット、RFC 6184に従ってパケット化
オーディオ: OggコンテナからのOpusフレーム、RFC 7587に従ってパケット化
RTP: 参加者ID拡張を含む標準準拠のヘッダー
タイミング: フレーム精度のタイミング（30fpsビデオ、20msオーディオパケット）

カオス注入

5種類のスパイクが実際のネットワーク状態をシミュレート:

パケットロス: アプリケーション層でRTPパケットをドロップ（1-100%）
ネットワークジッタ: レイテンシ変動を追加（ベース + ガウスジッタ）
ビットレート低減: ビデオエンコードをスロットル（30-80%低減）
フレームドロップ: ビデオフレームをスキップ（10-60%ドロップ率）
帯域幅制限: 総スループットを上限

分散戦略

スパイクは設定可能な戦略を使用してテスト期間全体に分散:

均等: ジッタ付きの均一な間隔（予測可能な負荷）
ランダム: 予測不可能なタイミング（現実的なカオス）
前寄せ: 初期に高密度のスパイク（復旧テスト）
後寄せ: ベースライン後にカオス（比較テスト）
レガシー: 固定間隔のタイカー（ランタイム注入）

パーティショニング

Kubernetesデプロイメントでは、参加者のパーティショニングによって水平スケーリングを実現:

各ポッドが participant_id % total_partitions == partition_id を処理
ポート割り当て: base_port + (partition_id * 10000) + participant_index
1～10ポッドへの自動負荷分散
1500以上の参加者（ポッドあたり150）にスケーリング

システムの実行

1. ローカル開発（ネイティブGo）

最適: 開発、デバッグ、小規模テスト（1～100参加者）

# オーケストレーターを起動
go run cmd/main.go

# 別のターミナルで: UDPレシーバーを起動
go run examples/go/udp_receiver.go 5002

# config/config.jsonを編集して num_participants: 10 を設定
# カオステストを実行
go run tools/chaos-test/main.go -config config/config.json

実行の流れ:

単一のオーケストレータープロセスが :8080 で動作
参加者はUDPを 127.0.0.1:5002 に送信
カオススパイクはHTTP APIを介して注入
リアルタイムメトリクスが2秒ごとに表示

設定（config/config.json）:

{
  "base_url": "http://localhost:8080",
  "media_path": "public/rick-roll.mp4",
  "num_participants": 10,
  "duration_seconds": 300,
  "spikes": {
    "count": 20,
    "interval_seconds": 5,
    "types": { "rtp_packet_loss": {...}, "network_jitter": {...} }
  },
  "spike_distribution": {
    "strategy": "random",
    "min_spacing_seconds": 5,
    "jitter_percent": 15
  }
}

2. Docker Compose（コンテナ化）

最適: 隔離されたテスト、CI/CD、中規模テスト（100～500参加者）

前提条件:

Docker Desktop（メモリ割り当て8～16GB）
docker-compose がインストールされていること

# オーケストレーターコンテナをビルドして起動
./scripts/start_everything.sh build

# 別のターミナルで: UDPレシーバーを起動
go run examples/go/udp_receiver.go 5002

# config/config.jsonを編集して num_participants: 100 を設定
# カオステストを実行（コンテナを対象）
go run tools/chaos-test/main.go -config config/config.json

リソース制限（docker-compose.yaml を編集）:

services:
  orchestrator:
    deploy:
      resources:
        limits:
          cpus: "14.0"
          memory: 6G  # 参加者を増やすには増やす

スケーリングガイド:

Dockerメモリ	最大参加者数	CPUコア数
8 GB	~100	4
16 GB	~250	8
24 GB	~400	12
32 GB	~500	14

3. Nixを使用したKubernetes（本番規模）

最適: 大規模テスト（500～1500参加者）、水平スケーリング、本番検証

前提条件:

flakesが有効なNix
Docker Desktopまたはkindクラスター
kubectlが設定されていること

ステップ1: Nix環境に入る

# Nixが提供: Go、Docker、kubectl、kind、ffmpeg
nix develop

# またはdirenvを使用して自動アクティベーション
echo "use flake" > .envrc
direnv allow

ステップ2: Kubernetesにデプロイ

# 最適な設定で自動デプロイ（システムリソースを検出）
./scripts/start_everything.sh run -config config/config.json

# またはカスタムメディアファイルを指定
./scripts/start_everything.sh run --media=path/to/video.mp4 -config config/config.json

実行の流れ:

Nixが提供するGoツールチェーンでDockerイメージをビルド
kindクラスターを作成/使用
10個のオーケストレーターポッドを含むStatefulSetをデプロイ
UDPリレーポッドをデプロイ
UDPリレー用の kubectl port-forward を設定
ローカルのTCP→UDPリレーを起動
全ポッドでカオステストを実行

ステップ3: 集約されたUDPストリームを受信

オプションA: UDPレシーバー（Kubernetes推奨）

# 1500人の全参加者からの集約ストリームを受信
go run ./examples/go/udp_receiver.go 5002

オプションB: WebRTCレシーバー（複数参加者）

# WebRTCを介して最大150参加者に接続
go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150

アーキテクチャの流れ:

10ポッドに分散した1500参加者
  → 各ポッド: 150参加者
  → participant_id % 10 でパーティション分割
  → 全員がUDPをudp-relay:5000に送信
  → UDPリレーが集約 → TCP :5001
  → kubectl port-forward 15001:5001
  → ローカルリレーがTCPをUDP :5002に変換
  → 受信側が1500ストリームすべてを受信

注意: start_everything.sh スクリプトが自動的に以下を設定:

kubectl port-forward（udp-relay 15001:5001）
ローカルTCP→UDPリレー（tools/udp-relay）
受信側の実行のみ必要

手動Kubernetesセットアップ

# イメージのビルドとロード
docker build -t chaos-monkey-orchestrator:latest .
kind load docker-image chaos-monkey-orchestrator:latest

# デプロイ
kubectl apply -f k8s/orchestrator/orchestrator.yaml
kubectl apply -f k8s/udp-relay/udp-relay.yaml

# ポッドが準備できるまで待機
kubectl wait --for=condition=ready pod -l app=orchestrator --timeout=300s

# UDPリレーのポートフォワード
kubectl port-forward udp-relay 15001:5001 &

# ローカルTCP→UDPリレーを起動
go run tools/udp-relay/main.go &

# 別のターミナルで: レシーバーを起動
go run ./examples/go/udp_receiver.go 5002

# 別のターミナルで: カオステストを実行
go run tools/chaos-test/main.go -config config/config.json

クリーンアップ

# Kubernetesリソースを削除
./scripts/cleanup.sh

# またはクラスター全体を削除
kind delete cluster --name av-chaos-monkey

Nixを使用したクロスプラットフォームビルド

# Linux x86_64向けにビルド（最も一般的）
nix build .#packages.x86_64-linux.av-chaos-monkey

# ARM64向けにビルド（Raspberry Pi、AWS Graviton）
nix build .#packages.aarch64-linux.av-chaos-monkey

# macOS Intel向けにビルド
nix build .#packages.x86_64-darwin.av-chaos-monkey

# macOS Apple Silicon向けにビルド
nix build .#packages.aarch64-darwin.av-chaos-monkey

# バイナリの場所
./result/bin/main

AV-Chaos-Monkey

人気