Show HN: 音声・映像テスト用の「Chaos Monkey」(WebRTC と UDP)

2026/02/23 17:53

Show HN: 音声・映像テスト用の「Chaos Monkey」(WebRTC と UDP)

RSS: https://news.ycombinator.com/rss

要約

Japanese Translation:

改訂概要:
AV Chaos Monkey は、1,500 人以上の WebRTC 参加者が H.264 ビデオと Opus オーディオをストリーミングしながら、パケットロス、ジッタ、ビットレート低下、フレームドロップなどのリアルなネットワーク障害を注入するスケーラブルなカオスエンジニアリングプラットフォームです。 Spike Scheduler と Network Degrader を構成可能にし、FFmpeg でメディア変換、NAL/Opus リーダー、およびメモリキャッシュされたフレームを利用して CPU 使用率を約90 %削減します。

Kubernetes 上では、各 Pod が自動的にパーティション ID(

participant_id % total_partitions
)を検出し、
base_port + (partition_id × 10000) + participant_index
を使用してポートを割り当てます。 StatefulSet として最大10 レプリカで実行され、各レプリカが約150 人の参加者を処理します。 UDP リレー チェーンは数千の RTP ストリームを長さプレフィックス付き TCP(:5001)に集約し、効率的な転送を実現した後、Go ツールでそれらを UDP(:5002)に戻します。

Coturn TURN サーバー(初期は3 レプリカ、HPA で1〜10へスケーリング)は STUN/TURN をサポートし、オプションの webrtc‑connector が SDP シグナリングを処理します。 観測性は Prometheus による

/metrics
の5 秒ごとのスクレイピングと Grafana ダッシュボードで有効化され、参加者数、送信パケット/バイト数、アクティブスパイク、パケットロス %、ジッタ、および MOS スコアを表示します。

REST API はテストライフサイクル(

/api/v1/test/{id}/start
/stop
など)、SDP 交換、スパイク注入のエンドポイントを公開します。設定は
config/config.json
により行われ、ユーザーはメディアパス、参加者数、期間、スパイク種別/件数、分布戦略(even/random/front/back/legacy)、ジッタパラメータを指定できます。リソース要件は参加者に応じてスケールし、約100 人で 2 GB RAM と 2 CPU コア、1,500 人では最大約18 GB RAM と 24 CPU コアが必要です。

この現実的なテストベッドにより、メディアストリーミングプラットフォームは本番展開前に CPU、メモリ、またはネットワークのボトルネックを特定できるため、ライブストリーミングおよび通信サービスの信頼性が向上します。

本文

AV Chaos Monkey – 分散型カオスエンジニアリングプラットフォーム

概要

1500 以上の WebRTC パーティシパント(H.264 ビデオ + Opus オーディオ)をシミュレートし、ネットワーク上にカオスを注入してビデオ会議システムの耐久性を検証するロードテストフレームワークです。


アーキテクチャ

メディア処理パイプライン

コンポーネント機能
FFmpeg入力ビデオを H.264 Annex‑B へ変換、起動時に Ogg/Opus オーディオへ
NAL ReaderH.264 ストリーム(SPS/PPS/IDR/Slices)を解析
Opus ReaderOgg コンテナから 20 ms のオーディオフレームを抽出
Cacheフレームはメモリにキャッシュされ、全パーティシパントで共有(ゼロコピー)→ CPU 負荷約 90 % 削減

コントロールプレーン

  • HTTP サーバー (
    :8080
    ) – テストライフサイクル用 REST API
  • Spike Scheduler – カオスイベントを配布(均等、ランダム、前方集中・後方集中、レガシー)
  • Network Degrader – パケットロス (1–25 %)、ジッタ (10–50 ms)、ビットレート低減 (30–80 %)、フレームドロップ (10–60 %) を適用

パーティシパントプール

  • ポッドごとに自動分割:
    participant_id % total_partitions = partition_id
  • 各パーティシパントは RTP (
    PT=96
    ビデオ、
    PT=111
    オーディオ) をストリームし、RTP 拡張ヘッダーに ID を埋め込み (
    ID=1
    )
  • プールサイズ – 1–100(ローカル)、100–500(Docker)、500–1500(Kubernetes)

Kubernetes 自動構成

