ESC

Start typing to search across invoices, services, domains, tickets, and more...

Search... Ctrl+K
活用シーンとソリューション

VOD・ショート動画プラットフォームのバックエンド構築:ストレージサーバー、FFmpeg HLS 変換、MinIO、CDN

8 ステップ 17 分で読めます 7 回閲覧 0
目次

動画配信(VOD)やショート動画プラットフォームのバックエンドに必要なのは、元動画と変換済みファイルを保存するストレージ用専用サーバー、HLS のビットレートラダーを出力する ffmpeg トランスコードパイプライン、MinIO などの S3 互換オブジェクトストレージ、そして帯域の大半を担う CDN の 4 つです。IMIDC は香港(中国本土へ CN2 GIA)、東京、シンガポール、ロサンゼルスなどでこの基盤を提供しており、香港専用サーバーは月額 $139 から、ロサンゼルス専用サーバーは月額 $499 から、10Gbps アップリンク、DDoS 対策、IMIDC CDN も利用できます。

要点
  • リージョン:中国向けは香港、地域向けは東京・シンガポール・台北・ソウル・バンコク・ロサンゼルス。
  • 香港専用サーバー月額 $139 から、台湾専用サーバー月額 $199 から、ロサンゼルス専用サーバー月額 $499 から。
  • 10Gbps アップリンク、SSD ストレージ、DDoS 対策、自社ストレージ機器向けの 1U〜フルラックのコロケーション。
  • IMIDC CDN が HLS セグメントを配信し、ストレージサーバーは最前線ではなくオリジンとして動作。
  • 既存の動画ライブラリを移す際は無料のサーバー移行を利用可能。

アップロードから再生までの VOD パイプライン

どの動画プラットフォームも、アップロード→元動画の保存→トランスコード→各画質の保存→CDN 配信という同じ流れをたどります。

  1. アップロード:クライアントは署名付き URL でオブジェクトストレージへ直接アップロードし、API サーバーが大きなファイルを中継しないようにします。
  2. キュー:アップロード完了イベントでジョブをキュー(Redis、RabbitMQ、DB テーブル)に投入します。
  3. トランスコード:ワーカーサーバーが ffmpeg で HLS ラダー、カバー画像、短いプレビューを生成します。
  4. 保存:変換結果は公開読み取りの HLS バケットへ、元動画はコールドストレージへ。
  5. 配信:プレーヤーは CDN から master.m3u8 を読み込み、CDN は不足分のセグメントをストレージのオリジンから取得します。

タイトル、投稿者、再生数、審査状態などのメタデータは API サーバーの通常のデータベースに、動画データそのものはストレージサーバーに置きます。

ffmpeg によるトランスコード:HLS ビットレートラダー

各動画を一度に複数の解像度へエンコードし、キーフレームをそろえることで、プレーヤーが画質をスムーズに切り替えられます。

mkdir -p out/v0 out/v1 out/v2 out/v3
ffmpeg -i input.mp4 \
  -filter_complex "[0:v]split=4[a][b][c][d];[a]scale=-2:1080[v0];[b]scale=-2:720[v1];[c]scale=-2:480[v2];[d]scale=-2:360[v3]" \
  -map "[v0]" -c:v:0 libx264 -b:v:0 5000k -maxrate:v:0 5350k -bufsize:v:0 7500k \
  -map "[v1]" -c:v:1 libx264 -b:v:1 2800k -maxrate:v:1 3000k -bufsize:v:1 4200k \
  -map "[v2]" -c:v:2 libx264 -b:v:2 1400k -maxrate:v:2 1500k -bufsize:v:2 2100k \
  -map "[v3]" -c:v:3 libx264 -b:v:3 800k  -maxrate:v:3 856k  -bufsize:v:3 1200k \
  -map a:0 -map a:0 -map a:0 -map a:0 -c:a aac -b:a 128k -ac 2 \
  -preset medium -profile:v high -pix_fmt yuv420p \
  -force_key_frames "expr:gte(t,n_forced*2)" -sc_threshold 0 \
  -f hls -hls_time 4 -hls_playlist_type vod -hls_flags independent_segments \
  -hls_segment_filename "out/v%v/seg_%04d.ts" \
  -master_pl_name master.m3u8 \
  -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2 v:3,a:3" \
  out/v%v/index.m3u8
画質解像度(16:9)映像ビットレート音声想定する視聴者
1080p1920x10805,000 kbps128 kbps AACPC、テレビ、Wi-Fi
720p1280x7202,800 kbps128 kbps AAC電波の良い 4G/5G のスマートフォン
480p854x4801,400 kbps128 kbps AAC混雑したモバイル回線
360p640x360800 kbps128 kbps AAC電波が弱い、データ節約モード
  • -force_key_frames "expr:gte(t,n_forced*2)" はフレームレートに関係なく 2 秒ごとにキーフレームを入れ、-sc_threshold 0 で全画質の位置をそろえます。
  • H.264 はどの端末でも再生できます。後から HEVC や AV1 のラダーを追加すれば、対応端末の帯域を削減できます。
  • CPU トランスコードはコア数に比例して伸びるため、多コアの専用サーバーを並べるのが最もシンプルなワーカープールです。数コアごとに 1 ジョブを割り当て、サーバー追加でスケールします。

