「M-1グランプリ」敗者復活戦投票システムの概要
視聴者投票の実施と集計
- AWSのサーバレスアーキテクチャの作成
- 自社社員2名だけでシステム構築から運用まで対応
- 生放送や番組連動でも確実に運用できる高可用性
Webページから投票 -> 集計処理 -> 結果表示
Webコンテンツの提供
- Cloud front
- ELB
- EC2
投票データの処理
ここがサーバレス
- Kinesis
- Kinesis App
- DynamoDB
集計結果の表示とエクスポート
投票データはリアルタイムで集計
* 番組関係者は専用webページから閲覧
* JSON形式でエクスポート(DynamoDBのスキャン)
AWS/サーバレスを選択した理由
ABC放送通信連携システム(2012年〜)が構築済みだけど
- アクセスを捌き切れるか不安
- 5年ぶりのM-1ということで注目度高
- 敗者復活戦は重要イベント
- スケジュール的問題
- 専用の作り込みが必要なのに放送開始1ヶ月ほど前に使用決定・開発開始
なぜAWSのサーバレスか?
- マネージドなのでアクセス集中を捌きやすい
- ドキュメントやツールが豊富
->短期間で高信頼性のシステム構築が可能
サーバレスアーキテクチャの採用
負荷対策やバックアップをサービスに任せることで、プログラムの開発にリソースを集中できる。
Kinesisはバースト対策に良い
- 番組連動: バーストトラフィックの発生
- 告知によって莫大なトラフィックが発生
- 全投票数のうち2~6割が告知後一分間
- 指定したシャード数のトラフィックはちゃんと受けてくれる
- Kinesis Enable Appで処理するトラフィックをコントロールできる
DynamoDBで簡単集計
Atomic Counterで得票数を更新
番組との連動に耐えうるシステムの設計
安定した集計処理
Apache JMeterを使った負荷試験
-> 負荷試験に基づいてシステム構成や設定値を決定
集計処理プログラム
- 並列処理、パラメータチューニング
- 不正データ排除
- 強力なエラーハンドリング
- 高い汎用性
システムの多重化
1秒たりとも止められない!
北バージニアリージョンにバックアップ
東京で何かあっても北バージニアで処理続行
バージニアはAWS創業の地なのでリソースが豊富
| 通常時 | 障害発生時 |
|---|---|
| 投票データを共有し、並行して処理を行う | バックアップシステムで処理を行う |
設定などは共通化(同一のAMIから作成)
データストレージへのバックアップ
投票データ、DynamoDB、結果データをS3に保存
-> 事後の検証・分析にも活用可能
運用負荷低減の試み
システム設定用のスクリプト作成
システム初期化・設定を行う対話式スクリプトを独自開発
個人的所感
実は一番楽しみにしてたセッション。Webコンテンツ配信で普通にEC2が出てきてビビったけど
Kinesis からLambda、DynamoDBの連携はよくやっているが、Kinesis Appは名前ぐらいしか知らないので、一度使ってみるべきだろうか。
開発に集中できるというのはサーバレスアーキテクチャの素晴らしいところ。「サーバレスアーキテクチャを採用した開発」そのものの学習コストはあるだろうし、それを面倒臭がって「EC2立てればええやん」という人もまだまだいるだろうけど、長期的な幸せを考えたら運用とかのことを考えなくて済むサーバレスはやっぱり素晴らしいと思う。