サービス利用者の増加や自社サービスの多角化に伴い、各サービスの膨大なデータを収集・蓄積し、分析を行うことは今後のサービスの発展において必要不可欠です。
前回は、サイバーエージェント秋葉原ラボの研究室長の福田一郎氏と、LINE Data Labsのデータエンジニア吉田啓二氏が、自社のデータ基盤を開発・運用しながらサービスを発展させる上で、社内部署とどのように協力すればいいのかについてお伝えしました。
今回は、実際にデータエンジニアリングを行う上での開発環境や求められる人材、今後の展望について議論します。
対談者プロフィール
株式会社サイバーエージェント 秋葉原ラボ研究室長 福田 一郎氏
2008年、サイバーエージェントに入社。2011年、秋葉原ラボを設立し、メディア事業全体の大規模データ処理基盤、データ分析、機械学習システムを統括している。
LINE株式会社 LINE Data Labs データエンジニア 吉田 啓二氏
LINEの全社員が担当サービスのデータを分析できるプラットフォーム"OASIS" の開発・運用を担当。
求めているのは、システム設計・データ構造の把握への視点を持つエンジニア
オンプレミスとクラウドの使い分け
吉田：私の前職では、すべてクラウド（※1）上のデータ基盤を使用していて、データ分析基盤の開発・運用を担当していました。その際、運用するにつれて増加していくクエリにかかるコストや、クエリを書く人たちのデータリテラシーのばらつき等が課題に挙がっていました。
LINEではクラウドは使用しておらず、Hadoop（※2）などのオープンソースソフトウェア（OSS）を中心として構築された自社のデータ基盤上で、データ分析が行われるようになっています。
⇒ 参考：LINEの全社員が必要に応じて担当サービスのデータを分析できる環境の構築 - LINE Engineering Blog
サイバーエージェントでは、自社のデータ基盤「Patriot」を構築されていることを伺ったのですが、クラウドの基盤も使用していますか？
▲LINE株式会社 吉田啓二（よしだ・けいじ）氏
福田：BigQuery（※3）を使用している部署が多いですが、どのクラウドサービスを使用するかは部署ごとに判断しています。
ただ、おっしゃる通りで、クラウドを使用した経験がある人はクラウドならではの課題を分かっているんですよね。
Amazon Redshift（※4）にデータを入れているサービスがあったのですが、すぐに容量や処理速度が不足してしまったり、とりあえず安いし保存するのに楽だからBigQueryに入れておこうというサービスもありました。その他にもFirebase上のAnalytics機能（※5）やAmazon Athena（※6）を使用してみたり、基盤が乱立する時期があったので、どの基盤を基本的に利用するかというのを決めるのが大変ですね。
BigQueryは高速で、クエリを投げると比較的すぐにレスポンスが返ってくるので、各サービスの担当者にとって便利な部分がとても多いです。しかし、クラウドサービスを使用すれば何も考えないで良いというわけではなく、分析ツールを使うユーザーの増加やサービスの多角化に伴ってスキーマ管理が乱れたり、効率的なクエリが書けなくなるといった問題も発生してきます。
それはかつてのデータエンジニアたちが、秋葉原ラボを設立する前に経験してきたことを繰り返しているのと同じなんですよね。ですので、現在は各サービスの担当者の意向でBigQueryを使用しているだけであって、秋葉原ラボとしては本質的な課題は使用するツールやサービスが何であるかではないという認識です。
あと、クラウドにかかるコストも結構厳しいのも事実です。
吉田：クエリ課金はサービス側の予算でまかなっているのですか？
福田：そうですね。あるサービスでは生のログをそのままBigQueryに入れるのと同時にオンプレのHadoopにも保存していたりもしますが、冗長だなとは感じていました。こういった基盤でのデータ保存の現状は、基盤構築・運用に携わる人しか分からない上に、サービス側にもあまり意識されていない部分だと思っています。
吉田：オンプレのデータ基盤も運用していると、データがオンプレ・クラウドの各ストレージに分散してしまうと思うのですが、不便ではないですか？
福田：自社のデータ基盤を構築して、データエンジニアを揃えて分析を行っている立場からすると、基本的にはオンプレでHadoopベースのデータ基盤を構築・運用したほうが、後々のデータマネジメントで効率的だと思います。自社の基盤をオンプレのHadoopで構築していると、「なぜパブリッククラウドに移行しないのですか？」と聞かれることが多いので、業界的にはパブリッククラウド利用がマジョリティなのかなと思います。
でも、どのクラウドもデータの入れ方に関するサポートは付いているんですけど、出し方のサポートってないんですよね。クラウドからオンプレに戻す場合や、他のクラウドに移す場合など、出ていかれる側のクラウドベンダーのサポートは基本的にないので、全てのデータをクラウドに持っていくことには慎重になってしまうところです。
一方で、即時的なレポートの作成などはクラウドの方が使用しやすい部分もあると思うので、社内での使用を禁止することはないです。悩みどころではありますね。
結局オンプレとクラウド、どちらを使用するにしても、最終的にはデータ設計や業務分析がしっかりできていないことに課題があるというところに辿り着きますね。
▲株式会社サイバーエージェント 福田一郎（ふくだ・いちろう）氏
吉田：そうなんですよね。LINEでは、60サービスくらいがデータ基盤を使用しています。とても大きいひとつのサービスがデータ基盤を使用するのではなく、細かいサービスが数多く使用している状態で、兼用するのも大変だと感じています。
福田：サイバーエージェントも年々さまざまなサービスが増加していて、現在グループ会社を含めると約150のプロダクトがあります。
NetflixとかUberのような、海外の有名企業は単一ドメイン環境が多いので、管理もしやすいと思っています。ただ、LINEやサイバーエージェントのように社内に多種多様なサービスを提供している会社では、全部のサービスのデータとデータ分析の状況を把握して対応することは難しいですよね。
吉田：お互いが満足できるような仕組みを一緒に作り上げていきたいですよね。
※1 クラウド…クラウドコンピューティングの略。サービス事業者が提供するシステム環境を利用すること。一方で、自社でデータ基盤を構築・運用することを「オンプレミス」と呼ぶ。略して、オンプレと呼ばれることも多い。
※2 Hadoop…大規模なデータの管理・分析を分散処理技術によって行うオープンソースのソフトウェアフレームワーク
※3 BigQuery…Google Cloud Platformが提供するビッグデータ解析サービス
※4 Redshift…Amazon Web Services（AWS）のクラウド型データウェアハウスサービス（DWH）
※5 Firebase上のAnalytics機能...Googleが提供しているモバイルおよびWebアプリケーションのバックエンドサービス（DWH）
※6 Amazon Athena…Redshiftと同様、AWSのサーバーレスクエリサービス
一般的にはクラウドを使用したいエンジニアが多い
吉田：私はエンジニアの採用面接に同席することもあるのですが、ウェブ系のエンジニアは多くいる一方で、Hadoopの開発・運用経験者やデータエンジニアリングの知見を持つ人は少ないのではないか、と思うことがあります。そもそもデータ基盤がオンプレであること自体、企業の中でもマイノリティである気がするので、採用にも響いてしまうと思ったり……。
福田：クラウドを使いたいエンジニアからは選ばれにくくなりますよね。Hadoopを使える界隈は日本で数百人しかいないのではないかって思うほどに少ない気がします（笑）
吉田：私たちはその少人数の取り合いをするライバルですね（笑）
福田：自社のデータ基盤をHadoopで構築しているので、私たちも採用の悩みはありますね。「採用で悩むなら、クラウドに移行した方がいいのでは？」と言われることもあるのですが、そうじゃないんだよなぁって思ったりします（苦笑）。
Hadoop自体、徐々に成熟してきていて、大きなミスは避けられるようになっていると思うので、昔よりも学び始めの難しさは軽減したと思います。全体的なシステム設計やデータ構造の把握ができるかどうかといった部分が分かる人ならば、どういうところを学べば上手に使用できるのかという感覚が分かると思うので、最初からHadoopに詳しくなくてもいいと思っています。
とはいっても、そもそもデータ分析基盤のシステム設計やデータ設計に対する視点を持つ人が少ない気がしますね。
吉田：ただ単に技術を使いこなせるだけではなくて、そのサービスの仕様を考えた上で構造をどうすればいいのか、などを考えられる人がいいですよね。それ以外の具体的な課題などは、実際に試行錯誤しながら開発・運用の経験をした方が理解しやすい部分もあると思うので。
データエンジニアリングの体系化へと踏み込む挑戦
吉田：秋葉原ラボでは、データ分析だけでなく、データエンジニアリングの体系化への取り組みもされていると伺ったのですが、具体的にはどういった取り組みですか？
福田：例えばNoSQLデータベースを使う際のスキーマ設計など、データインテンシブなアプリケーションを作る際の共通的にでてくる課題をモデリングして、要素技術として体系化していく取り組みをしていますね。それによって、データ活用の方法が多様化していっても、属人性が削減され、持続可能な開発につながると思っています。
個人的にはそこまで踏み込まないと本当の技術とは呼べないと思っているので、頑張って取り組みたいと思っています。
あとは、機械学習系のアプリケーション開発に対して、最新のアルゴリズムなどの社内外の研究成果を取り込みつつ、システムとしての品質をどう向上していくかといった課題に対して、ソフトウェア工学的なアプローチも含めて模索しています。
吉田：LINEでは、現在ETL（※）処理が二つあります。一つは簡単に分析するようなライトなもので、それは各サービスの担当者に書いてもらっています。もう一方は、安定性を求められるもので、我々が管理しています。よりクリティカルな領域でも各サービスの担当者が自由に分析・運用ができるような設計を行いたいです。
福田：データの発生源から処理の終わりまでを一貫してみれるような、発生源からいかにうまく流し込むかといった視点が重要になってくる課題ですよね。
※ETL……データウェアハウスを構築する上で、データを「Extract（抽出）」、「Transform（変換・加工）」、「Load（出力）」する一連の作業のこと。
データエンジニアだからこそ湧き上がるモチベーション
吉田：データ基盤におけるエンジニアは、サービスの売り上げとは一見離れているように感じる人が多いのではないかと感じていて、個人的には縁の下の力持ちのような存在だと思っています。
機械学習などは「レコメンドシステムを適用してこのような結果が出ました」といった具体的な分かりやすい話ができると思うのですが……。
各サービスのデータの収集や、そのデータの集計・加工を行うETL（※）をかくのが好きであるとか、技術自体が好きなエンジニアはいいと思うのですが、そうでない人は割と泥臭い仕事に対してやりがいを感じづらいこともあるのではないかと思っています。
一番土台にいるデータエンジニアが、会社貢献している実感を受けられるようにするにはどうすればいいのでしょうか？
福田：秋葉原ラボでは「データ活用ができる仕組みをつくることこそが技術である」ということへの理解があります。
「Patriot」を開発した当初は、レコメンドシステムのような機能を形成するのには時間がかかる上に何のためにデータ解析をするのかが理解されにくいと思い、まずは各サービスの担当者がKPIを定期的に把握できるようにレポーティングすることをツールの目的としていました。ですので当時は、全部のサービスのデータと集計を行うために、地道にクエリをかくような仕事も多かったので、少々つまらないと思われていたかもしれません。
しかし、その過程を踏んででも、「データ基盤を開発することが先々のサービス発展につながる」という意志のもと取り組んでいましたね。その後データの収集を主眼として「データ基盤の構築」からデータの利活用へと発展する形で分析者や機械学習エンジニアを採用していきました。
そうしてやっとサービスに適用できるレコメンドシステムや、スパムのフィルタリングなどを運用できるようになりました。秋葉原ラボができて8年になりますけど、それらの機能のすべてはデータの上で成り立っているので、当時の取り組みがあってこその成果だと思っています。
前回の記事「サービス増加に伴うカオス化を抑えるには？」で話した通り、サイバーエージェントでは秋葉原ラボとは別の組織で、データの抽出・変換・出力を行うETLの設計・実装の役割も担っているチームがあります。ただ、データ基盤からデータ収集を行う際に、エンジニアとユーザーの中間層のようなポジションがないほうがいいと思っています。
目指す状態は、ユーザーが欲しいと思っている結果を、データ構造と紐付けて思い通りに出せるようになり、データマネジメントも行われている環境です。
そのためには、データ構造のアルゴリズムの一般化の研究が今後のサービスを発展するための開発へと繋がるという共通認識がチーム内でもあり、取り組んでいる段階です。
前回の記事
LINEとサイバーエージェントは「データ基盤の設計・マネジメント、データエンジニアリング」をどうサービス発展につなげているか？
