アジア向けライブ配信を自前で構築：香港・東京・シンガポールのサーバーに SRS オリジンと CDN

アジアの視聴者向けにライブ配信を自前で運用するなら、香港・東京・シンガポールの専用サーバーに SRS（または nginx-rtmp）のオリジンを置き、RTMP か SRT で受信し、HLS と WebRTC で出力して、CDN で視聴者に配る構成が基本です。IMIDC はこの構成に必要な要素をそろえています。中国本土へ CN2 GIA で接続する香港専用サーバー（月額 $139 から）、日本の専用サーバー、営業経由で構成するシンガポールのサーバー、10Gbps アップリンク、DDoS 対策、そして IMIDC CDN です。

自前ライブ配信基盤の全体像

ライブ配信基盤は「受信（インジェスト）」「オリジン／パッケージング」「配信」「再生」の 4 段階で構成されます。

1. 受信：配信者の OBS、vMix、ハードウェアエンコーダーが RTMP または SRT でオリジンへ送出。
2. オリジン：SRS がストリームを受け取り、必要に応じて複数ビットレートにトランスコードし、HLS セグメントを生成、WebRTC を提供し、ディスクに録画。
3. 配信：CDN がオリジンから HLS を取得し、視聴者に近い拠点でセグメントをキャッシュ。
4. 再生：HLS は hls.js、Video.js、ネイティブプレーヤー。1 秒未満の双方向性が必要なら WebRTC プレーヤー。

代表的な用途は、ウェビナーや社内タウンホール、オンライン授業、製品発表やイベント、そして第三者プラットフォームではなく独自ブランド・アクセス制御・録画を持ちたいゲーム／eスポーツ配信です。

受信・再生プロトコルの選び方

受信は RTMP か SRT、大規模配信は HLS、WebRTC は双方向性が重要な場面だけに使います。

SRS は 1 つのプロセスで RTMP、SRT、HLS、HTTP-FLV、WebRTC を扱えます。パーシャルセグメントを使う LL-HLS が必要な場合は、視聴者に低遅延を約束する前に、パッケージャーと CDN の両方が対応しているか確認してください。

専用サーバーに Docker で SRS をデプロイする

SRS は Docker と相性がよく、押さえるべき点はポート、WebRTC の候補 IP、永続化ディレクトリの 3 つです。

mkdir -p /opt/srs/conf /opt/srs/html /opt/srs/record
# put srs.conf (below) into /opt/srs/conf/srs.conf, then:
docker run -d --name srs --restart unless-stopped \
  -p 1935:1935 -p 1985:1985 -p 8080:8080 \
  -p 8000:8000/udp -p 10080:10080/udp \
  -e CANDIDATE=203.0.113.20 \
  -v /opt/srs/conf/srs.conf:/usr/local/srs/conf/srs.conf \
  -v /opt/srs/html:/usr/local/srs/objs/nginx/html \
  -v /opt/srs/record:/usr/local/srs/objs/record \
  ossrs/srs:5 ./objs/srs -c conf/srs.conf

docker logs -f srs          # watch publish / play events
ufw allow 1935/tcp; ufw allow 8000/udp; ufw allow 10080/udp

HLS、HTTP-FLV、WebRTC、SRT、録画、配信開始フックを含む本番向けの srs.conf：

listen              1935;
max_connections     3000;
daemon              off;
srs_log_tank        console;

http_api    { enabled on; listen 1985; }
http_server { enabled on; listen 8080; dir ./objs/nginx/html; }
rtc_server  { enabled on; listen 8000; candidate $CANDIDATE; }
srt_server  { enabled on; listen 10080; }

vhost __defaultVhost__ {
    hls {
        enabled         on;
        hls_fragment    2;
        hls_window      12;
        hls_path        ./objs/nginx/html;
        hls_m3u8_file   [app]/[stream].m3u8;
        hls_ts_file     [app]/[stream]-[seq].ts;
        hls_cleanup     on;
    }
    http_remux { enabled on; mount [vhost]/[app]/[stream].flv; }
    rtc        { enabled on; rtmp_to_rtc on; rtc_to_rtmp on; }
    srt        { enabled on; srt_to_rtmp on; }
    dvr {
        enabled     on;
        dvr_plan    session;
        dvr_path    ./objs/record/[app]/[stream]/[2006]-[01]-[02]_[15][04][05].mp4;
    }
    http_hooks {
        enabled     on;
        on_publish  http://127.0.0.1:8085/api/streams/on_publish;
    }
    play { gop_cache on; }
}

