Skip to content
KitploitKITPLOIT
ツールエクスプロイトブログ
Log in
提出
ツールエクスプロイトブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
AV-Chaos-Monkey — Audio Video Testing(webRTCおよびUDP)向けのChaos Monkey | Kitploit
ツール/GitHubGitHub/mdsadiqmd/av-chaos-monkey
ウェブセキュリティネットワークセキュリティペネトレーションテストクラウドセキュリティDevSecOpsカオスエンジニアリング
GitHubmdsadiqmd/av-chaos-monkey

AV-Chaos-Monkey

Audio Video Testing(webRTCおよびUDP)向けのChaos Monkey

リポジトリを見る
52217ヶ月前Kitploit レビュー済み

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

AV Chaos Monkey

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

アーキテクチャ

image
  1. メディア処理パイプライン:

    • FFmpegが起動時に入力ビデオをH.264 Annex-BおよびOgg/Opusに変換
    • NALリーダーがH.264ストリーム(SPS/PPS/IDR/スライス)を解析
    • OpusリーダーがOggコンテナから20msのオーディオフレームを抽出
    • フレームはメモリにキャッシュされ、全参加者間で共有(ゼロコピー)
    • 参加者ごとのエンコードに比べてCPU使用量を約90%削減
  2. コントロールプレーン:

    • HTTPサーバー(:8080)がREST APIを介してテストライフサイクルを管理
    • スパイクスケジューラがカオスイベントを分散(均等/ランダム/前寄せ/後寄せ/レガシー)
    • ネットワークデグレーダーがカオスを適用: パケットロス(1-25%)、ジッタ(10-50ms)、ビットレート低減(30-80%)、フレームドロップ(10-60%)
    • ロードされたカオス設定が参加者プールに適用される
  3. 参加者プール:

    • ポッド間で自動パーティション分割: participant_id % total_partitions = partition_id
    • 各参加者がRTPストリームを生成(PT=96 ビデオ、PT=111 オーディオ)
    • 参加者IDがRTP拡張ヘッダー(ID=1)に埋め込まれる
    • プールサイズ: 1-100(ローカル)、100-500(Docker)、500-1500(Kubernetes)
  4. 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のみ):

    root@kitploit:~
    オーケストレーターポッド (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参加者)

    root@kitploit:~
    # オーケストレーターを起動
    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):

    root@kitploit:~
    {
      "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 がインストールされていること
    root@kitploit:~
    # オーケストレーターコンテナをビルドして起動
    ./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 を編集):

    root@kitploit:~
    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. Nixを使用したKubernetes(本番規模)

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

    前提条件:

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

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

    root@kitploit:~
    # Nixが提供: Go、Docker、kubectl、kind、ffmpeg
    nix develop
    
    # またはdirenvを使用して自動アクティベーション
    echo "use flake" > .envrc
    direnv allow
    

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

    root@kitploit:~
    # 最適な設定で自動デプロイ(システムリソースを検出)
    ./scripts/start_everything.sh run -config config/config.json
    
    # またはカスタムメディアファイルを指定
    ./scripts/start_everything.sh run --media=path/to/video.mp4 -config config/config.json
    

    実行の流れ:

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

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

    オプションA: UDPレシーバー(Kubernetes推奨)

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

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

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

    アーキテクチャの流れ:

    root@kitploit:~
    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セットアップ

    root@kitploit:~
    # イメージのビルドとロード
    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
    

    クリーンアップ

    root@kitploit:~
    # Kubernetesリソースを削除
    ./scripts/cleanup.sh
    
    # またはクラスター全体を削除
    kind delete cluster --name av-chaos-monkey
    

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

    root@kitploit:~
    # 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
    

    APIリファレンス

    テストライフサイクル

    root@kitploit:~
    # テスト作成
    POST /api/v1/test/create
    {
      "test_id": "optional_id",
      "num_participants": 100,
      "video": {...},
      "audio": {...},
      "duration_seconds": 600,
      "spikes": [...],
      "spike_distribution": {
        "strategy": "even",
        "min_spacing_seconds": 5,
        "jitter_percent": 15
      }
    }
    
    # テスト開始
    POST /api/v1/test/{test_id}/start
    
    # メトリクス取得
    GET /api/v1/test/{test_id}/metrics
    
    # テスト停止
    POST /api/v1/test/{test_id}/stop
    

    WebRTCシグナリング

    root@kitploit:~
    # SDPオファーを取得
    GET /api/v1/test/{test_id}/sdp/{participant_id}
    
    # SDPアンサーを設定
    POST /api/v1/test/{test_id}/sdp/{participant_id}
    {"sdp_answer": "v=0..."}
    

    カオス注入

    root@kitploit:~
    # スパイク注入
    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"}
    }
    

    設定

    スパイクの種類

    種類パラメータ効果
    rtp_packet_lossloss_percentage (0-100)RTP層でパケットをドロップ
    network_jitterbase_latency_ms, jitter_std_dev_ms遅延変動を追加
    bitrate_reducenew_bitrate_kbpsビデオエンコードをスロットル
    frame_dropdrop_percentage (0-100)ビデオフレームをスキップ
    bandwidth_limitbandwidth_kbps総スループットを上限

    分散設定

    root@kitploit:~
    {
      "spike_distribution": {
        "strategy": "even",
        "min_spacing_seconds": 5,
        "jitter_percent": 15,
        "respect_min_offset": true
      }
    }
    

    クライアント統合

    UDPレシーバー(Go)

    root@kitploit:~
    # RTP解析機能付きの提供レシーバー
    go run examples/go/udp_receiver.go 5002
    

    出力:

    root@kitploit:~
    Listening for RTP packets on UDP port 0.0.0.0:5002
    Packet #100 from 127.0.0.1:xxxxx:
      Participant ID: 1001
      Payload Type: 96 (H.264 video)
      Sequence: 1234
      Timestamp: 90000
      SSRC: 1001000
      Payload Size: 1200 bytes
    
    ═══════════════════════════════════════════════════════════
                        パケット統計                           
    ═══════════════════════════════════════════════════════════
    Duration: 60s
    Total Packets: 180000 (3000 pkt/s)
    Total Bytes: 450 MB (60 Mbps)
    
    Media Type Breakdown:
      Video (H.264): 120000 packets (66.7%)
      Audio (Opus):  60000 packets (33.3%)
    
    Unique Streams (SSRCs): 1500
    Unique Participants: 1500
    

    WebRTCレシーバー(Go)

    root@kitploit:~
    # 単一参加者
    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
    
    # 実際のテストIDを使用した例
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 chaos_test_1770831684 150
    

    注意: WebRTCは1:1接続が必要です。Kubernetesの場合は、全参加者を自動集約するUDPレシーバーを使用してください。

    カスタム統合

    RTPパケットフォーマット:

    root@kitploit:~
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           timestamp                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           synchronization source (SSRC) identifier            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Extension ID=1 | Length=4    |    Participant ID (uint32)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         H.264/Opus Payload                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    ペイロードタイプ:

    • 96: H.264ビデオ(RFC 6184)
    • 111: Opusオーディオ(RFC 7587)

    参加者IDの抽出:

    root@kitploit:~
    // 拡張ビットが設定されているか?
    if (packet[0] & 0x10) != 0 {
        offset := 12 + int(packet[0]&0x0F)*4  // CSRCをスキップ
        extID := binary.BigEndian.Uint16(packet[offset:])
        if extID == 1 {
            participantID := binary.LittleEndian.Uint32(packet[offset+4:])
        }
    }
    

    パフォーマンス

    リソース要件

    参加者数メモリCPU帯域幅
    1002GB2コア250 Mbps
    5006GB8コア1.2 Gbps
    100012GB16コア2.5 Gbps
    150018GB24コア3.7 Gbps

    Kubernetesのスケーリング

    • 自動スケーリング: 参加者数に基づいて最適なポッド数を計算
    • ポッド容量: ポッドあたり150参加者(設定可能)
    • 最大ポッド数: 10(StatefulSetの制限)
    • ポート範囲: パーティションあたり10,000ポート

    スループット

    参加者あたり(1280x720@30fps + Opus):

    • ビデオ: ~2.5 Mbps(H.264)
    • オーディオ: ~128 Kbps(Opus)
    • 合計: ~2.6 Mbps
    • パケット: ~90ビデオ + 50オーディオ = 140 pkt/s

    監視

    Prometheusメトリクス

    root@kitploit:~
    # /metrics エンドポイントで公開
    av_chaos_monkey_participants_total
    av_chaos_monkey_packets_sent_total
    av_chaos_monkey_bytes_sent_total
    av_chaos_monkey_spikes_active
    av_chaos_monkey_packet_loss_percent
    av_chaos_monkey_jitter_ms
    

    Grafanaダッシュボード

    root@kitploit:~
    # Dockerモード: 監視スタックを起動
    docker-compose --profile monitoring up
    
    # Kubernetesモード: 監視をデプロイ
    kubectl apply -f k8s/monitoring/prometheus-rbac.yaml
    kubectl apply -f k8s/monitoring/prometheus.yaml
    kubectl apply -f k8s/monitoring/grafana.yaml
    
    # Grafanaにアクセス
    # Docker: http://localhost:3000
    # Kubernetes: http://localhost:30030 (NodePort)
    # デフォルト認証情報: admin/admin
    
    # Prometheusにアクセス
    # Docker: http://localhost:9091
    # Kubernetes: http://localhost:30090 (NodePort)
    

    Kubernetes自動検出:

    • オーケストレーターポッドに prometheus.io/scrape: "true" のアノテーションが付与されている
    • Prometheusが全ポッドの /metrics を5秒ごとにスクレイピング
    • GrafanaにPrometheusデータソースが事前設定されている
    • ダッシュボードは起動時に自動プロビジョニング

    リアルタイム統計

    root@kitploit:~
    # テストメトリクスを取得
    curl http://localhost:8080/api/v1/test/{test_id}/metrics | jq
    
    # 出力
    {
      "aggregate": {
        "total_frames_sent": 45000,
        "total_packets_sent": 180000,
        "total_bitrate_kbps": 250000,
        "avg_jitter_ms": 12.5,
        "avg_packet_loss": 2.3,
        "avg_mos_score": 4.1
      }
    }
    

    トラブルシューティング

    UDPパケットを受信しない

    root@kitploit:~
    # UDPターゲット設定を確認
    kubectl logs orchestrator-0 | grep "UDP transmission enabled"
    
    # UDPリレーが動作しているか確認
    kubectl get pod udp-relay
    
    # ポートフォワードを確認
    ps aux | grep "kubectl port-forward"
    
    # UDP接続をテスト
    nc -u -z localhost 5002
    

    WebRTC接続に失敗する

    root@kitploit:~
    # TURNサーバーを確認
    kubectl get svc coturn-lb
    
    # ICE候補を確認
    kubectl logs orchestrator-0 | grep "ICE"
    
    # TURN接続をテスト
    turnutils_uclient -v -u webrtc -w webrtc123 <turn-server>:3478
    

    メモリ使用量が多い

    root@kitploit:~
    # ポッドあたりの参加者数を確認
    kubectl exec orchestrator-0 -- curl -s http://localhost:8080/api/v1/test/{test_id}/metrics | jq '.participants | length'
    
    # 参加者を減らすかポッド数を増やす
    go run tools/k8s-start/main.go -replicas 10 -participants 1000
    
    # Dockerメモリを増やす(Docker Desktop)
    # 設定 → リソース → メモリ → 16GB
    

    UDPレシーバーでのパケットロス

    単一のUDPソケットは、カーネルバッファのオーバーフローなしで3000以上の同時ストリームを処理できません。解決策:

    • UDPリレーを使用(転送前に集約)
    • ソケットバッファを増やす: setsockopt(SO_RCVBUF, 8MB)
    • ベースラインの損失を測定アーティファクトとして許容

    ライセンス

    BSD 3-Clause License

    貢献

    貢献歓迎!主な領域:

    • 追加のスパイクタイプ(CPUスロットル、メモリプレッシャー)
    • より多くの分散戦略(波状、バースト)
    • 拡張メトリクス(MOS計算、RTCPフィードバック)
    • クライアントライブラリ(Python、Rust、TypeScript)

    参考文献

    • RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
    • RFC 6184 - RTP Payload Format for H.264 Video
    • RFC 7587 - RTP Payload Format for Opus
    • WebRTC Specification
    ツールをダウンロード