「AWSのコスト管理は大変」――視聴率を調査するビデオリサーチのクラウド活用裏話：安心安全が第一でもクラウドネイティブを目指す理由

テレビ番組の視聴度合いの指標となる「視聴率」を算出するシステムにクラウドを活用するビデオリサーチは現在、クラウドネイティブに向けた取り組みを進めているという。2021年5月11〜12日に開催された「AWS Summit Online 2021」でシニアフェローの豊島潤一氏が紹介した。

[高橋睦美，＠IT]

　「ビデオリサーチの調べによると、番組の視聴率は○％でした」――そんな一文で知られる通り、テレビの視聴率測定、広告、調査分野で事業を展開するビデオリサーチ。同社は2020年4月から調査対象世帯（パネル）を大幅に増やした「新しい視聴率」の測定を開始した。

　同社では、長年オンプレミス環境の独自システムに頼ってきた視聴率算出の仕組みを、Amazon Web Services（AWS）上に移行して運用しているという。どのような方針で構築しているのか。2021年5月11〜12日に開催された「AWS Summit Online 2021」でビデオリサーチのシニアフェロー、豊島潤一氏が紹介した。

コストより安心安全を重視　「力」でねじ伏せる方針のシステム構築

　ビデオリサーチではパネル世帯に設置したセンサーから届くデータを基に、放送中の視聴率である「リアルタイム視聴率」と、放送後7日間の視聴率である「タイムシフト視聴率」の2つを算出している。パネルは全国32地区（47都道府県）にまたがり、2万台以上のテレビを常時測定している。

　「2020年4月から開始した新しい視聴率の測定は、パネルが大幅に増えただけでなく調査内容の増加により、データと処理量が増加しました。特に、タイムシフト視聴による処理量の増加は劇的でした」（豊島氏）

　さて、視聴率の算出手法といえば「アンケート」などを考える人も多いだろうが、現在は次のような流れで算出している。

　まず、テレビに接続されたセンサーが、音声から特徴を抽出した「フィンガープリント」を作成する。そのデータをインターネット経由でAWSに収集し、全国各地の放送波から作成したマスターのフィンガープリントと照合し、視聴判定処理をする。こうして「何時何分何秒に、どのチャンネルが見られていたのか」を集計し、メインフレームを用いて視聴率の形に加工しているというわけだ。

視聴判定の仕組み

　ビデオリサーチから提供される視聴率は、民放各社における重要な取引指標となっている。それ故に、他の調査や数字にはないさまざまな要件がある。

ビデオリサーチ シニアフェロー 豊島潤一氏

　1つは、視聴率に正解がないことだ。「個人の行動はさまざまで、突然テレビを見たり、ゲームをしたり、タイムシフトを見たりとさまざまな行動があり得ます。そのため、個人の行動を推定してデータを補完できません。従って、集める、測定する、計算する、いずれのプロセスでも問題を発生させてはいけません」（豊島氏）

　そしてもう1つは、番組の放送が不確実なものであることだ。番組は常に番組表通りに放送されるとは限らない。ニュース速報や特別番組が組まれたり、スポーツ番組が延長されたりすることもあり、それに伴って視聴行動が大きく変わる可能性がある。その上、テレビは今や、タイムシフト視聴はもちろん、Blu-rayを見たりゲームをしたりと、リアルタイムにテレビ放送を見るだけのデバイスではない。なお「テレビ視聴ではないデータの判定処理は、システムにとっては最も高負荷なものとなる」（豊島氏）そうだ。

　他にもデータの欠損が絶対に許されないこと、一日の区切りが朝の4時59分と5時の間にあり、5時までのデータを含む前日の視聴率を4時間後の9時に提供しなければいけないことといった細かい要件もある。もし、処理の遅延や障害が発生すれば致命的な事態となる。

　こうしたシビアな要件が求められる視聴率を算出するシステムには「コストよりも安心、安全を最重視することが求められた」と豊島氏は説明した。

　また視聴率システムの根幹部分はプロプライエタリなものが多いという。移行に当たって過去のシステムとの差異を発生させないよう、長期の検証、並行期間が必要となる。そのため、クラウド活用に当たっては既存システムをそのままクラウドに移行（リフト）することを重視し、改修や運用効率化（シフト）は移行完了後に実施するという方針で改修に臨んだ。「あくまでシステムを安全に移行させることを最重視して、このようなアプローチとなりました」（豊島氏）

