DeNAがデータプラットフォームで直面した課題と克服の取り組み
はじめに
こんにちは。この記事はDeNAの小口（Rikiya Oguchi）と長谷川（Ryoji Hasegawa）がお届けします。
小口はゲーム事業部の分析部データエンジニアリンググループの所属で、長谷川は全社共通部門である分析推進部の所属です。ゲーム事業部と全社部門で所属は違いますが、近しいミッションのもと、普段から密に連携して仕事をしています。
DeNAでは現在、データプラットフォームの刷新を進めています。この記事では、そのプロジェクトについて、以下の流れでご紹介します。
- 現行データプラットフォームの背景と概要
- データプラットフォーム構築後の環境変化
- 現行データプラットフォームが抱える課題
- 現行組織が抱える課題
- データプラットフォームの刷新
- 刷新後のシステム構成
- 組織体制の刷新
我々と同じようにデータプラットフォームの構築・運用に携わっている方々や、データプラットフォームを利用されている方々、特に、現状のデータプラットフォームで課題を抱えており、刷新を検討されている方々の参考になれば幸いです。
現行データプラットフォームの背景と概要
DeNAが現行データプラットフォームの整備を始めたのは、2010年です。怪盗ロワイヤルに代表されるモバイルゲームの大ヒットを背景に、ユーザ行動分析のような、それまでになかった踏み込んだ分析ニーズが発生しました。膨大なデータを分析するために、Hadoopを導入し、Hadoopにデータを収集するためのデータ収集基盤を構築しました。更に、分析業務の高速化、効率化を実現するために、商用の並列分散データベースVerticaを2013年に導入しました。以下が現行データプラットフォームの構成です。
現行データプラットフォームの特徴として、以下の点が挙げられます。
- 大量データの分析基盤
- オンプレミス
- 高いコスト効率
- 単一のクラスタ
大量データの分析基盤
サービスが生成する分析ログやデータベーススナップショットを、早いものは15分程度の遅延で、遅くともだいたい翌朝には分析可能な状態にしています。ユーザ理解を深めるために細かな行動ログまで蓄積していった結果、現在では2PBを超えるデータが蓄積されています。
オンプレミス/高いコスト効率
DeNAには、カリカリにチューニングしたインフラを徹底的に使い倒すことで高いコスト効率を実現してきた文化と技術があります。データプラットフォームもその自社管理のインフラ上に構築しました。
単一のクラスタ
HadoopやVerticaの基盤を立ち上げた当初、分析対象はモバゲープラットフォームと、モバゲー上で展開されるソーシャルゲームでした。そのため、一つのHadoopクラスタと一つのVerticaクラスタ上で、あらゆるデータを横断で分析できる基盤を提供していました。
データプラットフォーム構築後の環境変化
こうしてできたデータプラットフォームは、DeNAの分析ニーズを満たし、的確な意思決定を支えてきました。一方、時間が経つにつれて、事業の要件や技術動向に変化が現れました。
事業・組織構造の多様化
DeNAはこの10年間で、Webからリアル、エンタメから社会課題解決に渡る様々な事業にチャレンジしてきました。それに伴い、データプラットフォームがサポートする対象事業も広がっていきました。また、事業展開の形も、DeNA本体で展開するケースだけでなく、子会社化して展開したり、アライアンスを組んだり、M&Aを行ったりするケースが増えてきました。
データプラットフォームの一部として、”Argus”という内製BIツールを提供しているのですが、このArgusのMonthly Active Userが多い月で千人近くに達しており、これはDeNAグループ全社員の4割強に当たります。この数字からも、利用部門の広がりを感じていただけるのではないかと思います。
データ利用方法・ツールの多様化
世の中の分析ツールの進化に伴い、新しいツールを取り入れたいというニーズが出てきました。また、DeNAでは以前から機械学習やAIの活用を進めていましたが、活用の裾野が広がり、データプラットフォームのデータを使って手早く試したいというニーズも出てきました。
BigQueryをはじめとするクラウドサービスの台頭
2015年頃からBigQueryを使い始め、今ではメインで利用しています。BigQueryの優位性は、チューニングの手間をかけずとも一定の性能を発揮してくれ、なおかつコストパフォーマンスも高い点です。
オンプレミスの基盤は、しっかりチューンナップし、運用のノウハウを蓄積すれば高い性能を発揮するのですが、DeNAではチューニングの徹底が難しい事情がありました。管理者を介さずにデータアナリスト自身が様々なタスクを実行できる自由度を与えていたためです。多くの利用者が複雑な分析クエリをアドホックに実行する環境であり、事前にクエリをチューニングするということが難しい状況でした。
また、分析以外の領域では、DeNAはより早い時期からクラウドサービスを利用してきました。多様な機能やインフラを手早く立ち上げ、必要な間だけ利用することができるクラウドサービスの利点を理解し、オンプレミスと併用してきました。
現行データプラットフォームが抱える課題
データプラットフォームを取り巻く環境の変化と、年月の積み重ねにより、次第に以下のような課題が目立つようになりました。
事業の多様化・組織構造の変化への対応に多大な労力がかかる
モバゲー/ゲーム以外の事業や子会社に利用が広がると、当然、「担当外の事業のデータは参照できないようにする」といった権限管理が必要となります。当初の要件には無かった権限管理を後付けしたことで、運用が複雑化する要因となってしまいました。
また、「事業を譲渡するので、その事業のインフラをDeNA社内から切り離す必要がある。譲渡は来月末までに完了する予定。」といったケースも発生しました。オンプレミスの単一クラスタで環境を構築していたため、その事業用にゼロから環境を構築しなおす必要がありました。
新技術・新ツール導入に柔軟に対応できない
様々な事業がオンプレミスの同一環境に同居しているため、OS、M/Wのバージョンやマシンスペックを個別要件に合わせるのが難しく、それが障害となって新しいツールを取り入れるのが難しいケースが生じていました。個別の事業・要件毎に専用のサーバを用意すれば理論的は対応できますが、構築のリードタイムと運用コストを考慮すると、そういった対処は安易にはできませんでした。
環境・データのガバナンス不在
ガイドラインやベストプラクティスを確立する前から利用者（必ずしもエンジニアに限らない）に高い自由度を与えてしまったため、混乱が生じるようになりました。例えば、以下のような、ちょっとお恥ずかしい事例が発生していました。
- 管理者側でpythonをバージョンアップしようとして失敗。調べてみると、いつの間にか利用者により環境変数の設定（.bashrc）が変更されていた。
- 生データを集計してDWH・データマートを生成するデータフローが、一部、複雑怪奇化し、依存関係の把握が困難となっていた。その結果、変更時に思わぬ箇所で副作用が発生し、障害につながることもあった。
環境のレガシー化
大規模データを多くの利用者で分析できるようにするために、もともとデータプラットフォームは複雑な仕組みにならざるを得ませんでした。そこに加え、より厳格な権限管理等の要件が後から追加されたことで、より一層複雑化してしまいました。年月が経ち、人員が入れ替わっていく中で、「ここの詳細な仕様はコードを読まなければ誰も分からない」、「この設定を変更するとどういう影響が出るか分からない」というケースが生じてしまいました。
また、早期にHadoopを取り入れていたが故に、技術の移り変わりの影響を受けてしまいました。例えば、古くからHadoopを利用していたサービスでは、集計スクリプトの実装にPigを利用していたのですが、今となってはPigに習熟したエンジニアは社内では希少な存在となってしまいました。
現行組織が抱える課題
課題があるのはデータプラットフォームだけではありません。データプラットフォームを運用・利用する組織にも課題が感じられるようになりました。分析を支える組織が大きくなり、分業化が進むにつれて、コミュニケーションコストが目立ち始めたのです。
現状では、分析に関連する業務を以下のロールで分業しています。
- データアナリスト
- データエンジニア
- 分析基盤エンジニア
- インフラエンジニア
データプラットフォームが立ち上がった当初は、分析基盤エンジニアとデータアナリストが一つの部署に所属していました。しかし、事業の多様化に伴い、分析基盤エンジニアとデータアナリストが別組織に分化していきました。分析基盤エンジニアが全社共通部門の所属となる一方で、データアナリストは各事業部の中で活動を続けました。システム基盤は全社で共通化したほうが効率的である一方、データアナリストはドメイン知識と事業へのコミットが必須であるため、このような体制へ移行しました。ただ、この体制では以下のような課題が生じました。
- 分析基盤エンジニアが、分析業務の実情を把握する機会が少なくなった
データアナリストのニーズを把握し、最適な分析環境を提供するためのハードルが上がったように思います。また、分析がどのように事業貢献しているか見えづらくなったことが、少なからず分析基盤エンジニアのモチベーションにもマイナスの影響を与えていたと思います。 - データアナリスト業務におけるエンジニアリング寄りの業務のサポートが手薄になってしまった
分析基盤とその利用方法については分析基盤エンジニアがサポートしていたものの、データアナリストが行う業務の中にも、データ設計や集計スクリプトの作成等、エンジニアリングのスキルが必要な部分があり、業務品質のバラツキが目立つようになりました。これが、先に述べたデータガバナンス不在にもつながっていると考えています。
ゲーム事業部では、データアナリストの組織規模が大きいため、特に後者の課題が顕著でした。そこで事業部独自に「データエンジニアリンググループ」を立ち上げ、データアナリストをサポートしています。
また、インフラについては、ゲームやモバゲーのインフラも担当しているインフラ専門部隊の力を借りており、ハードウェアやOS・ネットワークレイヤと、一部ミドルウェアの構築・運用を担ってもらっています。しかし、データプラットフォームが複雑化するに伴い、分析基盤エンジニアとインフラエンジニアの連携の難易度が上がっていきました。両者間の情報共有不足が原因で、システム障害が発生するといったケースも起きてしまいました。
データプラットフォームの刷新
これらの課題を根本解決するために、我々はデータプラットフォームを刷新する決断をしました。その際、刷新の方針を以下のように定めました。
- パブリッククラウドへ全面移行する
- サービス毎に環境を分離する
「事業別にアクセス権限を分離したい。」「各事業内では環境のカスタマイズを行えるようにしたい」といった要件を満たすには、事業毎に専用の環境を用意することが望ましいと考えました。事業毎の専用環境をスピーディに構築するには、クラウド環境が必須です。更に、アライアンスやM&Aで会社の枠を超えて協働することを考えると、パブリッククラウドが最も適した選択肢だと考えました。これにより、「事業の多様化・組織構造の変化への対応に多大な労力がかかる」「新技術・新ツール導入に柔軟に対応できない」という課題を解決できると考えています。
クラウド移行するとして、オンプレミスの仕組みをそのままクラウド上に再現しても全ての課題を解決できません。現状の仕組みをベースにすると「環境・データのガバナンス不在」や「環境のレガシー化」といった課題が残り続ける可能性が高いのです。そこで、今使える技術・ツールを積極的に採用し、ゼロベースで再設計することにしました。
分析やシステムを支えるツールは次々と有用なものが生み出され、発展を続けています。特に、クラウドのマネージドサービスを活用すれば、複雑な仕組みの構築・運用をクラウド事業者に担保してもらい、我々から見える仕組みをシンプル化することができます。これにより、「環境のレガシー化」を改善できると考えています。
また、ガバナンスを効かせる上でも新しい技術・ツールは有効だと考えています。
例えば、コンテナ技術を利用し、利用者側向けに個別のコンテナの中身をカスタマイズしつつ、カスタマイズの影響をコンテナ内に閉じ込めることができます。（参考資料: 自由と統制のバランス 分析基盤のアプローチ）
もう一つの例はクラウド基盤の監査ログです。例えばBigQueryでは、クエリ実行等の操作を行う度に自動的に監査ログが記録され、それをBigQueryのテーブルとして参照することができます。こういったログを活用し、利用状況やデータの依存関係の可視化を図ろうとしています。（参考資料: BigQuery を使い倒せ！ DeNA データエンジニアの取り組み事例）
もちろん、クラウドや新しいツールを導入するだけでは不十分です。使い方の工夫、管理ツールの開発、適切な利用ルールの設計と徹底、ベストプラクティスの蓄積・共有等、様々な面で刷新を進めようとしています。
ちなみに、刷新後のデータプラットフォームと、そこに至るまでの移行プロジェクトを“polymorph”というコードネームで呼んでいます。polymorphは日本語では「多形」と訳され、wikipediaでは以下のように解説されています。
1. 化学の用語で、同じ組成の化学物質に、多くの結晶形が存在すること。
2. 生物学の用語で、同じ種の生物に、多くの形態、形質の個体が存在すること。アリやハチなどに見られる。
「様々な事業毎に、ベースは共通化しつつも柔軟にカスタマイズ可能な環境を提供する」というビジョンにちなんで名付けました。
刷新後のシステム構成
具体的なシステム構成は以下の通りです。既に一部のサービスのデータプラットフォームはこの構成で動いており、残りのサービスについても、現在、移行を推進しているところです。
BigQueryを中心にGCP上に構築
既に述べた通り、2015年頃からBiqQueryを利用していました。BiqQueryがDeNAの分析要件を十分に満たしており、更に運用面やコスト面で他のソリューションに対する優位性があることが確認できたので、これまでHadoopやVerticaで処理していた部分も全てBiqQueryに移行することにしました。そして、データベース以外のコンポーネントもGCP上に構築する方針にしました。「サービス毎に環境を分離する」という方針のもと、分析対象のサービス毎にGCPプロジェクトを作成し、その中に専用のデータプラットフォームを構築しています。
データレイクーGoogle Cloud Storage
データレイクにはGoogle Cloud Storage（GCS）を利用しています。現行のデータプラットフォームでは、Webサーバ、ストリーム処理基盤、KVS等を組み合わせ、大量のデータ受信に耐えられるログ収集基盤を構築・運用していますが、これをGCSというマネージドサービスに置き換えることで、ログ収集・蓄積の仕組みを大幅にシンプル化し、運用の負担を下げようとしています。
コンピューティング基盤ーGoogle Kubernetes Engine
コンピューティングの基盤としては、Google Kubernetes Engine（GKE）を利用しています。GKEを使うことで、インフラのメンテナンス等の作業を最小化できます。また、オートスケールを利用することで、「使いたい時に使いたい分だけ利用する」仕組みを実現しつつ、プロビジョニングの省力化を図っています。
バッチ処理ワークフローエンジンーDigdag
集計等のバッチ処理の管理には、これまではJenkinsを利用していましたが、polymorphではDigdagをGKE上で稼働させて利用しています。Jenkinsはとても汎用的なツールではありますが、元々CIツールであり、バッチジョブ管理の機能は十分とは言えませんでした。その点、Digdagはまさに集計等のデータ処理のためのワークフローエンジンなので、必要な機能が揃っています。また、ワークフローをyamlファイルで定義できるので、github flowのような開発フローを適用し、ガバナンスを強化することが可能です。
BIツールーLooker
BIツールは、先にも触れたArgusという内製ツールを全社的に利用しているのですが、最近、Lookerの導入を始めました。内製ツールは、Redashのようにレポート毎にSQLを直接記述する方式だったのですが、Lookerは、LookMLというDSLでデータを定義することにより、SQLを自動生成する仕組みを採用しています。LookMLでデータ定義を共有することにより、「レポート毎に指標の定義が違う」といった問題を防ぐことができ、データガバナンスを強化することができます。また、LookMLさえ作ってしまえば、データやSQLに対する深い知識がなくともレポート作成ができる点（データの民主化）や、LookML・レポート定義のgithubによる管理をサポートしており、github flowのような開発フローを導入できる点も利点です。
組織体制の刷新
データプラットフォームの刷新とともに、組織体制の見直しも行っています。システムを大幅に簡素化し、更にマネージドサービス等を活用することで、運用の難易度と負担を下げ、細かな分業を不要にしようと考えています。
まずは、データエンジニアと分析基盤エンジニアの垣根をなくし、基盤からデータアナリストのサポートまで、ワンチームで幅広く対応できる体制を目指しています。分析基盤エンジニアとデータエンジニアの融合は既に始めており、この記事が分析基盤エンジニアである長谷川とデータエンジニアである小口の共著になっているのもその一環です。
また、クラウドネイティブなデータプラットフォームに移行することで、インフラエンジニアへの依存を最小限にしようとしています。Hadoop運用では、数百台のサーバを管理しなければならないので、インフラエンジニアのノウハウに頼らざるをませんが、BigQueryのようなマネージドサービスを利用すれば、そもそもインフラの管理が不要となります。
まとめ
DeNAは、ゲーム事業の急成長を背景に、大規模なデータプラットフォームの運用を開始しました。データプラットフォームは的確な意思決定を支えてきたものの、時が経ち、事業や技術の環境が変化するにつれて、「事業の多様化・組織構造の変化への対応に多大な労力がかかる」「新技術・新ツール導入に柔軟に対応できない」「環境・データのガバナンス不在」「環境のレガシー化」「組織の課題」といった課題をかかえるようになっていきました。
そこで、「パブリッククラウドを活用し、事業毎に専用の環境を構築する」というアプローチで解決に取り組んでいます。
以上、駆け足で概要的な話になってしまいましたが、今後はBigQuery、GKE、Digdag、Lookerに限らず具体的な話をカジュアルに発信していくので引き続きウォッチしていただけると幸いです！