ショート動画の要点:縦型動画と即時再生

ショート動画アプリは最初のフレームが出るまでの速さが勝負なので、短いセグメント、少ない画質段数、プレビューの先読みを使います。

# vertical short video: 3-step ladder, 2 s segments for a fast first frame
ffmpeg -i clip.mp4 \
  -filter_complex "[0:v]split=3[a][b][c];[a]scale=1080:-2[v0];[b]scale=720:-2[v1];[c]scale=540:-2[v2]" \
  -map "[v0]" -c:v:0 libx264 -b:v:0 3500k -maxrate:v:0 3750k -bufsize:v:0 5000k \
  -map "[v1]" -c:v:1 libx264 -b:v:1 2000k -maxrate:v:1 2150k -bufsize:v:1 3000k \
  -map "[v2]" -c:v:2 libx264 -b:v:2 1000k -maxrate:v:2 1070k -bufsize:v:2 1500k \
  -map a:0 -map a:0 -map a:0 -c:a aac -b:a 96k \
  -preset medium -force_key_frames "expr:gte(t,n_forced*2)" -sc_threshold 0 \
  -f hls -hls_time 2 -hls_playlist_type vod \
  -hls_segment_filename "short/v%v/seg_%03d.ts" -master_pl_name master.m3u8 \
  -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2" short/v%v/index.m3u8

# cover image and a small progressive MP4 preview for feeds
ffmpeg -ss 1 -i clip.mp4 -frames:v 1 -vf scale=540:-2 short/cover.jpg
ffmpeg -i clip.mp4 -t 6 -vf scale=360:-2 -c:v libx264 -b:v 400k -an -movflags +faststart short/preview.mp4
  • セグメントは 2 秒にし、フィードの次の動画の先頭セグメントを先読みします。
  • 60 秒以下のクリップなら 3 段階で十分なことが多く、段数を増やしてもストレージが増えるだけで体験はあまり変わりません。
  • カバー画像と無音プレビューはアップロード時に生成し、HLS リクエスト前にフィードを表示できるようにします。

MinIO によるオブジェクトストレージとホット/コールド階層

変換済みファイルは専用サーバー上の S3 互換オブジェクトストレージに保存し、視聴頻度に応じて階層化します。

# single-node MinIO on a storage dedicated server (use distributed mode across 4+ servers for HA)
docker run -d --name minio --restart unless-stopped \
  -p 9000:9000 -p 9001:9001 \
  -v /data/minio:/data \
  -e MINIO_ROOT_USER=vodadmin \
  -e MINIO_ROOT_PASSWORD=replace-with-a-long-random-secret \
  minio/minio server /data --console-address ":9001"

# buckets: raw uploads (private) and hls output (public read via CDN)
mc alias set vod http://127.0.0.1:9000 vodadmin replace-with-a-long-random-secret
mc mb vod/raw
mc mb vod/hls
mc anonymous set download vod/hls
mc ilm rule add vod/raw --expire-days 180      # drop raw uploads after 180 days
mc mirror --overwrite out/ vod/hls/videos/abc123/

MinIO は AGPLv3 ライセンスで、コミュニティ版の配布形態は変更されてきたため、本番利用前に現行のエディションとライセンスを確認してください。SeaweedFS、Garage、Ceph RGW も S3 互換の選択肢です。この例の raw バケットはアップロードの一時置き場にすぎないため、元動画や高画質のメザニンファイルは再トランスコード用にコールドストレージへ保管してください。

階層保存するものハードウェアアクセス傾向
ホット新着・人気動画の変換済みファイルNVMe/SSD のストレージサーバーCDN からの取得が常時発生
ウォームロングテールの変換済みファイル大容量 HDD RAID やイレイジャーコーディングの専用サーバー時々の取得、CDN のキャッシュミス
コールド元動画とメザニンファイル大容量 HDD サーバーやコロケーションのストレージ筐体再トランスコード時のみ読み出し

目安として、上記 4 段ラダーの合計は約 10.5 Mbps、動画 1 分あたり約 79 MB です。1,000 時間のコンテンツなら変換済みファイルだけで約 4.7 TB、これに元動画が加わります。

CDN 配信と帯域の実コスト

動画プラットフォームの最大のランニングコストはストレージではなく帯域なので、サーバーを選ぶ前に見積もりましょう。

1 日のアクティブ視聴者1 人あたり視聴時間平均配信ビットレート月間配信量
1,00020 分1.5 Mbps約 6.75 TB
10,00020 分1.5 Mbps約 67.5 TB
50,000(ショート動画)30 分1.2 Mbps約 405 TB
100,00020 分1.5 Mbps約 675 TB
  • 計算式:月間 TB = 視聴者数 × 分 × 60 × Mbps ÷ 8 ÷ 1,000,000 × 30。
  • HLS バケットの前に IMIDC CDN を置けば、キャッシュヒット率が高いほどストレージサーバーはキャッシュミスだけを処理すれば済みます。
  • セグメントと VOD プレイリストは公開後に変わらないため長い Cache-Control を設定し、パージではなくパスのバージョン管理で更新します。
  • 署名付き URL やトークンで直リンクを防ぎましょう。放置すると帯域が知らないうちに消費されます。

