データ分析基盤の課題と取り組み
越野雄弥氏（以下、越野）：マクロミルの越野です。私からは「マクロミルで活用されるデータ分析基盤」のお話しをします。マクロミルは、AWSで分析基盤を構築していて、そのデータ分析基盤の課題や取り組みについて話していきます。本日はどうぞよろしくお願いします。
本日のアジェンダです。
社内向けデータ分析基盤を担当
自己紹介からさせてください。改めまして、越野雄弥と申します。2013年の11月にマクロミルに入社して、5年ほどマーケティングリサーチのシステム基盤を担当していました。去年から、社内向けのデータ分析基盤を担当しています。
趣味として、3つ挙げています。1つ目はラーメン作りです。ラーメンを食べ歩いているうちに自分でもラーメンを作りたくなり、主に煮干しを使ったラーメンを作っています。
2つ目は、コーヒーです。会社でもお昼休みになると豆を挽くところからコーヒーを楽しんでいます。
3つ目は、ゲーム。「NieR:Automata」と「FINAL FANTASY XIV」いうゲームが好きです。
「FINAL FANTASY XIV」はオンラインゲームで、「NieR:Automataコラボ」をきっかけに始めました。ストーリー、音楽がとてもよくて、このよさを誰かに共有したくて、今では社内の人を誘い、3人ほど光の戦士が生まれ、一緒に冒険しています。
右下の画像は、AWSの資格です。今はアソシエイトレベルの3つを取っています。今後はプロフェッショナルにも挑戦していきたいと思っています。
リサーチやアンケートをメインとした会社
続いて会社紹介をさせてください。マクロミルをご存知の方は、まだそんなに多くないのかなと思っています。一言で言うとマクロミルは、リサーチやアンケートをメインとしてやっている会社です。創業は2000年の1月で、今年でちょうど20年になったばかりの企業です。本社は品川に構えていて、従業員は連結で2,500名程度です。
今「リサーチをやっている会社」と言いましたが、リサーチと言ってもいろいろあり、代表的な6つのサービスを紹介します。
（スライド左の）1つ目のインターネットというのは、インターネット上でのアンケート配信です。マクロミルの100万人以上のモニター会員に対して、アンケートをしています。
2つ目のオフラインは、会場調査やグループインタビューのことです。マクロミルの会場にモニター会員に来ていただいて、メーカーの新商品を試していただいて調査、インタビューなどをしています。
3つ目のグローバルというのは、名前の通りで、世界90ヶ国のグローバル調査への対応をしています。
4つ目はデジタルマーケティング。これはオンライン行動データのアクセスログ計測を主軸に、タグ接触などによる広告の効果測定などを行っているサービスです。
5つ目はデータベース。マクロミルのモニター会員の一部に、日常で買っている商品からバーコードをスキャンしてもらって、購買データを送ってもらっています。その購買データ・購買履歴を元に「こんな商品を買っている人にアンケートをしたい」といったような要望に応えるサービスです。
最後のセルフ型は、自分でアンケートを作成して回答を集めることができるサービスで、簡単な集計も無料で利用できるので、ぜひ使ってみてください。
AWSでデータ分析基盤を構築
システム系の部署は、3つに分かれています。私の所属している第1プロダクト開発部は、既存事業や社内システムとは独立していて、ビジネス成長のための新規事業という位置づけで、新しいことにチャレンジする部署です。今回お話するデータ分析基盤もこちらにあります。
最近では、クラウドのセンターオブエクセレンス、略してCCoEといった横連携の動きを始めていて、技術面で先行しているメンバーがリードして、AWSにも全面的に協力してもらいながら、部内に限らず構成レビューするなど、横断的な活動をしています。
AWSとは技術研究の取り組みもしていて、新しい技術を使って楽しく・おもしろくをテーマに取り組んでいます。2019年の事例だと、調査に関係する役立つツールとして、RekognitionやSageMakerを使った、顔に自動で目線を入れていくようなものを作りました。
データ分析の目的
まず、データ分析の目的とは何でしょうか？ 社内にヒアリングしていくと、「データの相関を見つけたい」とか、「蓄積されたデータから新たな発見を得たい」とか、「仮説を確かなものにしたい」とかがありました。これら3つすべてに言えることですが、根本としてあるのが、「データ分析というのは意思決定のためにやっているんですよ」ということです。
データ分析は手段なので、目的があってようやく意味があるものになります。目的を定めずになんとなくデータ分析を始めてしまうと、広がりすぎてしまいます。データを見るのは楽しいのですが、時間ばかり経過していくことがけっこう多いです。このようなことはみなさんも経験があるのではないでしょうか。
ETL済みのデータを分析する
続いてデータ分析の処理フローです。データ分析基盤の中で、このような処理フローが行われています。まずデータを集めて保存し、それらを今度は、抽出・加工・書き出します。この部分をETL（註：Extract（抽出）、Transform（変換）、Load（格納）の略）と言います。そのETL済みのデータを分析するのが、データ分析の基本的なステップです。
マクロミルの分析基盤は、「SUNA-BA」という名前で呼んでいます。先日社内のデザイナーが作ってくれたロゴです。、せっかくの機会ですので掲載しました。
マクロミルのデータ分析基盤の全体構成です。各システムから集めているデータ、例えばWeb回遊データ、スマートフォンの位置情報データ、テレビの視聴データ、APPログ、購買データなど、こういったものをまずはデータレイクに入れて、そこからETL処理をしてウェアハウスに入れます。
そのデータをユーザーにとって使いやすくするのが、右側のSUNA-BAポータルです。このポータルの中からクエリを実行することもできますし、データカタログという部分で、そのデータが何を示しているのかを覧で見られるようにしています。
ユーザーにはどんな人がいるか。マクロミルの中で言うとデータの分析者、あとは新しいビジネスを作っていこうとする事業企画の方々などです。このデータ分析基盤は、社内システムからも使われることがあります。
データ分析基盤がほしかったわけと、要求を満たす必要条件
これらのデータ分析基盤が生まれた背景です。マクロミルは「リサーチをやってきた会社」と言いましたが、創業以来さまざまなデータを蓄積してきました。ただそのデータの有効活用というところは、なかなか整っていませんでした。さらなるビジネス拡大を考えたときに「データからインサイトを得るための環境がほしい」、これがきっかけです。
それらを満たすために必要な条件が2つありました。1つは、社内すべてのサービス・システムのデータを保有していること。もう1つは、各システムのデータ参照が可能なだけではなく、それらを掛け合わせた集計や抽出が可能であることです。
データを集めるのではなく取りに行く
それらを満たすために作っていくアーキテクチャです。作るために必要な構築にあたってシステム面がどうだったか。各サービスは縦割り構成でした。システム間は連携されていません。事業会社とかだと、けっこうみんなバラバラだったりするのではないかと思います。
環境にしても、今でこそマクロミルでは全部クラウドに上がっていますが、当時はオンプレミスとクラウドが混ざっていました。データを集めるといったときに、データベースにしてもMySQLを使っているところもあれば、Oracle、SQLServer、PostgreSQLなど、バラバラでした。
データ量に関しても、近年の新しいところは保有データが多く、たとえば、広告データ測定を提供するAccessMillというサービスでは、1時間あたり30ギガバイトぐらいの勢いで増えています。これは月間150億アクセスくらいあるサービスです。
実際にデータ分析基盤を作ろうとなって、データレイクにデータを集めようとしたときに、各プロダクトに聞いていくとこのような回答が返ってきてしまいます。事業会社のあるあるなんじゃないですかね。やっていることで、いっぱいいっぱいになってしまう。
ではできないかと言うと（そうではなく）、マクロミルでは、データレイクにデータを入れてもらうのではなくてこちらからデータを取りに行くというスタンスで、データ分析基盤を構築するようにしました。
AWS DMSを中心としたアーキテクチャ
そのときに核となったサービスが、AWS Database Migration Service（以下AWS DMS）です。特徴は3つあって、同種のデータベース間の移行はもちろんのこと、異種のデータベースの移行も対応していて、1回きりの移行ではなくて継続的なデータレプリケーションもできる。これらが主な特徴です。
アーキテクチャをもう少し詳細に表した図がこちらです。各データベースからAWS DMSを通してAurora MySQLにデータを集めています。DMSのところも工夫しています。当初は、「日次でデータがあればいい」「データ連携ができていればいい」「昨日のデータが今日あればいいよ」という要件もあったので、時間起動でDMSタスクを動的生成しています。
CloudWatch Eventで何時に起動し、Step Functionsを通じて、Lambdaが起動され、LambdaからDMSタスクを1つひとつ動的タスクを生成していくという仕組みをとっています。中にはデータベースからAuroraまで、ずっと連携し続けている継続的なレプリケーションをやっているものもあります。リカバリー制御が必要になってくるところはJenkinsに寄せるなど、各パターンを使い分けています。
Auroraまで持っていくところまでがデータを保存するところです。保存したデータを、今度はAWS Batchを使ってファイル化し、ETL処理しています。こちらのバッチも工夫しています。バッチの中で並列にコンテナが動くのですが、そこからAuroraのParallel Queryという機能を使うことで、パラレルなコンテナからの大量のデータを処理できるようにし、高速なファイル化ができるようにしています。
だいたい30ギガバイト程度であれば、8分ぐらいでファイル化できます。それらをS3に置いています。S3に置かれたファイル群を、GlueやAthena、Redshiftから使う構成にしています。
Athenaの課題
弊社において、データ分析で一番重点的に使っているのがAthenaというサービスです。
Athenaを使っていくうちに、いろいろな課題にぶつかったので、次にこうした課題をどのように解決したかという話をしていきます。
データ分析基盤のユーザー数は順調に増えていって、今では300人を超えました。日本のマクロミルで言うと、（社員は）1,000人ぐらいなんですが、ここから営業さんを除くと2人に1人ぐらいの人が、このデータ分析基盤を使っているような状況です。ユーザーが増えていくとやっぱりどのシステムでも問題が起きると思うんですけど、表面化してきました。
それらの課題を1つひとつ書いていきます。
Athenaクエリが返ってこない
1つ目です。Athenaのクエリが返ってこなくなることがありました。ユーザーが増えたことでAthenaのリソースが枯渇するという事象が増えてきました。
ユーザーは、全員がSQLに強いというわけではありません。Athenaの特性上、あまり好ましくない「SELECT *」とかも当然のように叩かれます。実行完了までに時間の掛かるクエリを複数実行とかもあります。日付指定のやり方やクエリの書き方を覚えて、2015年から2020年を抽出したらどうなるんだろうと思って試す方も、やっぱりいます。
その結果、Athenaが応答できなくなって、「なんか、Athenaが動いてないんだけど!?」という問い合わせが来て、ユーザーが意図せず止めを刺してくるわけです。Google BigQueryとかを使っていたらたぶん動いてしまうので、今度はお財布のほうに止めを刺しにきますね。対応として、ユーザーの教育はもちろんですが、インフラ面でも、このような（スライドのような）対応をしてきました。
30分以上継続したクエリは問題になりやすい
Athenaのリソース監視を自前で構築して対応しました。やってみての感覚にはなるのですが、30分以上継続して実行されているクエリは、後々問題になる、Athenaのリソースに響いてくるようなリソースだということがわかってきまして、クエリのIDやクエリの内容とかを即座に通知するようにしています。
クエリの履歴等を見ていこうと、Amazonのコンソールの画面を見ている方もいると思うんですが、あの履歴がなかなか使いづらい。クエリの検索はできるんですがそのページ内のことしか検索できなくて、［Ctrl］＋［F］とやっていることが変わらないんですよね。
こうしたこともあって、どういったクエリが問題だったかを溜めていくところは、かなり大事な取り組みだと思っています。ユーザーも今後増えてきて、どのように使うかが見えてこないところもあるので、過去どうだったかというところを確認できるダッシュボードを作成しています。
ダッシュボードは、このようなかたちです。5分以上、10分以上、30分以上、60分以上経過しているクエリを追っています。30分以上叩かれるクエリというのが、1日1回ぐらいは叩かれます。その結果が1本とかだったらそこまで問題にはなってこないのですが、2本、3本と増えてくると、いよいよまずいことになってくるので、そういうところは「もしもし？」と言って、ユーザーさんに「止めていいですか？」ということをやっています。
データが更新されない問題
続いて2点目です。Athenaのデータが更新されず古くなっていることがありました。Athenaに限らずですが、データ分析基盤のデータがいつの時代のものかということは、どのデータ分析基盤でも大事なことだと思っています。ユーザーからすると、それはいつできたのかが本当に大事なことで、マクロミルではデータレイクからデータを取りに行く仕様もあって、連携元がどういうデータ変換をしたかというところが全部追いきれません。
そのため変化があったときに、問題が起きました。更新量が増えたことによるDMSの連携遅延だとか、ファイルサイズが増えたことによってバッチのコンテナのリソースを超えてしまったときとかに、ファイル化の失敗が起きてしまいました。バッチのファイル化失敗においてはエラーを検知できるんですが、DMSの連携のところだと遅延でそのまま動いているのでエラーは起きていないんです。
なので、なかなか検知しづらいこともあって、実際に利用している方々から問い合わせを受けて対応するという良くない状態が続いていたことがありました。これは本当に良くないことだと思っていて、自分がユーザーの立場だったとしたら「このデータって正しいのか？ 正しくないのか？」ということを疑いながら利用し続けることは、やっぱり難しいことですよね。
問題をゼロにするのではなくリカバリーで解決
とはいえ、データを取りに行くという都合、問題をゼロにしていくというのは、やっぱり難しいことなので、データ分析基盤を提供する立場としては、すぐに気づいてリカバリー可能な仕組みを作る必要がありました。対応として、データ分析基盤で提供している全データベース・全テーブルの更新時間を監視するようにしました。ダッシュボードを作っていて、どのテーブルに問題が起きたかを視覚的にわかりやすい仕組みにしています。リカバリーはワンクリックで本当に簡単に実行可能なようにしていて、なるべく気づいたらすぐに実行できるようにしています。
ダッシュボードは、このようなかたちです。ファイル化されてからそのデータがいつ時点のものか、その差分を追っています。問題がないところはグリーンで表示され、問題があってうまく連携できてないものは赤くなって、すぐわかるような仕組みです。
大量Viewの問題
3つ目はAthena上に生まれる大量のViewです。うちのデータレイクやウェアハウスにしても最低限のETL処理しかしていなくて、ほとんど生データに近いようなものになっています。ユーザー側のデータ分析者とかが、なるべく生の状態で使って、そこから自分でデータをデータウェアハウスとかマートみたいな感じで使いたいという要望があったからです。
ユーザーはAthenaのViewを利用したETLをやったつもりではいるのですが、AthenaのViewは論理的なビューであって、マテリアライズドな感じではなく、同じテーブルであってもそこに2回アクセスが発生したりして、あまり効率が良くない使い方になってしまっているんです。これらに対しては、本当に地道にやるしかなくて、ユーザーにヒアリングしてクエリのチューニングとか教育とかそういった方向で多方面にサポートしています。
データ分析基盤を提供することばかりに目がいっていると、ユーザーの求めているものからずれることがあります。我々の目的は、データ分析基盤を提供することではなく、これを使ってビジネスを成長させていくことに目を向けないといけません。ビジネス価値を生むためにはユーザーと向き合い、実現したいことを聞いて、それを形に素早く落とし込むのが大事だと思っています。
データ分析基盤に大事な3つのこと
最後に、まとめです。
データ分析基盤は、やっぱりモニタリングがとても大事だと思っています。とくにデータの更新時間はユーザーにとっても大事な情報であって、いつ時点の情報かというところを見せる必要があります。今、マクロミルでは問題があったときのお知らせぐらいしかできていないのですが、今後ユーザーへの見せ方を工夫していきたいところです。
2つ目は、アーキテクチャは常に改善し続ける。AWSに限らずですが、クラウドサービスを利用していると、1年後には新しい仕組みができていたりします。今うちのシステムでは、AWS BatchでがんばってETLとファイル化をしていますが、つい先日、Auroraのスナップショットからファイル化ができるようになったとか。実際に使えるかまだ試していませんが、どんどん新しい仕組みが登場します。
常に新しいものをウォッチして、取り入れられそうなものは取り入れていく。こうしたことを続けていくことが大事だと思っています。そのためには、チャレンジが許容される土俵が大事です。間違っていたら直せばいいし、そこら辺は今後もどんどんチャレンジしていきたいと思っています。こういうところは、今データ分析基盤をやっていて非常におもしろいところです。
3つ目はユーザーのやりたいことと向き合う。自分はシステム面ばかりにフォーカスして仕事をしているんですが、ユーザーの求めているものから、けっこうズレてしまうこともあります。利用されないものを作ってしまってはもったいないです。「ビジネス的な価値を生む」ということをきちんと目的とし、ユーザーと向き合っていかなければならないと思っています。
ユーザーにヒアリングしてみると、何に困っているか読み取りにくいことも多いです。でもそういったことも、ユーザーのサポートや教育をしていくことで、だんだん埋められていくのではないかと思っています。
私のお話は以上です。どうもありがとうございました。