OBS または ffmpeg から送出して再生を確認します。

# OBS (RTMP):  Server  rtmp://203.0.113.20/live   Stream key  event1?secret=YOUR_KEY
# SRT push from ffmpeg (OBS can also output SRT):
ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4000k -g 60 \
  -c:a aac -b:a 128k -f mpegts \
  "srt://203.0.113.20:10080?streamid=#!::r=live/event1,m=publish"

# Playback URLs
# HLS       http://203.0.113.20:8080/live/event1.m3u8
# HTTP-FLV  http://203.0.113.20:8080/live/event1.flv
# WebRTC    http://203.0.113.20:1985/rtc/v1/whep/?app=live&stream=event1   (WHEP)

• エンコーダーのキーフレーム間隔は 2 秒にし、hls_fragment 2 と合わせます。
• CANDIDATE にはサーバーのパブリック IP を指定します。誤っていると WebRTC プレーヤーが接続できません。
• on_publish フックでアプリ側がストリームキーを検証できます。HTTP 200 で本文 0 を返せば許可、それ以外は拒否です。

アダプティブビットレートにするには、追加の画質を送出する ffmpeg トランスコーダーを置き、マスタープレイリストから参照します。

# simple ABR ladder: pull the source from SRS and publish 720p + 480p renditions
ffmpeg -i rtmp://127.0.0.1/live/event1 \
  -map 0:v -map 0:a -c:v libx264 -preset veryfast -s 1280x720 -b:v 2500k -g 60 \
     -c:a aac -b:a 128k -f flv rtmp://127.0.0.1/live/event1_720 \
  -map 0:v -map 0:a -c:v libx264 -preset veryfast -s 854x480 -b:v 1000k -g 60 \
     -c:a aac -b:a 96k  -f flv rtmp://127.0.0.1/live/event1_480

nginx-rtmp を使いたい場合：軽量で RTMP 受信から HLS 出力まで対応しますが、SRT と WebRTC にはネイティブ対応していません。

# nginx-rtmp alternative (nginx.conf, top level)
rtmp {
    server {
        listen 1935;
        application live {
            live on;
            hls on;
            hls_path /var/www/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;
            on_publish http://127.0.0.1:8085/api/streams/on_publish;
        }
    }
}

帯域の計算：視聴者数 × ビットレート

ピーク時の送信帯域は「同時視聴者数 × 平均ビットレート」に、プロトコルのオーバーヘッド約 10% を加えたものです。

計算式：1 時間あたり GB = Mbps × 3600 ÷ 8 ÷ 1000。10Gbps アップリンクのオリジン 1 台なら数百人規模は余裕を持って直接配信できますが、それ以上は CDN から視聴者に配信し、オリジンは CDN のキャッシュにだけ供給する形にします。受信側の帯域は小さく、1080p で配信者 1 人あたり 4〜6 Mbps 程度です。

オリジンと IMIDC CDN の連携

CDN には HTTPS でオリジンから HLS を取得させ、セグメントは長く、プレイリストは 1 秒程度だけキャッシュさせます。

# Nginx in front of SRS as the HTTPS origin for the CDN
server {
    listen 443 ssl;
    http2 on;
    server_name origin-live.example.com;
    ssl_certificate     /etc/nginx/ssl/origin-live.crt;
    ssl_certificate_key /etc/nginx/ssl/origin-live.key;

    location ~ \.m3u8$ {
        proxy_pass http://127.0.0.1:8080;
        add_header Cache-Control "max-age=1" always;
        add_header Access-Control-Allow-Origin "*" always;
    }
    location ~ \.(ts|m4s)$ {
        proxy_pass http://127.0.0.1:8080;
        add_header Cache-Control "max-age=86400" always;
        add_header Access-Control-Allow-Origin "*" always;
    }
}

