日本一テレビ、番組連動インタラクティブシステム

株式会社フォアキャスト・コミュニケーションズ
日本一テレビ、番組連動インタラクティブシステム
# 生放送視聴者参加型のインタラクティブシステム
フォアキャスト・コミュニケーションズはクラスメソッドとともに、2013 年に放送された日本
一テレビ内番組の全国歌唱王選手権「歌唱王」と U-20 お笑い日本一決定戦「ワラチャン」に
て、生放送の視聴者参加型の大規模投票にあわせた、リアルタイムな投票進行のシステムを
AWS を利用し開発しました。「歌唱王」
「ワラチャン」は、生放送番組でネットユーザーからの
投票を基に、出場者の中から日本一を決定するという企画でした。そのため、番組の進行に合
わせて各出場者ごとにリアルタイムで投票を切り替える必要がありました。
## システムの要件
簡単にまとめると以下の 3 つを実現する必要がありました。
1. 同時 66 万人に対して生放送に合わせたリアルタイムな投票遷移
2. エンターテイメント性を落とさない
3. 高い可用性
## リアルタイムな画面遷移を WebSocket で
生放送という時間的に不確定な番組進行に合わせて投票先や画面を切り替えるために、管理画
面からエンドユーザーに WebSocket でメッセージを送って画面遷移させる手法を採りました。
WebSocket は Node.js+Socket.IO で実装しました。
## WebSocket のスケールのために Redis の Pub/Sub を使う
WebSocket アプリケーションにスケーラビリティをもたせるために Redis で Pub/Sub 構成を
採りました。
## Pub/Sub の可用性担保のために Redis を冗長化
Pub/Sub は SPOF になりやすいポイントですが、Redis を多重化して管理画面から複数の
Redis にメッセージを送る仕組みにしました。
## WebSocket 接続の分離
サービスの高可用性のために ELB による負荷分散は必要でしたが、WebSocket 接続を ELB 経
由にすることは障害点を増やすことになってしまうので、直接 EC2 と接続するようにしました。
## SPOF の排除
ELB のヘルスチェックを Node.js アプリケーションまでにしておいては、Redis が止まった際
の Pub/Sub が維持できず、番組進行に支障をきたします。そのため ELB からのヘルスチェッ
ク用に Redis の死活まで確認出来るディープヘルスチェック用のコードを用意しました。また、
本システムは Multi-Region/Multi-AZ 構成を基本とし、各 Region、AZ、ELB、EC2、アプリケ
ーションのどのレイヤーで障害が発生しても、該当箇所が自律的にシステムから切り離される
ようにしました。
## システムのドミノ倒しを防ぐための DNS ラウンドロビン
66 万人に同時メッセージを送るためには多くの EC2 が必要でしたが、分散粒度が低いと、
Multi-Region/Multi-AZ でサービスの可用性を担保しても、大規模障害時には一時的な負荷の不
均等が発生し、システムがドミノ倒しになる可能性があります。そのためキャパシティには十
分な余裕を持たせつつ、分散の粒度を細かくすることで、より安定的なシステムとしました。
Region 障害時には DNS から該当 Region を指し示す ELB の CNAME レコードを切り離すこと
で、システムを継続させる仕組みとしました。
## 管理画面の冗長化
これだけサービスサイドの可用性を高めても番組進行管理画面がダウンしてしまっては意味が
ありません。そのため管理画面アプリケーションも Multi-Region に用意し、Redis は複数の管
理画面用 EC2 から接続されても正常に動作するようにしました。
## エンターテイメント性を落とさない
エンターテイメント性を担保するために、視聴ユーザからリクエストには迅速に応答する必要
がありました。そのため、コンテンツの軽量化、リクエスト数の最小化にも取り組んでいます。
WebSocket サーバの負荷を減らすために、コンテンツ配信は別環境から行いました。CDN は
ピーク性の高いトラフィックに対してプロビジョニングが難しいため、ELB+EC2(+nginx)のコ
ンテンツ配信環境を構築しました。
## システムを一括管理するスクリプトによるデプロイ管理
システムの構成や設定を変更する場合、多くの EC2 に都度変更をデプロイする必要がありまし
たので、CloudFormation と Capistrano を利用し、コードベースで管理しました。
## 大切な負荷試験
システムが要求処理性能を満たしていることを確認するために負荷試験を行いますが、66 万人
の WebSocket を同時に処理するシステムの負荷試験はログのデータも膨大で、バッチ処理で
はトライ・アンド・エラーのサイクルに間に合いません。負荷試験のフィードバックを迅速に
得るため、ログ収集・集計・分析には Fluentd と TreasureData を利用しました。膨大な負荷試
験のログをわずかな時間で分析し、システム性能が目標値に達成していることが確認出来まし
た。
## まとめ
テレビ連動などの大規模トラフィックにお悩みのお客様、またこういった大規模トラフィック
のシステム構築にご興味をお持ちの方はこちらまでご連絡下さい。
お問い合わせ：[email protected]

Download Report