ディスカッションの目的
2026年WBC決勝戦。大谷翔平選手の打席を、アメリカから日本の10万人が同時に、
遅延なく4K画質で視聴するシステムをAWSでいかに構築するかをディスカッションします。
通常月間100万アクセスのサービスが、一瞬で300万アクセスに跳ね上がり、
同時視聴者数は10万人、必要な通信量は2Tbps（テラビット毎秒）という膨大な規模になります。
でも、ここで多くの人がこう思います。
「そんな大規模配信、AWSで実現できるの？どんな技術構成が必要なの？」
そこで今日のゴール
オンライン雑談会の参加者同士で1つのテーマに向けて考え話し合い発表する。
※補足：AI使用可能（ただし補助で使用する。考えるのはあくまで人）
参加者同士で否定の意見もOK、その場合は代替案を話す。
まず根本的な問題を整理します
距離の問題: アメリカから日本まで、物理的に1万キロ以上離れています。
光の速度でも片道70ミリ秒かかり、これは避けられない物理限界です。
スケールの問題: 10万人が同時視聴すると、単純計算で2Tbpsの通信量が発生します。
これは一般的なWebサイトの数千倍の負荷です。
品質の問題: 4K映像は1秒間に20メガビットのデータが必要です。
これが途切れると、視聴体験が大きく損なわれます。
単一障害点の問題: どこか1箇所でも故障すると、全視聴者が見られなくなってしまいます。
2つの提案された解決アプローチ
雑談会では、これらの課題に対して2つの異なるアプローチが提案されました。
提案1：シンプル・確実型構成
基本的な考え方: 「複雑にしすぎず、確実に動く構成を」
配信の流れ
- Direct Connect（専用回線）: アメリカの会場とAWSを物理的な専用回線で直接接続
- MediaLive（映像伝送サービス）: 高品質な映像データをクラウドに安全に送信
- CloudFront（世界規模の配信網）: 日本を含む世界各地のサーバーから視聴者に配信
この構成の特徴はシンプルさです。経路が明確で、障害時の原因特定が容易になります。
障害に備える多重化の工夫
ネットワークレベルの冗長化:Route 53（DNS管理サービス）とAWS Global Acceleratorが障害を検知すると数秒で代替経路に切り替えます。
認証とセキュリティ：有料配信を支える仕組み
WBC配信は有料サービスのため、正当な視聴者のみがアクセスできる仕組みが必要です。
ユーザー認証の流れ:
- Cognito（認証サービス）: ユーザーのログイン情報を管理し、短時間有効なトークンを発行
- Lambda@Edge（エッジでの処理）: 世界各地のエッジサーバーで、トークンの有効性をリアルタイムチェック
- DynamoDB（高速データベース）: ユーザー情報と権限を高速に照会
この仕組みにより、不正アクセスを遮断しながら、正当な視聴者には遅延なく配信を提供できます。
提案2：多重冗長型構成
基本的な考え方: 「どこが壊れても配信を続ける」
配信の流れ
-
二重化された映像伝送: アメリカから西海岸（us-west-2）と東京（ap-northeast-1）の両方に同時送信
（※まず MediaConnect で米国西海岸に送信し、そこから MediaLive で処理。
MediaPackage v2 が東京リージョン（ap-northeast-1）でも並行稼働） - MediaLive（リアルタイム変換）: 4K映像を複数の解像度に同時変換（スマホ用、PC用など）
- MediaPackage v2（動的パッケージング）: 視聴者の環境に最適な形式で配信準備
- 多層フェイルオーバー: サーバー、リージョン、DNS、全てのレベルで予備系を準備
この構成では障害への備えを最優先にしています。
障害に備える多重化の工夫
リージョンレベルの冗長化:西海岸と東京の両方でシステムを稼働させ、片方に障害が起きても自動的に切り替わります。
認証とセキュリティ：有料配信を支える仕組み
WBC配信は有料サービスのため、正当な視聴者のみがアクセスできる仕組みが必要です。
ユーザー認証の流れ:
- CloudFront Functions（軽量エッジ処理）: 署名Cookie検証や簡易リクエスト制御を高速処理。大量のアクセスを低コストで効率的に捌く
- Lambda@Edge（複雑エッジ処理）: JWT検証（Cognitoが発行したトークンのexpやscopeチェック）を実行し、ユーザーの権限レベルに応じたアクセス制御を行う
- DynamoDB（高速データベース）: ユーザー情報と権限を高速に照会し、Lambda@Edgeと連携して動的な権限チェックを実現
Edge Authの役割: CloudFrontの世界各地のエッジサーバーで「配信の番人」として機能し、不正な視聴者を配信システムに入れる前に遮断します。
これにより、MediaPackageやMediaLiveなどの配信インフラには、認証済みの正当な視聴者のリクエストのみが到達します。
この仕組みにより、不正アクセスを遮断しながら、正当な視聴者には遅延なく配信を提供できます。
映像がアメリカから日本に届くまでの仕組み
ステップ1: 映像の取り込み
アメリカの会場で撮影された4K映像は、まずエンコーダー（映像圧縮装置）で20Mbpsのデータストリームに変換されます。これが配信の起点です。
ステップ2: クラウドへの伝送
Direct ConnectやMediaConnectを使って、映像データをAWSクラウドに送信します。
ここで重要なのは信頼性のあるネットワーク経路の確保です。
ステップ3: 複数形式への変換
MediaLiveが4K映像を受け取り、同時に複数の解像度（4K、2K、1080p、720p）に変換します。
視聴者の回線速度に応じて最適な画質を自動選択できます。
ステップ4: 世界規模での配信準備
MediaPackage v2が変換された映像を、Low Latency HLS（LL-HLS）という低遅延配信形式でパッケージ化します。これにより遅延を最小限に抑えます。
ステップ5: エッジサーバーからの配信
CloudFrontの日本国内のエッジサーバーから、実際に視聴者に映像が配信されます。
視聴者は物理的に近いサーバーから受信するため、遅延が大幅に削減されます。
2つの提案の実践的な比較
コスト面での違い
シンプル構成: 必要最小限のサービス利用で、コストを抑制します。
多重冗長構成: 複数リージョン、複数サービスの並列稼働で、コストはシンプル構成の約2-3倍かかる可能性があります。
運用面での違い
シンプル構成: 障害時の原因特定が容易、但し復旧まで配信停止の可能性があります。
多重冗長構成: 障害の影響を最小化、但し構成の複雑性による運用難易度が向上します。
信頼性の違い
シンプル構成: 単一障害点が存在、障害時は全面停止のリスクがあります。
多重冗長構成: 多重化により99.99%以上の可用性を実現します。
この記事は、実際のオンライン雑談会でのディスカッションをもとに構成しました。
大規模システム設計の考え方や、AWSサービスの実践的な活用方法について理解を深めていただければ幸いです。