インターネット広告業界において、その効果を最大化する運用力を強みに、代理店事業やアドテク事業など総合的なソリューションも提供しているネット広告の雄・サイバーエージェント。同社は、これまで実現が難しいとされていた、ライブ番組やニュース速報の結果をリアルタイムで取り入れ最適化する DSP（Demand Side Platform）を開発しました。開発者曰く、Google Cloud Platform でなければ実現できなかったという理由を聞いてきました。


■ 写真左から

アドテク本部 アドテクスタジオ
　DSPプロダクト 技術責任者　井上 ゆり氏
　DSPプロダクト 開発責任者　新田 智啓氏


■ 利用している Google Cloud Platform サービス

Kubernetes Engine、Google App Engine、Cloud Functions、Cloud Spanner、Cloud SQL、Cloud Dataflow、Cloud Pub/Sub、Google BigQuery、Google Stackdriver、Container Registry など


■ 株式会社サイバーエージェント

1998 年の創業以来、主力事業として国内トップシェアを誇る広告代理店だけでなく、動画広告やクリエイティブ制作、AI を広告配信技術に活用する研究開発も進めているインターネット広告事業のほか、「AbemaTV」「AWA」などに代表されるメディア事業、「プリンセスコネクト！Re：Dive」などの大ヒットタイトルを擁するゲーム事業を 3 本の柱として成長を続けている。現在の社員数は約 4,576 名（連結含む）（2018 年 4 月末時点）。

アドテクで重視されるのはレイテンシーの小ささとスループット


対となる SSP（Supply Side Platform）との連携で、インターネット広告の費用対効果を最大のものにする DSP は、今や Web マーケティングの世界においてなくてはならない存在です。広告枠を設けた Web ページにユーザーがアクセスした瞬間、その背後ではその 1 回の広告表示に対する入札がリアルタイムに行われ（RTB＝Real Time Bidding）、即座にそのユーザーにマッチした広告が表示される仕組みとなっています。ところがこれまでこの仕組みは、ある特定のサービスに関してはうまく機能させることができていませんでした。

「新たに開発した DSP にとって大切なことは、トレンドをいち早く取り込み、即座に広告クリエイティブに反映して配信すること。また、DSP として即座に結果を利用し “最適化” していくこと。ただ、従来はそれをリアルタイムに実施するのが難しく、例えば、まさに今配信されているライブ番組やニュース速報などといった分野には対応できていませんでした。一般的な EC などであれば、1 日配信した結果を翌日分に反映するスピード感でよかったのですが、1 時間もしたら終わってしまうライブ番組では、それでは遅すぎます。ライブ番組やニュース速報の結果をリアルタイムに広告に反映させる仕組みにニーズがあるのか、どのような可能性があるのかを検証するという目的もあり、開発をしてきました。」（新田さん）

そこに求められるのは、とことん「スピード」だと新田さんは言います。RTB のレイテンシ、ビックデータの分析レスポンス、機能開発スピード、事業目標の変化への対応スピード、そのスピードを実現するために選ばれたのが Google Cloud Platform（GCP） でした。






「社内のオンプレ環境も含めさまざまな選択肢を検討しましたが、どれを選ぶにせよ、まず BigQuery を使うことは決めていました。広告配信は RTB というリアルタイムに入札するシステムなので、秒間数万以上のリクエストを受け、毎月 TB クラスのデータが溜まっていく中で、充分なパフォーマンスとスケーラビリティを確保するには BigQuery しか選択肢がありませんでした。」（新田さん）


「また、マイクロサービス・アーキテクチャを採用しようとも考えていたので、当時、Kubernetes をマネージドで動かせる選択肢が GCP しかなかったというのも、GCP を選んだ大きな理由の 1 つです。そして、実際に使ってみてやっぱり便利だな、と。テスト環境を作ったり壊したりするのが非常に楽なので、開発効率が大きく上がりました。Stackdriver Debugger でシステムエラーなどのログを分析すると、すごい速度で結果が返ってくるのにも助けられましたね。」（井上さん）

Google が得意とする AI や機械学習を駆使してさらなるサービス品質向上を目指す


こうして、2017 年夏にスタートした開発は秋口にはおおむね完了。同年 11 月には広告配信が開始され、GCP を利用することが決定してから約 5 か月という迅速な開発に成功しました。広告配信部分や、どのような広告を配信するかといった部分はすべて Kubernetes Engine（GKE）上に構築され、そのほかにも多くの Google サービスを駆使しなければ、大規模なデータをさばくこのシステムを少人数のチームでこれだけのスピード感で作ることはできませんでした。

「広告の情報を管理するマスタデータは Cloud SQL で、広告予算情報のようなリアルタイムに処理せねばならないうえに、絶対に落としてはいけないようなものはトランザクション処理を大規模に行える Cloud Spanner で扱い、その他のインプレッションやクリックなどのログは Cloud Pub/Sub に流して Cloud Dataflow で処理しています。現在の課題は、Cloud Dataflow の使い方の見直し。広告規模のデータを処理するとどうしてもお金がかかってしまうので、これを何とかする工夫を検討中です。」（井上さん）


「とはいえ、肝心の速度については過去に培ってきたノウハウもあって、大きな苦労はなく実現できました。そのうえで Spanner に関してはさらなる高速化に期待しています。1 回あたり 6 ミリ秒というのは一般的な用途であれば充分速いのですが、広告配信の世界ではまだ厳しい。100 ミリ秒以内にレスポンスを返さねばならない中、50 ミリ秒をネットワーク通信部分で使うことを考えると、最大 3 回くらいしか投げられないため、そこも今後の課題ですね。話題の Cloud Memorystore for Redis が東京リージョンでも使えるようになったらすぐにでも導入したいと考えています。」（新田さん）

最後に、今回の経験を経て、今後も別のプロダクト開発において GCP を活用していく可能性があるか、今回利用した GCP サービスとは別に興味を持った GCP サービスがあるかを聞いてみました。

「もちろん、新しい開発に活用していくことは大いにありえると思います。個人的に試してみたいのは Google Cloud Natural Language API や Google Cloud Vision API ですね。社内にも AI Lab という広告の配信技術に AI をとりいれていく専門の部署があるのですが、この API を使えば自分たちだけでもある程度のことはできそうです。多くのデータからどの単語が重要なのか、広告バナー画像にどれが適しているかなどを分析して、何か新しいことができるんじゃないかと考えています。」（新田さん）

「私は Cloud Composer に注目しています。まだ試せていないのですが、これを使って機械学習のパイプラインをきれいに作り直したいですね。バッチ的な処理は現在 Google App Engine の Cron で実行しているのですが、少し設定にクセがあるのでそこを置き換えてあげたいです。後は Kubernetes のコンテナに機械学習をさせるためのツールである Kubeflow がマネージドに入ってほしいですね。」（井上さん）


株式会社サイバーエージェントの導入事例 PDF はこちらをご覧ください。
GCP のその他の導入事例はこちらをご覧ください。