　そして、高性能かつ高コストのインスタンスを多数稼働させてでも「パワーでねじ伏せる（処理を終わらせる）」というアプローチで正面から向かったという。

十分な助走期間を確保し、膨大な負荷に適応可能なシステムを実現

　ビデオリサーチでは、負荷のピークに合わせてリソースを用意し、ロードバランサーやマルチAZ（Availability Zone）、ホットスタンバイといった「よくある組み合わせ」でシステムを構築した。

　まず、パネルの自宅でテレビが視聴されると、「視聴フィンガープリント」がロードバランサー経由でデータ収集処理サーバに送信され「Amazon Aurora」に格納される。視聴判定処理をするサーバはAmazon Auroraからフィンガープリントを取り出して視聴判定を行い、その結果を「AWS Lambda」経由で「Amazon S3」に保存する。最後にメインフレームがAmazon S3からデータを取得し、視聴率を作成するという流れだ。

　処理フローはシンプルかもしれないが、処理すべきデータは膨大だ。2万台のセンサーから24時間365日届き続けるフィンガープリントのデータを、200チャンネル以上の放送と比較し、類似度を判定し続けなければいけないためだ。

　タイムシフト視聴の判定では負荷がさらに高まる。リアルタイム視聴では3秒の視聴と前後6秒を加えた15秒との比較になるが、タイムシフト視聴では過去8日間、69万1200秒ものデータと比較しなければならない。ましてや、テレビ以外の視聴、ゲームやネット動画を判定するには、どれだけ比較をしてもどの放送か分からないため、非常に重い処理になるという。

　これらのデータを、パネルの自宅に設置するローカル側の機器で保存し、マッチさせる方式は困難だったという。「過去69万1200秒分のデータを宅内の何かにためることは難しかったため、センターで全て集約するセンターマッチ方式に移行しました」（豊島氏）

　このやり方では宅内に設置する機器はシンプルになる代わりに、当然ながらサーバの負荷は高まり、コストは大きくなる。だが「安心、安定のためならばコスト増はやむを得ない」という大方針の下、「Savings Plans」や「Reserved Instance」を活用してコストを削減しつつ「Migration Acceleration Program」の適用でクレジットの付与を受けることで、コストの抑制に努めた。「迷ってオンデマンドで課金されるくらいなら買う、というのが弊社の方針になっています」（豊島氏）

　豊島氏はさらに「例えば『Amazon EBS（Amazon Elastic Block Store ）』のボリュームタイプを『gp2』から同性能の『gp3』にするだけでもコストが削減できます。このようにコスト効率を求めるために新サービスのキャッチアップも非常に重要です」とした。

　こうして既存のシステムをAWSでクラウド化した結果、さまざまなメリットが得られたという。

　「まず、クラウドのスケーラビリティを生かして、新旧システムの併走期間、助走期間を十分に確保できました。結果として、クラウド特有のリスクのあぶり出しや、サーバ構成を決定するための十分な性能検証も行えました」（豊島氏）。日々変わる視聴量やパネルの増減に、サーバ構成を柔軟に変動させることで対応できているという。

　またクラウド契約を一本化したことで、視聴率システム側で浮いた分のリソースを、他の部署で活用できるようになった。本番同等の環境を容易に構築できるようになったことで、ビデオリサーチ内部で、運用ツールの内製化や人材育成が容易になったという。

　他には、AWSのIAM（Identity and Access Management）ポリシーやセキュリティグループの設定を変更することで、緊急事態宣言後のテレワーク対応もスピーディーに行えたという。加えて、視聴率システムの一部にサーバレスアーキテクチャを採用することで、開発範囲や運用保守の肥大化防止も図った。

　「パワーで乗り切った視聴率システムですが、リソースの変更が柔軟にでき、Reserved InstanceやSavings Plansを全社でシェアできるクラウドだからこそできた判断だと考えています」（豊島氏）

課金の偏りや人員不足といった課題には正攻法で対応

　一方で、クラウド移行後は課題も見えてきた。