• origin-live.example.com のようなホスト名をオリジンに向け、IMIDC CDN のオリジンとして設定します。視聴者は CDN 側のホスト名を使います。
• プレイリスト（.m3u8）はセグメントごとに更新されるため 1〜2 秒、セグメントは変化しないため長期間キャッシュします。
• 有料・限定公開のイベントでは、CDN の署名付き URL やトークン認証を使います。
• WebRTC は HTTP 型 CDN ではキャッシュされないため、オリジン（または少数の地域 SRS エッジ）で処理します。

録画とストレージへのアーカイブ

すべての配信をオリジンで録画し、終了後にオブジェクトストレージへ移してリプレイやオンデマンド視聴に使います。

# move finished recordings to S3-compatible object storage every 10 minutes (cron)
*/10 * * * * rclone move /opt/srs/record s3store:live-archive --min-age 10m --delete-empty-src-dirs

上記設定の録画ディレクトリは公開 Web ディレクトリの外にあるため、URL を推測されて元データをダウンロードされることはありません。長期保管は別のストレージサーバーかオブジェクトストレージのバケットに置き、リプレイを公開する場合は HLS のビットレートラダーにトランスコードします。

オリジンの設置場所と DDoS 対策

オリジンは配信者と主な視聴者の近くに置き、公開エンドポイントを保護します。

• オリジンには IMIDC の DDoS 対策を付けましょう。特にゲームや eスポーツ配信は攻撃を受けやすい傾向があります。
• 公開するのは必要なポートだけ：受信用の 1935/10080（できれば配信者 IP に限定）、CDN オリジン用の 443、WebRTC 用ポート。
• ストリームキーはイベントごとに変更し、配信開始フックで検証します。
• 中国本土の視聴者向け配信は内容が合法である必要があり、本土でのライブ映像サービスには別途ライセンス規制が関わる場合があります（法的助言ではありません）。

最適な IMIDC 構成の選び方

配信者の数、トランスコード負荷、CDN が吸収するトラフィック量からオリジンの規模を決めます。

• 数百人までの社内ウェビナーや授業：香港専用サーバーまたは日本専用サーバー 1 台から HLS を直接配信。
• 数千人規模の公開イベントやゲーム配信：DDoS 対策付きの専用オリジン + IMIDC CDN。
• 複数地域のプラットフォーム：香港と東京にオリジン、シンガポールは営業経由。自社 ASN があれば受信に BGP と Anycast を活用。
• GPU や多コアのトランスコードノード、アーカイブ用大容量ディスク：IMIDC 営業にカスタム構成をご相談ください。

よくある質問

アジアの視聴者向けにライブ配信を自前でホストするなら、サーバーはどこが最適？

視聴者の多くが中国本土にいるなら、IMIDC の香港サーバーは中国電信 CN2 GIA を使うため香港が定番です。日本・韓国向けなら東京、東南アジア向けならシンガポールが適しており、視聴者が混在する場合はオリジン 1 つと CDN の組み合わせで対応できます。

同時視聴 1,000 人にはどれくらいの帯域が必要？

1 人あたり 3 Mbps なら、ピーク送信帯域は約 3 Gbps、転送量は 1 時間あたり約 1.35 TB です。この規模はオリジンから直接ではなく CDN 経由で配信すべきです。

SRS と nginx-rtmp のどちらを使うべき？

SRS は RTMP、SRT、HLS、HTTP-FLV、WebRTC を 1 つのサーバーで扱え、HTTP API も備えているため、より包括的な選択肢です。nginx-rtmp は軽量で、シンプルな RTMP から HLS への変換には十分です。

数千人の視聴者に 1 秒未満の遅延で配信できますか？

1 秒未満の配信には WebRTC が必要ですが、視聴者あたりの負荷が HLS よりはるかに大きく、一般的な CDN ではキャッシュできません。多くのプラットフォームは配信者や参加者に WebRTC、一般視聴者に HLS や LL-HLS を使い分けています。

IMIDC は配信オリジン向けの DDoS 対策を提供していますか？

はい。IMIDC は配信オリジンとして使うサーバーに追加できる DDoS 対策を提供しています。想定するイベント規模を営業に伝えれば、トラフィックに合った防御とポート構成を相談できます。

自社の配信プラットフォームを計画中ですか？香港専用サーバーや東京の専用サーバーと IMIDC CDN から始めるか、チケットを送信してオリジンの規模設計を IMIDC チームにご相談ください。