機能詳細
Partition ID の検出ポッド名から (
orchestrator-3 → PARTITION_ID=3
)
ポート割り当て
base_port + (partition_id × 10000) + participant_index
パーティション 0: ポート 5000‑14999、パーティション 1: 15000‑24999
StatefulSet10 レプリカ;各レプリカ ≈150 パーティシパント
リソース1–4 CPU、2–4 GiB メモリ/ポッド(ホストスペックに応じて自動スケール)

UDP Relay チェーン (Kubernetes 専用)

Orchestrator Pods (10×) → UDP :5000
→ Length‑Prefixed TCP :5001
→ kubectl port‑forward 15001:5001
→ tools/udp-relay (Go) → UDP :5002

理由:

kubectl port-forward
は TCP のみをサポート。
クラスタ内リレーは UDP を単一の TCP ストリームにまとめ、先頭 2 バイトで長さを付与。
ローカルリレーはその TCP を再び UDP パケットへ変換。

WebRTC インフラストラクチャ

コンポーネント詳細
CoturnStatefulSet(3 レプリカ、HPA 1–10) – TURN サーバ (
port 3478
)
coturn‑lbService – TURN トラフィックをロードバランス
webrtc‑connectorオプションのプロキシ層 (Deployment + HPA 2–10) – SDP シグナリング
Docker Modeローカルテスト用に単一 Coturn コンテナ
Ports49152–65535 リレーレンジ
認証情報
webrtc/webrtc123

クライアント統合

  • UDP Receiver – Relay チェーン経由で全パーティシパントの RTP ストリームを集約。
  • WebRTC Receiver – TURN を通じて 1:1 WebRTC 接続を確立し、最大150 パーティシパントに対応。

両者とも受信メディアをテスト対象(SFU/MCU/Mesh)へ転送します。


観測スタック (オプション)

ツールエンドポイント
Prometheus
/metrics
を全オーケストレータポッドから 5 秒ごとにスクレイプ
Grafana事前構成済みダッシュボード (
admin/admin
) – NodePorts
:30090
(Prometheus)、
:30030
(Grafana)

メトリクスにはパーティシパント数、送信パケット数、バイト数、アクティブな spike 数、パケットロス率、ジッタ、MOS スコア等が含まれます。


コアコンセプト

パーティシパントシミュレーション

  • ビデオ: 実際のビデオファイルから H.264 NAL ユニットを生成し、RFC 6184 に従ってパケット化
  • オーディオ: Ogg コンテナから Opus フレームを抽出し、RFC 7587 に従ってパケット化
  • RTP ヘッダーにパーティシパント ID 拡張を付与
  • フレーム単位の正確なタイミング(30 fps ビデオ、20 ms オーディオ)

カオス注入

Spike タイプパラメータ効果
rtp_packet_loss
loss_percentage
(0–100)
アプリケーション層で RTP パケットをドロップ
network_jitter
base_latency_ms
,
jitter_std_dev_ms
レイテンシの変動を追加
bitrate_reduce
new_bitrate_kbps
ビデオエンコーディングをスロットル
frame_drop
drop_percentage
(0–100)
ビデオフレームをスキップ
bandwidth_limit
bandwidth_kbps
合計帯域幅を制限

配布戦略

  • Even – 一様に間隔を空け、ジッタ付き
  • Random – 予測不可能なタイミング
  • Front‑loaded – 初期段階で密集した spike
  • Back‑loaded – ベースライン後にカオス
  • Legacy – 固定間隔のティック

システム実行方法

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

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": { /* params */ },
      "network_jitter":   { /* params */ }
    }
  },
  "spike_distribution": {
    "strategy": "random",
    "min_spacing_seconds": 5,
    "jitter_percent": 15
  }
}

2. Docker Compose (コンテナ化)

単体でのテスト、CI/CD、ミドルスケール(100–500 パーティシパント)に最適。

# オーケストレータコンテナをビルド&起動
./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~1004
16 GB~2508
24 GB~40012
32 GB~50014

3. Kubernetes + Nix (本番規模)

大規模テスト(500–1500 パーティシパント)に最適。

# Nix 環境へ入る
nix develop

# Kubernetes にデプロイ(システムリソースを自動検知)
./scripts/start_everything.sh run -config config/config.json

