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

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

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

著者

重森大

[著]

印刷する

絶対に落とさないために冗長化と事前負荷テストを徹底

　M-1グランプリは生放送である上に、敗者復活戦投票システムが番組進行に大きな影響を与えるため、番組中にシステムが停止することは許されない。そこでABCは同システムの完全な複製をAWSの日本リージョンとバージニアリージョンに構築した（図4）。双方共にアクティブで稼働させ、全ての投票データを両方のシステムで集計する。両リージョンの集計結果に違いが生じれば、システム障害の兆候に気付くことができる。

図4　日本リージョンとバージニアリージョンに同一システムを構築、平行稼働させた

　Kinesisで受け取ったデータはEC2で稼働するKinesisアプリケーションで集計した結果、DynamoDBに格納したデータと共に、クラウドストレージ「Amazon S3（Simple Storage Service）」にバックアップデータとして保存している。「万一障害が発生した場合には、バックアップデータからリストアして処理を継続できますし、障害が発生しなければ、事後検証や分析に使える有益なデータとなります」（小南氏）

　冗長化、バックアップに加えて、運用時の人的ミスをなくすための工夫も凝らしている。例えば日本リージョンで使っているEC2とバージニアリージョンで使っているEC2の仮想サーバを同じOSイメージ（AMI： Amazonマシンイメージ）から起動する。起動時に、どのリージョンで起動したのかを自動判別し、リージョンに依存する設定を自動的に施す仕組みだ。また各システム設定用の対話式スクリプトも作成。システムに欠かせない設定の抜け漏れを防いでいる。

　バーストトラフィックを想定した負荷テストは「事前に何度もしました」と小南氏は振り返る。EC2で多数の仮想サーバを動かし、テスト負荷測定ツール「Apache JMeter」を使ってシステムに負荷を掛け、設定値の調整を繰り返した。20万人が参加し、ピーク時のアクセスは1万以上を想定して、その数倍まで耐えられる構成にした。20万人という想定参加者数はこれまでの経験から導いたもので、結果的にほぼ想定通りの投票数が得られた。

　2016年にはdボタンから投票に参加できるようになりハードルが低くなったことから、さらなる高負荷を想定して負荷テストを実施。そうした前準備があり、100万票を超える投票データを問題なく処理することができた。

　「今後はオンプレミスで稼働する既存システムとの連携など、活用範囲を広げていきたいと思っています。M-1グランプリでの実績を背景に、社内でAWSの活用が広がりつつあるので、今後もクラウドのもたらす効果を最大限に生かしていきたいと考えています」（小南氏）