“宝の山”を有効活用できるのはオンプレミスだった――広告データ分析基盤をAWSから移行したワケ（1/2 ページ）

ソネット・メディア・ネットワークスは、広告配信の効果測定などを行う分析環境をAWSで構築した後、オンプレミス環境へ置き換えた。同社にとって、ログデータの活用は事業の生命線である。この分析環境移行の狙いとは。

公開 2015年11月19日 08時03分

更新 2015年11月20日 12時45分

著者

岡崎勝己

[著]

印刷する

事業基盤であるシステムの見直しに踏み切った理由とは

　「情報通信技術の進歩を人に優しいかたちにして、愉快なる未来を創る」を経営理念に、デジタルマーケティング関連サービスを提供するソネット・メディア・ネットワークス。その事業基盤と位置付けられるのが、媒体となるWebサイトを多数集め広告を配信する、いわゆる「アドネットワーク」の進化版とも呼べる同社のDSP（Demand Side Platform）、「Logicad」（ロジカド）だ。

　Logicadの1番の特徴は、ソネット・メディア・ネットワークスがソニーグループとして培ってきた人工知能やビッグデータ処理、金融工学の3つの技術を基盤とすることで、配信ログやCookieデータといった大規模データを高速かつ安定的に処理し、独自アルゴリズムでリアルタイム入札を実現していることである。

　近年ではDSP需要の一巡によって、業界の勢いがひと頃よりは失われている。そうした中、大規模データ処理による高度なターゲティングで差別化を図ったLogicadは、今なお多くの広告主に利用され、2014年度の売り上げは前年度比で2倍以上に達するほど伸びている。

　同社は2014年、事業の生命線とも呼ぶべきこのLogicadのシステム構成を抜本的に見直した。背景には、収集されるログデータの急増と、それに伴うデータ分析コストの増加があった。

Hadoopに関する記事

Hadoop事例記事

AWSデータ分析事例

ゼンリンデータコムのビッグデータチームが指南、AWSマネージドHadoopの勘所とは？

1日当たり400Gバイトのログデータをどう効率的に解析するか

ソネット・メディア・ネットワークス
安田崇浩氏

　ソネット・メディア・ネットワークスにとってLogicadで収集される広告配信ログは“宝の山”である。その解析を通じたDSPの機能強化は、競合との差別化、ひいては収益向上に直結する取り組みだ。そこで同社では、Logicadの早期立ち上げの際に「Amazon Web Services」（AWS）を採用したことで、当初から広告配信ログを「Amazon Simple Storage Service」（Amazon S3）で一元管理していた。Apache Hadoop基盤の「Amazon Elastic MapReduce」（Amazon EMR）やデータウェアハウス（DWH）の「Amazon Redshift」、オンプレミスのカラム型データベースなどによって、データマイニングの専門部署がログの解析作業を実施。広告の配信効果を管理するとともに、配信エンジンの機械学習用データ生成や新機能のリリース／効果確認、リポート作成、アドホック分析など、多様な用途で活用していた。

　しかし近年になって、収集されるログが急増するという問題が顕在化してきた。その量は2014年には1日当たり400Gバイト、件数で20億にも達し、分析作業に支障を来たすようになっていた。ソネット・メディア・ネットワークスの技術・開発部の部長でシニアアーキテクトも務める安田崇浩氏は、「Amazon EMRやAmazon Redshiftを常時起動させた場合はコストがかさみます。そのため、作業の都度、環境を立ち上げAmazon S3からデータを取り込んでいましたが、データが膨大となったことで解析開始までに少なからぬ時間を要することになり、そのことが作業を阻む一因となっていました」と当時を振り返る。

　また、データ量が増えれば必然的に処理時間も長引く。その結果、例えばAmazon EMRでのHiveの処理が、1クエリ当たり数十分もかかり、日々の継続的な分析を困難にさせていたという。

　一方で、「ログデータの中には解析に値しないデータも多数含まれています」と安田氏。それらを全て取り込んでの処理は、無駄なコストの発生が避けられないため、同社では期間を区切ったり、サンプリングしたりといった工夫を施していた。だが、このことは裏を返すと、せっかくの宝の山となり得る大量データを活用し切れないことに等しい。

常時稼働のHadoopがシステム移行の切り札に

　では、これらの問題に果たしてどう対応すべきか。同社が着目したのは、オンプレミスで分析環境を整備することである。Amazon S3とのデータ連係さえ確立できれば、分析基盤にはオンプレミスを活用した方がコストと性能の両面で既存環境よりも格段に優位だった。また、分析の自由度も高められると判断した。

　この考えの下、同社ではまず、各種DWH製品によるオンプレミス環境の整備を検討した。だが、最終的にこのアイデアは見送らざるを得なかった。分析対象となるデータは今後も急増し続けることが予想できる。DWHの専用製品ではライセンスやハードウェアへの継続的な追加投資が必要となる。しかも、そのユーザーは社内でも限られるとともに、ログデータの中には前述した通り、アクセス頻度の低いコールドデータが高い割合で含まれている。

　「ベンダー各社から見積もりを取り寄せたところ、想像以上にコスト負担が大きくなることが判明しました。また、せっかく導入しても、ユーザーの少なさから十分な費用対効果を得ることが困難だとの結論に至りました」（安田氏）

　こうした試行錯誤と前後し、安田氏はHadoopの商用製品である「Cloudera Impala」の性能の高さについての情報を耳にする。そして、これが最終的にプロジェクトの方向性を決定づけた。

　「試しに環境を構成して動かしてみたところ、アドホッククエリが想像以上に軽快に動くことに驚かされました。また、Cloudera Impalaはコストと機能の両面で、われわれの使い方に極めて合致していたのです」（安田氏）

　安田氏はこの検証を通し、Cloudera Impalaによって常時稼働のHadoopクラスタを構成することで、Amazon EMRやAmazon Redshiftからの移行に耐え得ると判断。これを受け、同社では分析環境の移行作業がいよいよ本格化することになったのである。

次ページへオンプレミスの分析基盤として選んだのは？