朝日放送が『M-1グランプリ』敗者復活投票システムをAWSで構築、システム停止は許されない（1/2 ページ）

人気番組『M-1グランプリ』の敗者復活制度は、視聴者による投票で成り立っている。システム停止は番組進行に影響を及ぼすため許されない。毎秒数万件のアクセスにも耐え得る仕組みを朝日放送はAWSで構築した。

公開 2017年07月26日 09時01分

更新 2017年07月26日 14時34分

著者

重森大

[著]

印刷する Googleで優先するソースとして追加

　テレビ番組でよく見掛けるリモコンのデータ放送ボタン「dボタン」からの投票。大阪の放送局である朝日放送（以下、ABC）は、そのシステムをクラウドサービス群「Amazon Web Services（AWS）」を使って構築。2017年6月開催のAWS関連イベント「AWS Summit Tokyo 2017」で発表した。ABCは全国ネットの番組も数多く制作している。漫才コンテスト番組の『M-1グランプリ』もその1つで、高い視聴率を誇る。番組では予選落ちした芸人の中から視聴者が選んだ1組を決勝戦に出場させる敗者復活制度を採用する。視聴者からの投票を集計するシステムは、AWSを使って構築したという。

併せて読みたいお薦めの記事

AWS Summit Tokyo 2017レポート

サーバレスのメリット

大規模環境のクラウド利用

既存システムとは別にM-1グランプリ用に新規開発された投票システム

　ABCは社内に技術局開発部という部門を持ち、多くのシステムを内製している。そのほとんどをオンプレミスで構築しており、クラウドの活用が早かったわけではない。ABCで技術局開発部に勤める小南英司氏は「視聴者がアニメを見ながら一緒に楽しめるアプリをリリースしたり、野球速報やライブ動画配信にも携わってきたりしました」と語る。これらのシステムを含め、2015年にM-1グランプリの投票システムを構築するまでは、全てのシステムをオンプレミスで構築してきたという。

朝日放送小南英司氏

　実は過去に構築したシステムの中には、番組と連動する投票システムもあり、2012年から稼働実績を積み上げてきた。社内では「ABC放送通信連携システム」と呼ばれ、データ放送コンテンツの制御やSNS（ソーシャルネットワーキングサービス）との連携機能、視聴者投票集計機能を備える。機能不足もなく、今でも多くの番組で使われているという。ではなぜABCはM-1グランプリ用の投票システムを改めて、しかもクラウドを使って構築し直したのか。

　クラウドを、中でもAWSを採用した理由は大きく2つある。「1つは視聴率の高い看板番組であり、高速な処理と1秒たりとも止まらない可用性を両立するため。もう1つは短期間で開発するためです」（小南氏）

　2008年の決勝戦放送時には関西で35％の視聴率をたたき出したこともある人気番組だけに、かなり多くの視聴者が投票に参加する可能性がある。しかも番組連動企画では、テレビを通じて投票を呼び掛けた直後に爆発的にアクセスが集中する。広告などでスパイクアクセスと呼ばれるこの現象は、サーバに非常に高い負荷を掛けることになる。それに耐えられるだけのサーバリソースを社内で用意するのは難しいと、ABCは考えた。

　「この敗者復活戦は番組構成上、重要な要素です。もしシステムが負荷に耐えきれなかった場合、番組構成にも影響を与える恐れがあります」（小南氏）。そこで注目したのがAWSだった。マネージドサービスなので「サーバの増設や設定値のチューニングをオンプレミスに比べて格段に省力化できます」（同氏）。

図1　AWSの採用により長短期間での開発を可能に

　もう1つの理由である短期間での開発だが、なんと要件をまとめて仕様を決定したのは放送の約1カ月半前。43日間で開発を終え、9日間の検証期間を経て2015年12月6日の放送を迎えた。開発に携わったのは、社内のエンジニア2人のみ。豊富に公開されているドキュメントやSDK（ソフトウェア開発キット）を活用することで、学習コストも開発コストも抑えることができたのだという。

Webサイトからの投票に始まり、翌年にはdボタンにも対応

　2015年の構築当初、M-1グランプリ敗者復活戦投票システムは大きく3つの機能で成り立っていた。視聴者向けのフロントエンドとなるWebコンテンツの配信機能、投票データの集計処理機能、システムの管理機能の3つだ。

図2　M-1敗者復活戦投票システムの概要

　Webコンテンツ配信には、仮想サーバ構築の「Amazon EC2（Elastic Compute Cloud）」、ロードバランサーの「Amazon ELB（Elastic Load Balancing ）」、コンテンツ配信ネットワーク（CDN）の「Amazon CloudFront」を使用している。基本的には静的なコンテンツが多いため、CloudFrontのキャッシュを最大限活用し、EC2で稼働させる仮想サーバの台数を抑えている。投票データの集計処理は、リアルタイムデータ処理の「Amazon Kinesis」とEC2、 NoSQLデータベースの「Amazon DynamoDB」を使って構築した。Kinesisを介することで、一気に大量の投票データが寄せられてもバックエンドが過負荷にならないようにした点がポイントだ。

　小南氏によれば、番組連動型の投票では、告知後の1分間に全投票の2割から6割が集中し、「Kinesisがこれを受け止めて、集計処理機能に流すデータ流量を調整するダムの役割を果たしてくれる」という。

　毎秒数万件の投票がなされたとしても、それをKinesisが一度受け止めてくれるので、Kinesis活用アプリケーションを走らせているバックエンドのEC2は、自分の処理能力に合わせてデータを集計処理できる。テレビ番組連動システムのように「バーストトラフィック（一時的な大量トラフィック）が発生することが分かっているシステムでは非常に有益なサービス」だと、小南氏は語る（図3）。

図3　告知直後のバーストトラフィックもKinesisが受け止めてくれるのでバックエンドの設計が楽に

　DynamoDBも「使いやすくて助かりました」と小南氏は評価する。「扱うデータがシンプルだったこともありますが、DynamoDBの投票数テーブルを番組制作サイドがリアルタイムに確認できるようにしておくことで、番組をスムーズに進行できました」（同氏）

　2015年の構築当初はWebサイトからのみ投票を受け付けていた同システムは、2016年にテレビリモコンのdボタンからでも投票ができるようにした。データ放送はBMLという独特なマークアップ言語を使っている。そのためCloudFrontでデータを受け取った上で、API（アプリケーションプログラミングインタフェース）作成・管理の「Amazon API Gateway」を介してKinesisにデータを投入する手法を取った。API Gatewayを使うことで、2015年に構築したシステムを活用し、最小限のシステム追加でデータ放送に対応できた。

次ページへ絶対に落とさないために工夫していること

印刷する

この記事の著者

重森大

朝日放送が『M-1グランプリ』敗者復活投票システムをAWSで構築、システム停止は許されない（1/2 ページ）