ストリーミングサーバーの構築：1 本のアップロードで視聴者は何人でも

自前のサーバーを使わずに配信すると、映像は視聴者 1 人ずつに個別に送られます。視聴者が 10 人なら同じデータを 10 回、100 人なら 100 回送ることになります。自宅やオフィスのアップロードは視聴者が数人増えただけで詰まり、パソコンには余裕があるのに映像が途切れ始めます。

ストリーミングサーバーはこれを逆にします。サーバーへ送るストリームはちょうど 1 本だけで、そのサーバーがすべての視聴者に配信します。これにより、自分の回線が運ぶのは常にアップロード 1 本だけになり、視聴者が 10 人でも 1 万人でもまったく変わりません。本記事では、なぜこの仕組みがこれほどうまく働くのか、そうしたサーバーをどう構築するのか、どのプロトコルがどれだけの遅延を伴うのか、そして実際にどれだけのトラフィックが発生するのかを解説します。

問題：アップロードがボトルネックになる

映像は途切れることのない流れです。1080p で 1 秒あたり 60 フレームのストリームは、内容によって 4.5 から 8 Mbit/s、720p なら 3 から 5 Mbit/s を必要とします。このビットレートが視聴者 1 人ごとに、配信中ずっと、休みなく流れます。

ドイツの平均的な家庭用回線のアップロードは 10 から 50 Mbit/s で、光回線でもアップロードは 50 から 100 Mbit/s にとどまるものが多くあります。そのため計算はすぐに行き詰まります。

さらに、見落とされがちな 2 つ目の問題があります。お使いの回線は、家庭やオフィスのほかのすべての通信とこの帯域を分け合っています。誰かが大きなファイルをアップロードしたり、バックアップが走り出したりすれば、その瞬間にストリームは崩れます。データセンターのサーバーにこの問題はなく、回線は自分だけのものです。

仕組み：1 回送って、何度でも配る

構成は 3 つの部分からできています。

• 送信側、つまり OBS、ffmpeg、ハードウェアエンコーダーが、ストリームをサーバーへ送ります。これをインジェストと呼びます。
• サーバーはこの 1 本のストリームを受け取り、目的の配信形式に変換して待機させます。
• 視聴者はサーバーからストリームを受け取ります。これをエグレスと呼び、視聴者数に応じて増えていく部分です。

決定的なのは非対称性です。自分からサーバーまでの経路は1 回だけ通りますが、サーバーから視聴者までの経路は何千回も通ります。だからこそ、自分の回線に必要なアップロードはストリーム 1 本分だけで、サーバーには視聴者数に見合う回線が必要になります。

実際に発生するトラフィック量

帯域は計算の半分にすぎません。より重要なのは転送量です。多くの事業者はこれを基準に課金するからです。式は単純です。

GB 単位の転送量 = Mbit/s 単位のビットレート × 秒数 × 視聴者数 ÷ 8000

現実的な例をいくつか挙げます。

最後の列の数字は、ストリーミングと従量課金が相性の悪い理由そのものです。来場の多い配信が 1 回あるだけで 1 か月分の無料枠を使い切ることがあり、そこから先は 1 TB ごとに追加で請求されます。無制限トラフィックのプランなら、この計算は完全に不要です。回線を 200 GB 通ろうと 50 TB 通ろうと、月額は変わりません。

どのソフトウェアが向いているか

最初に選ぶなら、nginx と RTMP モジュールが最も自然です。どこでも入手でき、資料も豊富で、同じサーバーを後から手を加えることなく視聴ページ用の Web サーバーとしても使えます。

nginx と RTMP でストリーミングサーバーを構築する

インストールする

Debian と Ubuntu では、パッケージ libnginx-mod-rtmp にモジュールが含まれているので、自分でビルドする必要はありません。

apt update
apt install -y nginx libnginx-mod-rtmp ffmpeg

AlmaLinux と Rocky Linux では、モジュールは EPEL リポジトリから入ります。

dnf install -y epel-release
dnf install -y nginx nginx-mod-rtmp ffmpeg

設定する

RTMP の設定は nginx.conf の http ブロックの外側に書きます。ここが最初につまずく点として最も多いところです。動作する最小構成は次のとおりです。

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # 通常の視聴者向けの HLS
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # 配信は自分のアドレスからのみ許可する
            allow publish 203.0.113.10;
            deny publish all;

            # 視聴は誰でもできる
            allow play all;
        }
    }
}

HLS のファイルは、その後は通常の Web サーバーが配信します。そのためには http 側に小さなブロックを置くだけで足ります。

server {
    listen 80;
    server_name stream.example.com;

    location /hls {
        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
        }
        root /var/www/stream;
        add_header Cache-Control no-cache;
        add_header Access-Control-Allow-Origin *;
    }
}

ディレクトリを作成し、設定を検証して、再読み込みします。

mkdir -p /var/www/stream/hls
chown -R www-data:www-data /var/www/stream
nginx -t && systemctl reload nginx

ポートを開放する

RTMP はポート 1935 を、配信は 80 と 443 を使います。nftables または ufw では次のようにします。

ufw allow from 203.0.113.10 to any port 1935 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp

1 行目に注意してください。配信用のポートは自分のアドレスだけに開いています。世界に開いた RTMP ポートは、アドレス帯が丸ごと自動的に調べられているため数日のうちに見つかり、そうなると他人が自分の回線を使って配信を始めます。

OBS から配信する

OBS の設定、配信の順に開き、サービスに「カスタム」を指定します。

