以下のインフラ構成を考える
- サービス内容：動画配信サービス
- パブリッククラウド上に構築する
- 同時視聴ユーザー数は最大1万人を想定
- サービスは24時間365日とめたくない
- 動画データは数TBに成長する見込み
- スタートアップなのコストは最小限に抑えたい
要件整理
| 項目 | 内容 |
|---|---|
| サービス種別 | 動画配信 |
| 同時視聴ユーザー数 | 最大1万人 |
| 可用性 | 24時間365日 |
| データ規模 | 数TB（成長見込みあり） |
| コスト方針 | 最小限に抑える |
構成要素と意思決定
配信レイヤー
同時視聴1万人かつ容量の大きい動画であるため、CDNが必要。キャッシュによりオリジンサーバーへのトラフィックを削減できる。CDNで配信地域の距離による遅延を解消し、オリジンサーバーの負荷を分散する。CDNは動画ファイルとAPIリクエストで配信先を分岐させる。
アプリケーションレイヤー
24時間365日稼働の要件を満たすため、冗長化が必要。ロードバランサーで複数台に振り分けることで、負荷分散と冗長化を実現する。
オートスケール
スタートアップとしてコストを最小限に抑えるために、モニタリングのメトリクス（CPU使用率やリクエスト数）を元にアプリケーションサーバを自動スケールさせる。
キャッシュサーバー
頻繁に参照されるデータをメモリ上に保持することで、DBへのアクセス回数を減らす。
データベース
24時間365日稼働の要件を満たすため、冗長化が必要。PrimaryとReplicaの構成にすることで、負荷分散と冗長化を実現する。
動画ストレージ
DBよりも安価なオブジェクトストレージを利用する。容量も無制限に近く、スケーラブルとなる。
動画処理パイプライン
アップロードされた動画をそのまま配信するのではなく、トランスコード処理でHLS形式に変換してからオブジェクトストレージに置く。デバイスや帯域に適応したストリーミングが可能となる。
監視
24時間365日稼働の要件を満たすため、モニタリングを用意する。メトリクスにアラート通知を設定して早期検知が可能となる。
インフラ構成図
graph TD
Player[プレイヤー] -->|動画リクエスト| CDN[CDN]
CDN -->|動画配信| Storage[(オブジェクトストレージ)]
CDN -->|APIリクエスト| LB[ロードバランサー]
subgraph PublicCloud["パブリッククラウド"]
subgraph AppLayer["アプリケーション層 オートスケール"]
LB --> App1[アプリサーバー 1]
LB --> App2[アプリサーバー 2]
end
App1 & App2 --> Cache[キャッシュサーバー]
App1 & App2 --> DBPrimary[(DB Primary)]
DBPrimary --> DBReplica[(DB Replica)]
subgraph MediaPipeline["動画処理パイプライン"]
Upload[動画アップロード] --> Transcode[トランスコード処理]
Transcode -->|HLS形式| Storage
end
subgraph Monitoring["監視・運用"]
Monitor[モニタリング] --> AutoScale[オートスケール制御]
AutoScale --> App1
AutoScale --> App2
end
end