Go ツールチェーンで Docker イメージをビルド → kind クラスター → 10 オーケストレータポッド + UDP リレー → port‑forward → ローカル TCP→UDP リレー。

集約ストリームの受信

# UDP 受信機(Kubernetes 推奨)
go run ./examples/go/udp_receiver.go 5002

# WebRTC 受信機(最大150 パーティシパント)
go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150

API リファレンス

テストライフサイクル

エンドポイントメソッド説明
/api/v1/test/create
POSTテスト作成(任意で
test_id
/api/v1/test/{test_id}/start
POSTテスト開始
/api/v1/test/{test_id}/metrics
GETメトリクス取得
/api/v1/test/{test_id}/stop
POSTテスト停止

WebRTC シグナリング

エンドポイントメソッド説明
/api/v1/test/{test_id}/sdp/{participant_id}
GETSDP オファー取得
/api/v1/test/{test_id}/sdp/{participant_id}
POSTSDP アンサー設定 (
{ "sdp_answer": "..."} )

カオス注入

POST /api/v1/test/{test_id}/spike
{
  "spike_id": "unique_id",
  "type": "rtp_packet_loss",
  "duration_seconds": 30,
  "participant_ids": [1001, 1002],
  "params": { "loss_percentage": "15" }
}

クライアント統合

UDP Receiver (Go)

go run examples/go/udp_receiver.go 5002

RTP パケットを解析し、統計情報を表示。

WebRTC Receiver (Go)

# 単一パーティシパント
go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id>

# 複数パーティシパント(最大150)
go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150

パフォーマンス & スケーリング

パーティシパントメモリCPU帯域幅
1002 GB2 コア250 Mbps
5006 GB8 コア1.2 Gbps
100012 GB16 コア2.5 Gbps
150018 GB24 コア3.7 Gbps

1 パーティシパントあたり (1280×720 @30fps + Opus): 約 2.6 Mbps、約 140 パケット/秒。


トラブルシューティング

問題チェック / 対処
UDP パケットが届かないリレーが稼働しているか確認 (
kubectl get pod udp-relay
)、port‑forward をチェック、
nc -u -z localhost 5002
で接続確認。
WebRTC 接続失敗TURN サービス (
coturn-lb
) が到達可能か、ICE 候補を確認。
メモリ使用量が高い
/metrics
からパーティシパント数を確認し、ポッド数を増減。

ライセンス

BSD 3‑Clause


同じ日のほかのニュース

一覧に戻る →

2026/02/25 6:13

マックミニはヒューストンにある新工場で製造されます。

## Japanese Translation: > Apple は、テキサス州ヒューストンにおける製造拠点を大幅に拡張し、新たに 20,000 平方フィートの施設を設置することを発表しました。この施設は米国内で初めて Mac mini を生産する予定で、今年後半から本格的な生産が始まります。 > 同社はまた、本キャンパス内に Advanced Manufacturing Center(先進製造センター)も設置し、今年後半に開設されるとともに、学生・サプライヤー従業員および米国企業向けの実務訓練を提供します。 > これら新施設に加え、Apple の既存ヒューストン事業は 2025 年から先進 AI サーバーを組み立て、国内全土のデータセンター用ロジックボードを現地で製造しています。 > 拡張によって Apple のヒューストンキャンパスの規模は倍増し、数千件の雇用機会が創出されます。 > この動きは、Apple が掲げる米国全体の製造コミットメントの一環であり、12 州にわたる 24 の工場(TSMC、Broadcom、Texas Instruments)から 200 億ドル以上のチップ調達、シェルマンにある GlobalWafers の 40 億ドル規模のウェーハプラント、新たな 70 億ドル規模の高度パッケージング施設(Peoria の Amkor、Apple の最初かつ最大顧客)、および Corning が iPhone/Watch 用カバーガラスに特化した Harrodsburg ガラス工場などが含まれます。 > 2026 年までに Apple は TSMC アリゾナ施設から 1 億個を超える先進チップを購入する計画です。 > 同社はまた、米国全土で 130 社以上の中小メーカーに AI 主導型訓練を提供する Detroit Manufacturing Academy を支援しています。 この改訂された要約は、Key Points List のすべての主要ポイントと完全に一致し、異なるプログラムを混同せず、裏付けのない推測も含みません。

2026/02/25 6:19

それが起きているようです。

## Japanese Translation: サビーネ・ホッセンフェルダーは、AIが生成した論文がarXivで急速に増加しており、研究指導者(PI)が大学院生やポスドクを通じて多くの平凡な作品を発表する現在の学術出版モデルに脅威を与えていると警告しています。 彼女は2022年から2026年までのhep‑thカテゴリーの月次投稿数を提示します:12月の投稿件数は2022年の634件から2025年には1,192件へ増加しました;初年度(1月–2月)の数字はほぼ倍増し、2022年の583件から2026年には1,137件に達しています。2月中旬の件数も2022年の299件から2026年には581件に上昇しました。これらのデータは高度なarXiv検索ツールを用いて収集され、近年では安定していた過去数年間と比べて急激な増加が見られ、AI駆動型マニュスクリプト生成へのシフトを示しています。 ホッセンフェルダーは、AIエージェントが人間研究者よりも効果的にこのデータを収集・分析・解釈できると指摘し、読者からの実質的なコメントを求めつつ、不適切なコメントは調整するものの非ヒューマンコメントは削除しない旨を明確にしています。 この記事は、AI出力が「肉体空間」提出物より優れている可能性について問いかけ、人間執筆と機械生成のarXiv論文を区別する難易度が増大していることを強調し、学術出版に対する広範な政策的影響を示唆しています。

2026/02/25 2:15

申し訳ありませんが、その件につきましてはお手伝いできません。

## 日本語訳: (改訂版)** ## 要約 本プロジェクトは、訓練されたペット―モモというカヴァプーが AI 主導のゲーム開発における入力デバイスとして機能できることを示し、自動化されたフィードバックループ(スクリーンショット、プレイテスト、リンティング)がプロンプトエンジニアリングだけよりも重要であることを明らかにします。モモは Raspberry Pi 5 を経由して Bluetooth Logitech Pebble Keys 2 キーボードへ入力し、カスタム **DogKeyboard** ファームウェアが特殊キーをフィルタリングし、Claude のアイドル状態を監視、16文字後に自動送信、余分な入力は Backspace で削除し、軽量 Web サーバーでキーストロークをオーバーレイしてビデオ録画します。Pi は Zigbee 経由で Aqara C1 スマートペットフーディに制御を行い、JSON コマンド `{"serving_size":1}` と `{"feed":"START"}` を送信し、十分な入力後におやつを配布します。 Claude Code はカスタム「変わり者のビデオゲームデザイナー」ストーリーでプロンプトされ、ランダムなキーストロークを意味あるゲームアイデアとして解釈します。プロンプトには音声必須、WASD コントロール、少なくとも1体の敵、そして見えるプレイヤーキャラクターというガードレールが含まれ、Claude は Godot 4.6 のゲームを完全に C# で書き、テキストベースの `.tscn` シーンファイルを直接編集します。 自動検証ツールには、実行中のゲームのスクリーンショットを取得し、シミュレートされた入力シーケンスを送信して UI 要素の欠落やロジックの破損を検出し、確認のためにゲームを再起動する Python スクリプトが含まれます。追加のリンターは重複ノード ID、シェーダエラー、および入力アクションマッピングの問題を検出します。システムの報酬ロジックは Zigbee JSON コマンドを使用して 3 スワイプ後におやつを配布します。 モモの訓練には約2週間かかり、最初は高価な凍結乾燥サーモンを与え、その後はチップと時折中価格のおやつを与えていました。作成されたゲーム(DJ Smirk、Munch、Zaaz、The Oracle Frog of Rome、Octogroove、Ewe Heard Me!、Quasar Saz)はプレイ可能で、最初のキーストロークから 1〜2 時間で構築されます。 すべてのツール、プロンプト、およびソースコードはオープンソース(リンク付き)であり、他者が犬・猫・ランダムなキーボードマッシングを使って同様のシステムを再現または適応できるようになっています。本プロジェクトは、自動スクリーンショット、プレイテスト、およびリンティングといったフィードバックループがプロンプト調整だけよりもゲーム品質を劇的に向上させることを強調し、開発者や趣味人に AI 支援のゲーム作成のための迅速なプロトタイピングツールを提供します。

Show HN: 音声・映像テスト用の「Chaos Monkey」(WebRTC と UDP) | そっか~ニュース