ビッグデータの活用が広がりを見せているが、システム開発に携わっている普通のエンジニアにとって、データ分析はそれほど馴染みのあるものではない。ましてや分析自体を自身ですることは、データ分析チームに配属されない限り関係がないことだと思っている人も多いだろう。
しかし神田氏は、「これからのシステムエンジニアにとって、データ分析をし、その結果を見ることができなければ、リスクになると考えた方が良い」と言い切る。なぜ、そう言えるのだろうか。
システム開発エンジニアにとってデータ分析スキルは必要か
神田氏はアドテク本部に所属し、スマートフォン向けのアドテク「AMoAd（アモアド）」のシステムを開発していることから、自身のことを「いわゆる普通のエンジニアだ」と言う。
そんな神田氏がなぜ、データ分析に興味を持ったのか。そのきっかけは「現状把握に時間がどれだけかかっているのか」という単純な疑問からだと語る。
システム運用をしていると、エンジニアとして把握しておかなければならないことがいくつかある。日別・週別のアクティブユーザー数や1日におけるユーザーの平均広告接触回数などはその一例だろう。ただこのような定期的な情報であれば、集計や分析のフローが整理されているので、時間をかけずに結果を出すことができる。
しかし「ユーザーの平均広告接触回数をOS別に知りたいというような、少しアドホックな条件を加えて分析しようとすると、ものによっては1週間以上かかることもあった」と神田氏は明かす。
このようにちょっとした疑問を解決するのにでも時間がかかることの弊害の第一は、ちょっとした疑問が生じても調査しなくなることだ。つまり「本当に困ることが発生するまで、調査をしなくなる」というわけだ。そういう習慣が身についてしまうと、「根拠のない思い込みによる誤った判断」や「古い調査結果に基づく誤った判断」が行われてしまう。
第二の弊害は、データを見るには特異なスキルが必要だと思ってしまうことである。「人は時間がかかる＝誰もができない特異なスキルが必要と思いがち。データの分析や抽出はやり方さえ分かれば、エンジニアならだれでもできること。しかし実際にやったことのない人は先のように思いがちなので、一部の人にしかできないタスクだと思ってしまう。これによりデータ抽出・分析業務の属人化が起こってしまう」と警鐘を鳴らす。
ではなぜ、時間がかかってしまうのか。神田氏は、仮説検証、ETL（Extract/Transform/Load）、データ抽出、分析のどの工程にどれだけ時間がかかるのか、自身のチームで調べてみたと言う。分析対象としたのはアプリケーションサーバのログデータ。「一か月分のデータから抽出しようとしたところ、ETLの情報を流すだけでも何週間もかかってしまった」と神田氏は続ける。「どのデータをどのくらい分析するか、分析対象のデータサイズによって分析時間は大きく変わる」ことが分かったのだ。
理想的には誰でも、気軽にデータ抽出・データ分析ができるような仕組みを実現したい。ではその理想の仕組みを作るのには何が必要なのか。「それは大きく3つある」と神田氏は指摘する。
第一はデータへのアクセスが容易であること。もちろんこれはセキュリティ的な観点を考慮した上での話だが、「広い範囲のデータにアクセスできた方が、開発に関わっている人たちも新しい知見を得られ、改善につながるので良い」と神田氏は説明する。
第二は高い応答性。「これは非常に重要」と神田氏。「理想的には5分以内に返ってくるように設計したい」。
そして第三が手順の再現性である。つまり誰が分析をやっても同じデータが得られるような再現性を担保することだというのである。
では実際にどのようなことを行ったのか。まず「データ分析の専用ログを出力するようにした」と神田氏。これまではいろいろな場所にさまざまなフォーマットのログがあったが、それを分析するのではなく分析用の専用ログを作ったというのである。これにより「データサイズも抑えられた」という。
次に行ったのはデータ分析基盤の構築。「計算エンジンはBigQueryとSparkを採用した」と神田氏。BigQueryはクラウド、Sparkはオンプレミスで運用。ストレージはGoogle Cloud Storage、UIはApache ZeppelinとJupyterを採用。「Apache ZeppelinとJupyterの両方を入れているのは、エンジニアの好みがあるため。双方のニーズに応えることで、データ分析の間口を拡げられると考えた」とその理由を明かす。
データ分析基盤は応答性を重視、誰もが気軽に使えるように
データ分析基盤の構成は下図のとおり。アプリケーションサーバからFluentdでログを抽出し、Streaming InsetでBigQueryへ。対象となるデータは大きいので、一定の期間が経ったら、Google Cloud Storageにエクスポート。過去のデータも含めて分析したい場合は、Google Cloud Storageからインポートすると、BigQueryで分析できる。またGoogle Cloud StorageはオンプレミスのSparkからも読み書きができるようなっている。「分析用のログ以外のデータソースにアクセスしてデータ処理をしたい場合はSparkを使っている」と神田氏。
こういう構成にしたのは、「とにかく応答性を重視したから」と神田氏は説明する。分析ツールにBigQueryを採用した理由については、「使いたかったということもあるが、BigQueryはIndex的なものの定義が不要で、アドホック分析に向いていたから」と語る。とにかくBigQueryにデータを入れておけば、思いついたクエリーが投げられるので便利なのだそうだ。
またSparkは分析ログに含まれないデータを処理したい場合に使うほか、機械学習を使いたいときなどにも使用しているという。「機械学習はSparkやscikit-learnを使っている。用途やデータソースによって環境を使い分けている」（神田氏）。
なぜこれほどまで応答性を重視するのか。それは先述したように、直観などのフィーリングを大事に考えているからだ。「直観は案外正しいが、根拠がない直観はダメ。しかし根拠のための調査をしようと思っても、結果を得るのに時間がかかると、コストと得られるメリットを天秤にかけてしまい、興味があるから調べるというような遊びのある調査は行わなくなってしまう。しかし10分以内で結果がでるのであれば、やってみようと思う人も増えると考えた」と神田氏は言う。
だがデータ分析環境ができたものの「最初はあまり使われなかった」と神田氏。理由は2つ。1つは使い方が分からなかったこと。「BigQueryもSparkもあり、UIも2種類といろいろありすぎた」のだという。2つめはそもそも何に使えるかわからなかったこと。「私たちのチームはあくまでも開発チーム。したがって分析の環境を作っても、『これで何をするんだっけ』ということになってしまう」というのだ。
そこで神田氏は使い方を共有するために、チュートリアルを開催したり、ドキュメント化をしたりしたという。「最も効果があったのは、ノートブックの活用」と神田氏は力強く語る。つまり他の人が分析した手順をノートブックに残すことで、「こういうことがしたい」と思ったときに参考にできるからだ。
ここまで解説したところで、実際に構築した分析基盤によるデモを実施。エンジニアでも簡単にデータ分析ができることを披露した。分析の手法はノートブックで共有できたが、「何に使えるのか」については、まだ共有する手段を試行錯誤しているからだ。
「基礎集計の結果と手順はチーム内のチャットグループで共有したり、有用なものは定型ジョブとして自動化したりしている。またTableauなどを使って可視化し、共有している」（神田氏）
エンジニアはデータ分析基盤を何に使えばよいのか。神田氏は「開発工程の選定やシステム改善の事前・事後の評価、運用フローの改善などに使える」と語る。開発項目の選定であれば、現状をより正確に把握し、開発すべき根拠を導き出してくれる。データ評価・分析のレベルを上げることや可視化、ワークフローの自動化などこれからの課題はいろいろあるが「BigQueryを使って人生が変わった」と神田氏は熱く語る。
気軽にデータ抽出できることで、新たな気づきがあるだけではない。今まで理解していたことよりも、さらにより深く、自分たちが作っているシステムの理解ができるようになったからだ。そして開発者がリリースした機能を自分で評価でき、改善サイクル回すスピードも上がる。
「データ分析のスキルは特異なものではない。データを見られないことはもはやリスクと捉えるべきではないか」こう参加者に問いかけ、神田氏はセッションを締めくくった。
お問い合わせ
株式会社サイバーエージェント
TEL: 03-5459-0202
