SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2018 夏】セッションレポート(PR)

課せられたのは「4時間で100社分のデータ処理」――2年目エンジニアが挑んだ機械学習【デブサミ2018 夏】

【C-2】メモリも、僕のキャパシティも溢れっぱなし。。2年目エンジニアが実現した機械学習

  • このエントリーをはてなブックマークに追加

 スマートフォンやパソコン、タブレットなど、複数のデバイスを日常的に利用するユーザーが増えている。そうしたユーザーの行動をトラッキングするため、株式会社ロックオンが提供するマーケティングプラットフォーム「アドエビス」では、デバイスやブラウザをまたぐ同一ユーザーを推定する「クロスデバイス機能」の提供を開始した。その裏側を支えているのは、膨大な量のアクセスデータを機械学習によって処理する分析基盤だ。本セッションでは入社2年目の若手エンジニアである内藤勇之助氏が、機械学習を用いたサービス開発で苦労した点や工夫した点について語った。

  • このエントリーをはてなブックマークに追加
株式会社ロックオン 開発部 内藤勇之助氏
株式会社ロックオン 開発部 内藤勇之助氏

機械学習を活用し、クロスデバイス計測を実現

 「アドエビス」は、広告効果測定ツール市場で3年連続シェアNo.1を誇るツールだ。導入実績は9000件を超え、アクセスデータは年間120億件以上を計測している。その「アドエビス」が提供開始した「クロスデバイス機能」は、どのような課題を解決するために生まれたものなのだろうか。

 「例えば、ある人が自宅のパソコンでWeb広告をクリックし、遷移先のサイトで商品の情報を見たけれど、その時は商品の購入に至らなかったとします。そして翌朝、通勤中にスマートフォンでブラウザを開き、昨日見ていた商品をもう一度調べて、購入に至るケースはよくあると思います。ここで、ある問題が生じます。これまでの広告効果測定は基本的に各デバイスが持つCookie情報からユーザーを判別しているため、パソコンとスマートフォンではCookieが異なり別の人と判定されてしまうのです」

 この事象が起きると、効果測定に不都合が生じる。例えば、1000万円の費用をかけてWeb広告を出稿するとしよう。クロスデバイスを考慮しない広告効果測定の場合、前述のシチュエーションが起きると、広告クリック後のコンバージョン率が低く判定されてしまうのだ。そして広告は効果が低いとみなされて取りやめになる。その結果、購入数が激減するという事態が起こりうる。デバイスをまたぐアクセスだけでなく、デバイスが同一であってもCookieを共有できない、異なるブラウザやアプリ間で発生するアクセスにも同様のことが言える。

スマートフォンの普及によるマルチデバイス化
スマートフォンの普及によるマルチデバイス化

 複数のデバイスをまたがって最終的にコンバージョンに至ることをクロスデバイスコンバージョンという。現在ではその割合が全体の40%ほどを占める。だからこそ、広告効果測定においてはクロスデバイスユーザーの判別が非常に重要になってきている。

 それを実現するため、同社は機械学習による分析基盤の構築を行った。ユーザーエージェントやIPアドレス、アクセス時間帯といった膨大な種類のアクセスデータと教師データを用いて、ユーザーを類推していったという。

 このプロジェクトでは、大きく分けて2つの要件をクリアする必要があった。

 「1つ目はスケーラビリティです。最初は10社くらいの導入数だとしても、将来的には10倍にも100倍にも利用者が増えていきます。そうなったとしても、遅延なく分析結果をお客さまにご提供できなければいけません。課せられた目安は、4時間で100社分のデータを処理することでした。2つ目は精度です。これが担保できないと、そもそもサービスとして成り立ちません。ある意味で相反する2つの要素を、同時に改善し続けていく必要がありました」

どうすれば、精度の高い分析を4時間以内に終えられるか?

分析基盤の全体構成イメージ
分析基盤の全体構成イメージ

 上図は、同社が開発した分析基盤のイメージ図だ。オンプレの環境にある大量のアクセスデータをクラウド上に移して分析する。その結果を再度オンプレの環境に移し、顧客が閲覧できる状態にする流れだ。この基盤上で、前述した2つの要件をどのように解決していったのだろうか。

 「まずスケーラビリティについて解説すると、前提として、分析対象の企業数が増えたとしても性能を落としてはいけません。その課題をクリアするため、AmazonEMRというサービスを用いました」

 Amazon EMRは、大量データを効率的に処理するためにHadoopを使用できるプラットフォームサービスだ。AWSのAmazon EC2インスタンス上に構築されたHadoopクラスタを、必要に応じて柔軟に増減できる。

 また、分析対象となるデータの格納にはAmazon S3を用いた。扱うデータ量が膨大だったため自由自在に拡張してくれるクラウドストレージは「うってつけの環境だった」という。

 ところが研究を始めてすぐ、ある課題に直面する。処理に時間がかかり過ぎてしまったのだ。当初は、1社の分析を終えるのに40分以上を要した。求められている水準が4時間で100社であることを考えると、1社あたりにかけられる時間は約2.4分。大きな乖離があった。この差を埋めていくために数多くの工夫を行ったという。

 1つ目の工夫は、分析クラスタを並列に複数起動させること。この手法は高速化以外にもメリットがある。クラスタの冗長化による可用性の向上だ。つまり、特定のクラスタに何かの問題が発生しても、他のクラスタが残りのデータを拾って分析処理を続行できる。

 本プロジェクトでは、10クラスタを立ち上げて10並列で分析を行った。これにより、1社分の処理にかけられる時間は1クラスタあたり24分となり、現実味のある数字となってきた。しかし、道のりはまだ遠い。どんな手段を用いて残りの時間を縮めていったのだろうか。

 2つ目の工夫は、各クラスタの共通処理を切り出して、初回に一度だけ実行するような設計にすること。これにより、1社あたりおよそ4~5分ほどの時間が短縮できたという。

 3つ目の工夫は、組み合わせの量を減らすこと。つまり、必要のないデータを省いていくということだ。それほど分析精度の向上に寄与しないと思われるデータをばっさり切り捨て、検証してはまた切り捨てて……といったトライ&エラーをくり返し、データ量を減らしていった。

 その他にもApache Hiveのクエリチューニングなどいくつもの改善を続け、実用に耐えうるレベルまで高速化を続けていった。

 「ですが、そのまま何事もなく順調にプロジェクトが進んで終了、とはなりませんでした。他のメンバーが行っていた作業とのバッティングが起きたのです。チームにボーロンというベテランのフランス人開発者がいるのですが、彼は主に分析精度を改善するための研究をしていました。毎日さまざまな手法を試して、精度が少しでも良くなったらそのソースコードをプッシュするわけです。何が起きたかというと、彼の変更したアルゴリズムを取り込んでみると、確かに精度は上がっているけれど速度が遅くなっているのです。せっかく処理速度を改善したところがまた遅くなる……ということが、くり返し行われました。でもその中で、地道に課題と向き合いながら、精度と性能の改善を両立していきました」

 高水準な分析基盤の構築は、一朝一夕には実現しない。改善のサイクルを回し続けながら、少しずつ性能を向上させていくことが重要なのだ。機械学習によるデータ分析をサービスに取り入れる際には、顧客に満足してもらえるサービスの質を担保するのが前提の上で、裏でも絶え間なくシステムの改善を続けることが何よりも大切であり、同時に大変でもある。そう総括し、内藤氏はセッションを締めくくった。

お問い合わせ

 株式会社ロックオン

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11026 2018/09/03 14:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング