ユーザーの増加やサービスの多角化に伴い、各サービスの膨大なデータを収集・蓄積し、分析を行うことは、さらにサービスを発展させるために必要不可欠です。
そこで今回は、サイバーエージェント秋葉原ラボ・研究室長の福田一郎氏と、LINE Data Labsのデータエンジニアである吉田啓二氏に、「データ基盤の設計・マネジメント、データエンジニアリング」をテーマに、サービスを発展させる上で社内部署とどのように協力すればいいのかについて語っていただきました。
対談者プロフィール
株式会社サイバーエージェント 秋葉原ラボ研究室長 福田 一郎氏
2008年、サイバーエージェントに入社。2011年、秋葉原ラボを設立し、メディア事業全体の大規模データ処理基盤、データ分析、機械学習システムを統括している。
LINE株式会社 LINE Data Labs データエンジニア 吉田 啓二氏
LINEの全社員が担当サービスのデータを分析できるプラットフォーム"OASIS" の開発・運用を担当。
サイバーエージェントのデータ基盤「Patriot」と秋葉原ラボ
吉田：私はLINE Data Labsという部署で、LINEのサービスの各データが収集・蓄積されているデータ基盤から、LINEの社員が自由に担当サービスのデータを抽出して分析できるBI・レポーティングツール"OASIS"の開発・運用を主に担当しています。
LINE Data LabsではHadoop（※）などのオープンソースソフトウェア（OSS）を中心として構築された自社のデータ基盤を整えています。サイバーエージェントの秋葉原ラボでも同様に、Hadoopを中心に用いた自社のデータ基盤を構築されているそうですね。
※Hadoop…大規模なデータの管理・分析を分散処理技術によって行うオープンソースのソフトウェアフレームワーク
福田：もともとHadoopを用いたデータ基盤は、2010年頃にアメーバピグ向けに開発し始めたのが発端だったんです。その後、多角化する他の自社サービスにも収集したデータを活用できるように、基盤を整えていこうという動きがあり、2011年にデータ解析やマイニングの研究開発組織として秋葉原ラボを設立しました。
▲株式会社サイバーエージェント 福田一郎（ふくだ・いちろう）氏
吉田：秋葉原ラボはアメーバピグのデータ基盤から発展した経緯があるんですね。福田さんは、秋葉原ラボの立ち上げ時からずっとデータ分析向けのシステムに携わっていますよね。福田さんご自身がデータ分析システムに関わり始めた契機はあったんですか？
福田：私が新卒で入社した2008年当時は、サイバーエージェントのメディアサービスは「Ameba」のみで、私はAmebaブログやアメーバピグの運用・開発を担当していました。当時、アメーバピグではコンシューマ向けのデジタルアイテムの販売や課金システムが出始めた頃だったんです。
当時のブログサービスで計測できたことはPVや訪問者数の集計程度だったのですが、アメーバピグで行われていたデジタルアイテムの販売・課金や、一般のECシステムのようなユーザーを軸としたデータ分析をする基盤を整えたいと思ったのがスタートです。
ただ、レコメンドシステムのような機能を形成するのには時間がかかるし、何のためにデータ解析をするのかが理解されにくいんですね。そこで、まずは各サービスの担当者がKPIを定期的に把握できるようにレポーティングすることを目的とした「Patriot」というデータ分析基盤を、Hadoopを用いて開発しました。
最初は、「Patriot」をアメーバピグのマーケターに利用してもらうところからスタートしました。サービス分析に効果的だと好評で、それがきっかけで利用してくれる社内サービスが増えました。「Patriot」が成長するに伴い、秋葉原ラボも分析者や機械学習エンジニアが増員して発展してきています。
チーム体制は大きく3つのチームに分かれていて、現在は約40人います。大規模データ処理基盤の開発を行っているチームが約10人、データ分析を行うチームにデータアナリシスエンジニアが約10人、情報推薦や自然言語処理、マルチメディア解析など機械学習を行っているチームに15人くらいです。
最初の頃に比べると、組織としても人数が増えて成長しつつある段階ですね。
吉田：LINE Data Labsは50人くらいですね。主に大きく分けると4職種、機械学習エンジニア・データサイエンティスト・データプランナー・データエンジニアが所属しています。
LINEの全社員がデータ抽出・分析を行える複数のBIツール
吉田：秋葉原ラボは設立して7年半以上経っていますが、LINE Data Labsができたのは2016年なので、約2年前です。
当初は、データ基盤への各サービスのデータの収集や、そのデータの集計・加工を行うETL（※）バッチ処理の開発、BI・レポーティングツールを用いたレポート作成などを、全てLINE Data Labsのデータプランナーとデータエンジニアが行っており、各サービス側で自由かつスピーディーにデータ分析を行うことができないという課題がありました。
この課題を解決して、各サービス側で自由にデータ分析を行えるようにするために、データ基盤のデータをLINE社内へ提供・公開する取り組みが、2017年の後半から始まり、私もそのプロジェクトにジョインすることになりました。
※ETL…データウェアハウスを構築する上で、データを「Extract（抽出）」、「Transform（変換・加工」、「Load（出力）」する一連の作業のこと。
▲LINE株式会社 吉田啓二（よしだ・けいじ）氏
吉田：私が所属するチームでは、データ基盤に蓄積されているデータの活用を促進するための、社内向けのシステム・アプリケーションをいくつか開発・運用しています。私が開発しているのは、LINEの全社員が自分たちの手で自由に担当サービスのデータを分析することができる、「OASIS」というBIツールです。Apache Spark（※1）のアプリケーションや、Presto（※2）のクエリの実行が可能になっています。
※1 Apache Spark…Hadoopと同様、分散処理を行うフレームワーク。
※2 Presto…Faebook社が開発・公開した、高速にクエリを実行できる分散クエリ実行エンジン。
⇒ 参考：LINEの全社員が必要に応じて担当サービスのデータを分析できる環境の構築 - LINE Engineering Blog
サービス増加に伴うカオス化を抑えるには？
各サービスへのデータ出力
吉田：現在LINEでは、各サービスの担当者にクエリを書いてもらっていて、BIツールはサービス担当者の好みや案件によって使い分けてもらっています。サイバーエージェントでは、当初からレポート作成はサービス担当者が行っていたのですか？
福田：当初の「Patriot」は、アメーバピグのマーケティング担当者がレポーティンググラフを見ることができる仕様にしていました。そのときから、クエリを実行できるWebUIも用意していて、マーケティング担当者には、簡単なSQL（HiveQL）は書いてデータ抽出をしてもらっていましたね。
「PAC3（パックスリー）」と呼ばれる「Patriot」独自のワークフローエンジンを入れて、柔軟にデータの抽出・変換・出力をできるようにしていました。ある処理が終わると次の集計処理が行われるといった流れを整えたのが4、5年前です。
吉田：習慣化されているんですね。LINEではデータ基盤のデータの社内公開・提供を行う仕組みを構築する際に、「権限制御を厳密に行うこと」と「利用者数やサービスが増加しても安定して稼働させられること」を重視して開発を行ってきました。もともとは、データの整形・加工を行うバッチ処理はLINE Data Labsで開発・運用していたのですが、サービスが増えると対応が追いつかず……。
データ基盤のデータを社内公開するにあたり、各サービスに所属しているサービス開発担当のエンジニアにバッチ処理の開発・運用をお願いするフローを考えています。
福田：各サービス開発担当のエンジニアにバッチ処理をお願いすると、データマネジメントができなくなるんですよね。弊社では、データ基盤からデータの出力までの間に段階をひとつ多く挟んでいます。
技術本部という、秋葉原ラボも所属する横軸組織には、データマネジメントエンジニアが所属するチーム（秋葉原ラボとは別の組織）があるのですが、そこはレポート作成のためのデータの抽出・変換・出力を行うETLの設計・実装の役割も担っています。
「PAC3」のワークフローでは多少の専門的なエンジニアの知識が必要なので、データマネジメントエンジニアが所属するチームにETLの設計・実装に関しては任せてます。各サービス担当者には、データ抽出のプログラムを書くだけにしています。それでなんとか最低限のデータマネジメントは守っているという状態ですね。
吉田：データマネジメント部隊！データ管理はしっかり構造を決めないと、どんどんカオスになっていきますよね。
各サービスからのデータ収集
福田：あとは「Mine」という独自のデータ転送システムを導入しています。各サービスから生成されたデータを送ってもらうときに「フレームワークは使いづらい」「フロントエンド側から送りたい」といった意見をいただくので、HTTPで転送もできるようにしています。
「Mine」ではデータ転送する際にログのスキーマ設定ができるので、サービス側の方からすれば少々手間がかかるのですが「この形で送ってください」とお願いして運用しています。なるべく面倒な手作業は減らせるようなシステム設計を考えているので、ブラウザ上でサービスから送られてくるログの転送先が選択できるようにするなどの工夫もしています。
吉田：LINEで使っている「Aquarium」というデータ基盤のデータベース・テーブルのカタログツールでは、サービス毎に各テーブルの一覧があって、各テーブルやカラムの説明はサービス担当者が手入力していく流れになっています。
いろいろなテーブルがあると、各カラムの用途が分からなくなってくるので、本当はちゃんと管理したいのですが、いまいち良いソリューションが見つからず、手入力してもらうしかないんですよね。
福田：難しいですよね。説明しづらいというか書きづらいような特性のフィールドって出てきてしまう。
ちなみに、弊社はスキーマのバージョン管理はGitHub (GHE)を用いて行っています。記録を追えば変更が分かるようにはなっているのですが、様々な経緯で追えなくなることもあります（笑）。
考えを突き詰めていくと、データマネジメントのためにスキーマ管理だけはしっかりと行うことが必要です。何かしらのかたちでルールを設けて統制し、検証できるようにしないと、経験上、すぐにデータは乱れていきますから。
吉田：データの格納の仕方やデータ構造を設定し、データマネジメントができる環境を構築することが、今後のサービスの発展においても重要ということですね。
社員全体のデータリテラシー向上のための施策
吉田：全社員がデータを扱える環境を提供した一方で、想定外のデータが突然入ってきたり、不必要に重たいクエリ・アプリケーションが実行されたり、バランスが難しいと思うことがあります。
現在はデータ処理に関しての問い合わせ対応をチャット上で行っていて、問い合わせが来たら回答するという形を取っています。データ管理の最低限のルールを知ってもらうために、社内ではサービス担当者含め「みんなのデータリテラシーを上げていくぞ！」といった話もしていますね。
各サービスの部署のデータを取り扱うエンジニアと協力するか、高いデータリテラシーがなくてもうまく使えるようなツールを開発するか、どちらがよいのかを考えているところです。データを取り扱う際のスキルアップのための勉強会はやっていますか？
福田：SQLの書き方の講習は自主的に行なっています。ただ、そもそもデータベースやデータ構造の話は複雑すぎて、上手に教えることが難しく思いますね。効率的にデータを処理するとか効率的なデータモデリングをする必要性に行き着くんですけど、それが今からできるのかと考えると、なかなか厳しいですよね。
だからこそ、現在我々としてできることはデータ構造をどう作るべきかとか、こういうスキーマを作っておけばこういうふうに対応できるっていう流れの一般化みたいなのをやっていますね。
吉田：ルール化しておけば、そのルールに則っている限りはデータが乱れにくいということですね。サービスを専門に開発する人にもデータ構造を分かってもらうようにするのか、それとも大元で品質担保するのかは、どっちがいいのでしょうか？
LINEでは、ログのデータの品質担保の課題があります。各サービス側から送信されるログが欠損していたり、フィールドが変な値になっていたりすることがあり、時間が経ってからデータ分析担当のデータアナリストやエンジニアが気付くといったことがあります。この際に「データの品質担保は誰がやるべきか」となることが多くて（苦笑）。
サービス開発の担当者は、サービス開発を優先する気持ちも分かるのですが、データの品質担保をする人が誰もいないと、サービスを発展させる際に後々大変なことになるのに、各サービス担当側では対応しきれていないという状況になっています。
福田：「このサービスでこういうデータ管理をして失敗したんだよね」っていう話をサービス担当側に話しても、相手が担当していないサービスだと、うまく伝わらず「また同じことやるのか」という感じになるんですよね。
そうなると、データの定義やシステムといった「構造の設計をどうするのか？」を検討した方がいいのではないかと思います。
吉田：サービス担当側には、過去のデータ管理方法における失敗例やその背景をどうにか分かってほしい、という気持ちですよね。双方の歩み寄りは必要ではあると思うので、構造上の改善を進めつつ、それに対する理解も深めていくことが重要ですね。
⇒ 後編『データエンジニアからみる、本当の「エンジニア技術」とは？』に続きます！