　全社で一本化した契約だが、その請求アカウントには80以上のAWSアカウントがひも付いており、Savings PlansやReserved Instanceはその全アカウントで共有していた。そのため、アカウントごとの正確なコスト算出が困難になってしまったという。

　「本来アカウントAのために購入したReserved InstanceとSavings Plansの余剰分が他のアカウントに適用されてしまい、意図した形で利用できていない状況が発生していました」（豊島氏）

　そこでビデオリサーチでは、「Amazon Athena」を利用して割引前のAWS利用料をアカウントごとに算出した。InstanceとSavings Plansの割引額を独自に計算して引いていくという力業的な方法で実コストを算出したという。ただ「料金テーブルがAPIで取得でき、かつ構造化されているため非常に容易でした」と同氏はいう。

Reserved InstanceやSaving Plansが適切なアカウントに適用されていなかった問題を解決

　ただ、「パワーでねじ伏せる」という考えで最初から最上位スペックのリソースを使っていたため、高負荷になってもそれ以上スペックを上げる先がないという事態も発生した。

　「『Performance Insights』や『Slow Query』などで非効率な実行計画や重いクエリがないか、フェイルオーバーで異なるAZ間の通信が起きていないかなど、基本的なことを再確認しました」（豊島氏）

　また技術以外の側面でもさまざまな課題が生じた。大きな課題は人員不足で、中途採用はもちろんのこと「AWSのプログラムや研修を活用して、特に内部のスキルアップを実施しています。環境をフレキシブルに構築できるため、内製やハンズオンといったところもバシバシ進めるといいと思います」とした。すでに成果は出始めており、「AWS Solution Architect Professional」を2人、「AWS Solution Architect Associate」を5人が取得済みという。

　AWSにかかるコストは、「クラウドに移行する際、オンプレミスの考え方を引きずっていたところがありました。やはりそれでシステム設計、運用するとコストは高くなります。常にクラウドを意識した設計、運用でコスト管理をすべきでしょう」という。コストに関しては、テクニカルアカウントマネジャー（TAM）のサポートや「AWS Cost Anomaly Detection」の活用も有効だという。

　そして「見切りで始めてしまったことが原因ですが、運用開始後は利用ガイドラインの整備不足も課題になりました。社内のどこかに必ずガイドラインのベースとなるものが残っているはずなので、今後はそれをベースにCCoE（Cloud Center of Excellence）を立ち上げていきたい」と述べた。

データを生かすため、将来的にはクラウドネイティブを志向

　豊島氏はクラウド移行の経験も含め、「システムの規模が大きくなると、起きる可能性のあること、時に起きてほしくないことはたいてい起こると感じています」と述べた。その上で今後もさまざまな施策を進めていく予定だ。

　まず、メインフレームの機能を「Amazon EMR（Elastic MapReduce）」で代替すべく、検証を進めている。視聴率判定処理にARMアーキテクチャを活用することで、コスト削減や性能向上につなげる方針だ。「検証段階ですが、c6g系のインスタンスでコストを4割程度削減できる可能性を確認しています」という。

　さらに、運用やテストなどさまざまな側面での自動化、リージョン障害の影響を受けないようにするための大阪リージョンの活用など検討中の事柄は多々ある。「AWS Fargate」を活用したコンテナ化と視聴量予測を組み合わせ、柔軟かつ効率的な視聴判定サーバのスケーリングも実現していきたいという。

　すでにビデオリサーチ社内では、放送の一時間後に視聴率を速報表示する「PMビューン」のように、サーバレスで構築したシステムも稼働している。

　大量のセンサーから届く膨大なデータに基づいた視聴率の算出というクリティカルなデータの作成を、これまでのオンプレミスのシステムから、クラウドを組み合わせた構成へ移行させたビデオリサーチだが、「将来的にはやはりクラウドネイティブに向かおうと考えています」と豊島氏は述べた。

　「なぜなら、データはもはや電気のようにあって当たり前、使えて当たり前の存在になっているためです。ビデオリサーチが保有する多種多様なデータを活用するために、今後は機械学習やAI（人工知能）との付き合いが本格化していきます。機械学習やAIのクラウドが最も近道であり、最も適していると考えています」（同氏）。クラウドを生かして、社内に蓄積されたデータをより役立たせる「提言」の形にしていきたいと述べ、講演を締めくくった。