「出力」でビットレートを設定します。目安は、1080p60 で 6000 kbit/s、1080p30 で 4500 kbit/s、720p30 で 3000 kbit/s です。キーフレーム間隔は 2 秒にしてください。そうしないと HLS のセグメント長が不均一になり、切り替えのときにプレーヤーが引っかかります。

視聴する

ストリームはその後 https://stream.example.com/hls/kanal1.m3u8 に置かれ、HLS に対応したどのプレーヤーでも開けます。ブラウザーなら hls.js や Video.js などです。手早く確認するだけなら、VLC の「ネットワークストリームを開く」で足ります。

複数のプラットフォームへ同時に配信する

これが自前のサーバーの 2 つ目の大きな利点です。3 本のアップロードを並行させて自分の回線を破裂させる代わりに、サーバーへ 1 回送り、そこから先を配り分けます。そのために application ブロックへ配信先ごとに 1 行を追加します。

application live {
    live on;
    record off;

    push rtmp://live.plattform-a.example/app/STREAM_KEY;
    push rtmp://live.plattform-b.example/app/STREAM_KEY;
}

このときアップロードはストリーム 1 本のままです。複製を担うのはサーバーで、サーバーにとって帯域はまさに本来の役目です。

遅延：どのプロトコルを何に使うか

遅延はほぼすべて配信側で生まれ、送信側では生まれません。多くの人が見当違いの場所を探すので、ここを理解しておくことが大切です。

遅延が小さくなるほど、視聴者 1 人あたりの費用は上がります。HLS は単純なファイルの集まりで、どの Web サーバーもどのキャッシュも配信できるため、最も安く済みます。一方 WebRTC は視聴者ごとに専用の接続を維持するため、処理能力の消費がはるかに大きくなります。低遅延は本当に必要な場面だけで採用してください。

トランスコード：どこから見合うか

サーバーがストリームをそのまま中継しているだけなら、処理能力はほとんど要りません。この方式なら最新の 1 コアで数百人の視聴者に対応でき、ボトルネックは回線だけです。

回線の弱い視聴者も見られるように複数の画質を用意し始めると、状況が変わります。画質の段階が増えるたびに、その分の計算が必要になります。

ffmpeg -i rtmp://127.0.0.1/live/kanal1 \
  -c:v libx264 -preset veryfast -b:v 3000k -s 1280x720 -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_720 \
  -c:v libx264 -preset veryfast -b:v 1200k -s 854x480  -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_480

1 段階あたり 2 から 4 コアを見込んでください。3 段階なら、それだけで 8 から 12 コアを常に占有します。だからこそ、本当に必要かをよく考えてください。パソコンや Wi-Fi で見る人が大半の視聴者層なら、よく選んだ 1 段階だけで足りることも多くあります。

対策：誰が配信できるか

ストリーミングサーバーは外から見えるので、必ず見つけられます。日常の運用なら 3 つの対策で足ります。

• 配信用ポートのファイアウォール。1935 に到達できるのは自分のアドレスだけにします。自分のアドレスが変わる環境なら、代わりにサーバーへの VPN 接続を使ってください。
• ストリームキーの検証。on_publish を使うと、配信が試みられるたびに nginx が小さなスクリプトを呼び出し、キーを一覧と照合して、一致しなければ拒否します。
• 過負荷に対する基本的な保護。ストリーミングサーバーは停止がすぐ目に見えるため、狙われやすい対象です。KernelHost では 3.2 Tbps の処理能力を持つフラッド対策がすべてのサーバーに入っており、自分で設定する必要はありません。詳しくは DDoS 対策のページをご覧ください。

設置場所の選び方と複数台の構成

サーバーを置くべきなのは自分の近くではなく、視聴者の近くです。自分からサーバーへの接続は一度確立すれば、大陸の半分を越えても安定して流れ続けます。一方、視聴者への接続は読み込み時間と離脱率を左右します。

視聴者の大半がヨーロッパにいるなら、ドイツの拠点が正解です。複数の大陸に分かれているなら、2 台目のサーバーと DNS による振り分けが見合い、各視聴者は最も近い拠点にたどり着きます。KernelHost はそのためにドイツ、米国西海岸、米国東海岸、シンガポール、韓国に拠点を用意しています。一覧はサーバー拠点でご確認いただけます。

配信するのが生の映像ではなくファイル、つまり更新データ、画像、動画アーカイブである場合は、適した道具はストリーミングサーバーではなく、その前に置くキャッシュです。その仕組みは記事「自前の CDN サーバーを構築する」で解説しています。

どのサーバーが向いているか

ストリーミングサーバーでは、Web サーバーとは重要度の順序が違います。

1. 回線とトラフィック。ここが常にボトルネックです。絞られていない本物のギガビット回線は、6 Mbit/s で約 160 人の視聴者を支えます。
2. 無制限トラフィック。従量課金のプランはストリーミングではほとんど見積もれません。盛り上がった夜が 1 回あるだけで 1 か月分の転送量を使い切るからです。
3. CPU。トランスコードをしない限り二番目の問題です。トランスコードを始めると、ここが 2 つ目のボトルネックになります。
4. RAM とディスク。最も影響が小さい部分です。録画を残すようになって初めて、ディスク容量が課題になります。

まさにこの用途に合わせているのが、当社の無制限トラフィックのルートサーバーです。1 台ごとに実測の 2 × 1 Gbit/s 回線、絞りのない無制限の転送量、転送した量に左右されない固定の月額、そして 3.2 Tbps のフラッド対策を標準で備えています。サーバーは 30 秒未満で用意され、完全な root 権限、IPv4、/64 の IPv6 ネットワークが付きます。料金はプリペイド方式で月単位の解約ができるので、小さなプランから始めて、視聴者が増えたら合わせて大きくできます。