リージョン選び:香港か、東京・シンガポール・ロサンゼルスか

オリジンは視聴者がいて、そこへの経路が最も強い場所に置きます。

ロケーション主な視聴者経路・IP の特徴
香港中国本土、香港、中国語ユーザー中国電信 CN2 GIA(AS4809)、ホスティングに ICP 届出不要
日本・東京日本、韓国日本のネイティブ IP。VPS では中国向け CN2 最適化ルートを選択可能
シンガポール東南アジア、インド、オセアニア営業経由で個別に構成
米国・ロサンゼルス米州、プレミアム回線経由の中国ユーザー聯通 9929/4837 と CN2 ルート
台北 / バンコク / クアラルンプール単一市場向けプラットフォームローカルのネイティブ IP

多くのプラットフォームは CDN の背後に主オリジン(香港か東京が多い)を 1 つ置き、遠方地域からのキャッシュミスが遅くなってから 2 つ目のオリジンを追加しています。

著作権とコンテンツのコンプライアンス

動画プラットフォームはユーザーの投稿内容への対応責任を負うため、初日からパイプラインにコンプライアンスを組み込みます。

  • 自社が権利を持つか配信許諾を得たコンテンツだけを扱い、投稿者にも同様の規約に同意してもらいます。
  • 著作権の連絡窓口と通知・削除の手続き(DMCA 型の通知など)を公開し、有効な通知には速やかに対応し、繰り返し侵害者への方針を定めます。
  • 各ファイルの投稿アカウント、IP、日時を記録し、コンテンツのハッシュを保存して削除済み動画の再投稿を防ぎます。
  • ホスティング事業者は著作権の苦情を顧客に転送します。サービスを止めないためにも迅速に対応してください。
  • 中国本土の視聴者向けでは内容が合法である必要があり、本土でのオンライン視聴サービスには別途ライセンスが必要な場合があります。一般的な情報であり、法的助言ではありません。

最適な IMIDC 構成の選び方

まずはオリジン 1 台と CDN で始め、ライブラリの成長に合わせてトランスコードとストレージを分離します。

  • MVP や講座動画ライブラリ:香港専用サーバーまたは日本専用サーバー 1 台で API・MinIO・ffmpeg を動かし、IMIDC CDN を追加。
  • 成長中のショート動画アプリ:独立したトランスコードワーカー、ストレージ用専用サーバー上の MinIO クラスター、CDN。
  • 米州と中国の視聴者:CN2 と 9929 ルートを持つロサンゼルス専用サーバーを追加。
  • 自社ストレージ筐体:リモートハンド付きの 1U〜フルラックのコロケーション。
  • 大容量ディスク、多コア、シンガポール、その他カスタム構成:IMIDC 営業にご相談ください。

よくある質問

アジア向けに TikTok のようなショート動画プラットフォームを作るには、どんなサーバーが必要?

最低限、API サーバー、ffmpeg を動かすトランスコードワーカー、ストレージ用専用サーバー上の MinIO などの S3 互換ストレージ、そして CDN が必要です。IMIDC は香港、東京、ロサンゼルスなどの専用サーバーと IMIDC CDN でこの構成を支えます。

動画プラットフォームは香港とシンガポールのどちらに置くべき?

中国本土の視聴者が多いなら香港です。IMIDC の香港サーバーは中国電信 CN2 GIA を使い、ホスティングに ICP 届出も不要です。東南アジア向けはシンガポール、日韓向けは東京が適しており、IMIDC のシンガポールサーバーは営業経由で構成します。

VOD プラットフォームはどれくらい帯域を使いますか?

視聴者数 × 視聴分数 × 平均ビットレートで見積もれます。1 日 1 万人が 1.5 Mbps で 20 分視聴すると、月に約 67.5 TB です。その大半は CDN が配信し、ストレージのオリジンはキャッシュミスだけを処理するのが理想です。

動画の保存に MinIO は向いていますか?

MinIO は広く使われている S3 互換ストレージで、専用サーバー上で HLS セグメントや元動画を保存するのに適しています。まず現行のライセンスとエディションを確認し、代替として SeaweedFS、Garage、Ceph RGW も検討してください。

トランスコードに GPU は必要ですか?

必須ではありません。多コア専用サーバーで ffmpeg の CPU エンコードを行うのが、ビットあたりの画質が最も良くスケールも簡単です。アップロード量が多い場合は GPU で高速化できるので、GPU や多コア構成について IMIDC 営業にお問い合わせください。

自社の動画プラットフォームを構築しませんか?香港専用サーバーと IMIDC CDN をご覧いただくか、チケットを送信して、ストレージ・トランスコード・配信の設計を IMIDC のエンジニアにご相談ください。

この回答はお役に立ちましたか?

関連チュートリアル