アーカイブ動画

【DeNA】データ量はペタバイト超え。成長を続けるデータ分析基盤の歴史

株式会社ディー・エヌ・エー　データ本部　データ基盤部
データエンジニアリング第一グループ　長谷川 了示氏
※所属は3月14日時点のものです

最初に登壇した長谷川氏は、コンサルティングファーム、分析系SaaSベンダーを経て、2016年にDeNA入社。以降、一貫して全社データ分析基盤の設計・構築・運用に携わっている。長谷川氏は、DeNAのデータ分析基盤の特徴を次のように話している。

「DeNAのデータ分析基盤は勃興・浸透・拡散というフェーズを辿ってきており、データ分析基盤の形に合わせて、組織も変えてきました。それぞれのフェーズでさまざまな課題に直面しながらも、乗り越えてきた歴史があります」（長谷川氏）

続いて、それぞれのフェーズでの課題・対策について説明。 まずは勃興期以前のフェーズだ。データに基づきプロダクトを改善する文化はあったものの、データエンジニアといった専任メンバーはおらず、各領域のエンジニアが兼務するような状態だった。マーケティングチームでは、分析専用のデータマートが存在していたが、大規模なものではなかったという。

勃興期では、ゲーム事業の急成長に伴い、データ分析に基づくプロダクト改善の重要性が高まり、データ分析基盤が必要となった。その結果、ゲーム事業部内でアナリストと分析基盤エンジニアが一体となる専門組織を立ち上げ、分散処理基盤Hadoopの運用を開始する。

「"Hadoop: The Definitive Guide"の日本語初版が出版された2010年の取り組み。早い時期から取り組んでいたと思います」（長谷川氏）

データ分析基盤を利用する事業は、ゲーム事業以外にも広まっていった。ゲーム事業においても運営専門子会社が設立されるなど、次第に体制が変化。分析ニーズはさらに高まり、アナリストの生産性向上が求められるようになり、共通基盤へと拡張していく。

権限管理を導入し、すべての事業、プロダクトのデータを一つの基盤に同居させた。その上で、商用データベースの導入によりレスポンスの向上を図ったり、使い勝手のよいBIツールを内製化するなどの手も加えた。

一方で、システムの肥大化に伴う運用のつらみが顕在化していった。

「大規模分散処理システムを安定運用させるには、高い専門性を持つ人材が多数必要でした。また、一人の利用者が入れた重い処理が、最悪の場合は全利用者に影響を与えたり、個別利用者の要望に応えにくいといった課題もありました」（長谷川氏）

その他にも、利用者に自由度を与えすぎたことによるトラブル(意図せず環境を壊してしまう等)や、後から増改築したことによる技術的負債などの課題が生じていた。

このような課題解決に向けて、再び構築し直したのが以下のデータ分析基盤となる。

オンプレからクラウドに移行。Google CloudのBigQueryを中心した構成とすることで、分散処理基盤の運用はクラウドベンダーに任せることとした。

また、プロダクトごとに環境を分割すると同時に、コンテナ技術であるKubernetesを活用。利用者がコンテナ内を自由にカスタマイズできる環境を整えた。さらにはTerraformも導入しIaC環境も実現した。

データエンジニア組織は、複数のプロダクトが利用することになった浸透期から全社横断型の組織となる。加えて、ツール開発、分散処理基盤など機能ごと、エンジニアの技術専門性ごとにチームを細分化する体制となった。横断部門となったことで、さまざまな組織のつらみが生じてきたという。

「把握することが事業数に比例して増えるため、高い認知負荷が生じました。コンテキストスイッチも同様です。事業側から依頼されたことに対応するだけの関係性になりがちで、依頼内容がどう事業価値につながっていくのか、見えにくい状況でした」（長谷川氏）

そこでエンジニア組織もデータ分析基盤と同様に、再編することとした。再編においては、ソフトウェア開発で安定的に高速なデリバリーを実現するための考え方「チームトポロジー」を活用した。

イメージとしては以下スライドの右側である。ストリーム・アラインド・チーム（以下、SAT）を配置し、担当事業部を支援する。加えて、SATを支援するチームも配置した。

再編したのが半年前とのことで、良し悪しの判断はこれからだと言いながらも、半年ごとに行っている組織状況に関するアンケートでは、大幅に改善されたという結果が出ている。

長谷川氏自身の個人的な印象としても、担当アナリストや事業部メンバーとのコミュニケーションが密になり、コンテキストが把握しやすくなった。データの意思決定が活用される生の現場に触れる機会が増え、モチベーションが向上していると語った。

なお、組織変革の内容については以前開催したイベントでも紹介している。

関連記事
DeNAのデータエンジニアが語る、事業プロダクトを横断するデータドリブンな組織設計、社内データの利活用、データマネジメント

一方で、現在の組織の課題についても触れた。それは、チームトポロジー化によりチームの課題に集中しやすくなった一方で、横のつながりが希薄になりがちであること。共通利用しているツールはどのチームが担うのかなど、役割分担においては調整が必要であること。さらにはModern Data Stackなど、新しいツールや技術の活用だ。

長谷川氏は最後に、データ分析基盤とデータエンジニア組織の進化をまとめたスライドを紹介し、「コンウェイの法則は成り立っているような気がします」と、セッションを締めた。

【PayPay】データマネジメント組織立ち上げで生じた課題と解決策

PayPay株式会社　コーポレート統括本部　
システム本部データマネジメント部　三重野 嵩之氏

続いて登壇したのは、コンサルティングファームで大手SI案件の開発経験を積み、2021年6月にPayPayに入社し、現在はGoogle Cloudの運用やデータ分析基盤の構築を担当する三重野氏だ。まずは、自身が所属するPayPayのデータマネジメント部の成り立ちについて紹介した。

「データマネジメントチームが設立されたのは、2018年10月にPayPayがローンチされた2年後の2021年4月頃。その後、2022年10月にデータマネジメント部として設立されました。当初は2～3名のメンバーで細々と取り組んでいましたが、最近はメンバーも増えてきました」（三重野氏）

データに関わる部署は大きく4つに分類されており、プロダクト本部ではアプリの開発や改善、三重野氏が所属するシステム開発本部はPayPayアプリ以外のデータを担当する。例えばコールセンターのオペレーターが使うSalesforceのデータなど、さまざまなデータの取得やデータマートを構築している。

法務・リスク管理本部は、データに関するガバナンスや規定の策定、戦略系業務部署は 経営・営業・マーケティングなどの戦略を担う。

「戦略を練る際はBIツールを使って自ら分析を行ったり、SQLを直接書くこともあります。PayPayならではの強みだと思っています」（三重野氏）

スピードを持ってデータドリブンで業務を回したいという強い思いから、PayPay設立当初からエンジニア以外の社員もBigQueryの書き方やBIツールを活用するようになり、データマネジメントの知見は社内に伝播していった。結果として全社共通のデータマートが構築されるようになった。

その後データマネジメント部が発足すると、各部署で各々管理されていた状態から、Airflowなどを使い全社のデータマートの管理を担うようになり、より高度なデータ分析が行えるマネジメント体制となっていった。

PayPayのデータに関わる部署の特徴を三重野氏は、以下スライドのように3つにまとめている。まず1つ目は、PayPayにはプロダクトが1つしかないこと。2つ目は、設立当初からプロダクトのデータはBigQueryに連携されて業務を回していたことで、業務の部門でデータアナリストが活躍していたことである。

3つ目は、全社の共通マートの基礎になるものが、データマネジメントチーム発足の前に既に存在していたことが挙げられた。

三重野氏は、PayPayがデータマネジメント組織を立ち上げる際に実際に起きた課題や対応、現在の体制になるまでの経緯についても紹介した。

●課題1：各部署がどんな分析をしているかわからない

組織を立ち上げた当初は、全社共通マートを作成する際に各部署がどのような分析をしているのか分からない状態だった。三重氏は「当時は必要ないと思っていた」と、振り返る。

しかし半年ほど経つとインプット不足を感じるようになり、各部署へのヒアリングを実施していった。三重野氏は、「データマネジメント組織を立ち上げる際は、現場のヒアリングは絶対に最初に行うべきだ」とアドバイスしている。

●課題2：個人が作成したマートの利用が広まり、保守されない状態になる

個人が作成したデータマートの利用が広まったものの、作成した人が退職するとクエリが停止してしまうなど、保守されない状態になるというケースがあった。エンジニアが作成したクエリではなかったため、複雑な状態だった。そこでAirflowを使い、より使いやすい状態に改善した。

個人のマート作成が可能だったのは全社マートの原型があったからであり、今後の対応については検討を続けているという。

●課題3：データマネジメントチームに小さな問い合わせが増える

業務部署から、データマネジメントチームに要望のヒアリングや問い合わせ対応が増えてきたことで、対応業務に多くの時間を要するようになった。キャリア的な観点から工数を抑える必要性が出てきた。

対応策は2つ。1つは、Slack上に業務部門同士をつなぐチャンネルを作成し、お互いに情報交換できる環境を構築した。もう1つはデータマネジメントチームでBIツールを構築して渡すのではなく、業務部門の中にも構築できる人材を1人立てて、その担当者を育成するフローに変えた。

●課題4：チームが本来やるべきタスクが進まない

最後は、外部からの依頼や急に差し込まれる依頼も多くなり、データマネジメント組織として本来やるべきタスクが進まないという課題だ。

対応としては、月に一度の頻度でロードマップを見直すこと。急な差し込みタスクに応じられるように、業務の30％ほどは余裕を持ってタスクを組むようにした。結果、「やるべきタスクに時間を取れるようになった」と、三重野氏は成果を語っている。

【マネーフォワード】壁を乗り越え、組織とともに成長するデータマネジメント

株式会社マネーフォワード
CTO室　分析基盤部　太田 泰弘氏

「マネーフォワード ME」「マネーフォワード クラウド」など、個人・法人向けに数多くの金融系ウェブサービスを提供するマネーフォワード。登壇した太田泰弘氏は、データ分析チームの立ち上げメンバーとして2019年に入社以降、全社横断のデータエンジニアリング、データマネジメント全般の業務に携わっている。

太田氏は、まずはデータ分析基盤の変遷から紹介した。以前から有志によるBigQueryを活用したデータ分析に取り組む動きはあったが、2019年に正式にデータ分析の専門チーム「分析推進室」が立ち上がる。以降、一貫してデータ分析基盤の新規開発、保守運用、改善などを担っていく。

設立当初はアナリストやデータエンジニアなど3名からのスタート。管理会計周りを分析し基盤に寄せ、属人化を排除し自動化する取り組みを行っていった。徐々に、セールスやマーケティングといった領域のデータ分析業務も担うようになり、ビジネス領域へのデータ分析の浸透も実現していく。

2021年には、基盤改善のアジリティを高め、ML/AI領域にも対応するといった目的から、データ分析基盤部が立ち上がる。レガシーとなっていたデータベースを、BigQueryにリプレースする取り組みに着手した。

現在はリプレースされたデータ分析基盤のパイプラインに対する改善など、さまざまなタスクに取り組んでいる。

続いて太田氏は、各フェーズで立ちはだかった「壁」ならびに対応を紹介した。

まずは立ち上げ黎明期である。有志がそれぞれの事業領域のためにデータ分析を行っていたため、中央集権的な管理状態ではなく、サイロ化したデータ分析基盤が複数存在するような状態だった。

そこで改善策として、管理主体を明確にした中央集権的なデータマネジメントに 移行することを決め、積極的にデータ構造の変更などに着手していく。

具体的には、ETLシステムについては既存の構成を引き継ぐが、統一のデータレイクを用意するなどしてサイロ化を撤廃する。ドラスティックに変更を行っていったという。

続いては、分析推進室が立ち上がり、管理会計の属人化排除や自動化が進んだフェーズで起きた「データ民主化の壁」だ。管理会計の自動化が進み、KPI管理などにも使えることが分かると、事業部サイドから主体的に分析にコミットするメンバーが増加した。

一方で、各プロダクト（事業部）で分析を推進するためには、データアナリストがこれらの幅広いドメイン知識を取り入れる必要が生じた。当時は管理会計の集計ロジックも複雑化していったため、分析チームの工数も増えていた。そこにも対策を打っていく。

前者においては、データ分析チームのメンバーを事業部に送り込み、兼務を行いながらナレッジトランスファーを実施し、自走化を目指した。後者においては、管理会計とKPI管理を一体化して管理できる状態を目指した。

データ分析基盤サイドにおいても、プロダクトのユーザーや開発プロダクトの増加によりデータ量が激増したり、依頼数の増加に伴い人的リソースの枯渇、管理権限の煩雑化などの課題が生じていた。

オンプレETLサーバーの強化やHourlyでの転送挿入などの対策に加え、データ分析が行える非エンジニアを増やすために、GitHubの使い方をレクチャーするような取り組みも行ったという。太田氏は次のように当時を振り返った。

「データエンジニアは単にデータの実装を担うだけでなく、転送の妥当性やセキュリティ観点からの判断なども行う。つまり、組織内のデータの品質や利用意味に責任を持つ代表者。データスチュワードへの転換期になったと思っています」（太田氏）

続いて語られたのは、「データ組織分離」の壁である。データ分析基盤部設立の目的はレガシーデータベースをリプレースとML/AI領域に対応することだったが、データベースが寿命を迎えるため、緊急で行う必要があった。そのため同業務に集中した。

加えて後者の目的を実現するために、trocco®など各種ツールを導入し、エンジニアの工数を減らす取り組みも行った。データエンジニアが増えた現在でも同取り組みは継続しており、「データエンジニアが本質的な業務に向き合う屋台骨として支えてくれている」と、太田氏は話した。

しかし、緊急以外の依頼は分析推進室に担ってもらっていた結果、データ分析基盤部に社内利用者の声が届きづらくなるという課題が生じた。まさしく、データ組織分離の壁である。そこで相談窓口を一元化した。一方で、データ組織の構造が分かりづらい面もあり、見直しも検討しているという。

数々の取り組みによって、多くの課題は解決していった。既存ETLが動いているなどの課題は残っていたが、利用者にクエリの書き換えの打診を続けながら定点観測を行った。結果として半年ほどかけて切り替えは行われたが、同時に新たな課題が生じた。データカタログの要望だ。

そこで、yamlベースでメタデータを管理する仕組みを構築した。さらにはデータカタログのWebサイトも構築。分析利用ではなく、単にデータを確認したい利用者に行っていた権限付与の管理業務も軽減した。

太田氏は最後に、データエンジニアの本質はデータエンジニアマネジメントの重要性に気づくことであると見解を語り、セッションをまとめた。

「マネージドなETLや、データマネジメントを支えてくれるツールを導入するなど、少人数でも集中すべきポイントに向き合うことで、高い費用対効果を出せると思います。データ分析基盤の大幅刷新を繰り返すと、分析文化をストップさせる要因にもなるため、常に利用者からのフィードバックをもらい、アジャイルに改修やエンハンスメントを行うことが重要です」（太田氏）

primeNumberが提供するデータ分析基盤の総合支援サービスtrocco®

事前の申込数744名、当日の参加者も400名超えという注目が集まった本イベントを主催したのは、「あらゆるデータを、ビジネスの力に変える」というビジョンを掲げ、さまざまな企業にコンサルティングやエンジニアリングサービスといった、データマネジメントの支援を行っているprimeNumberだ。

イベントは、primeNumberの代表的なサービスでもあるtrocco®のプロダクトマネジメントに従事する佐々木樹哉氏がファシリテーターを務めた。そしてセッション内でも挙がったtrocco®について紹介を行った。

データをビジネスに活用するためには、上記スライドで示したさまざまなステップがある。trocco®はその中のデータ統合領域を自動化。データエンジニアリングにかかる工数を削減するSaaSだ。

Googleなど広告系データ、Salesforceなどクラウドアプリケーションのデータ、その他さまざまなデータをDWHに転送し、統合することができる。

また、ワークフローによるジョブ管理機能やメタデータ管理機能、データモデリングのための機能などを通じて、あらゆるデータの連携・整備・運用を効率化し、データマネジメントに貢献する。無料で利用できるのフリープランもある。

【Q＆A】参加者からの質問に登壇者が回答

イベントを聴講した400名を超える参加者からは、多数の質問が寄せられた。いくつか抜粋して紹介したい。

Q．データの品質管理に対する取り組みは？

長谷川：ライブストリーミングに関しては毎朝のバッチ処理の後、PRIMARY KEY違反がないか、NULLのカラム件数はどれくらいあるか、データ間の整合性がとれているかなどを確認。特に、お金が絡んでくるデータに関しては管理会計用に集計している数字とも突き合わせています。これらの取り組みはLookerで行っており、異常があったらSlackに通知するようになっています。

三重野：経営のKPIなど重要なレポートに対して、NULLやデータが正しいかどうかチェックを行っています。いずれはこれらのチェックを利用者側がJSONで定義し、システムに実装。自動でチェックできる体制を整えたいと考えています。

太田：Cloud DLPを用いてデータのセンシティブチェックを行ったり、持ち込みのレビュー体制と合わせて二重にチェックしたり、ETLではレコード数やラストアップデートタイムなどを計測。元データと照らし合わせてズレがないかどうかなど確認しています。またdbtを活用し日々のデータマート更新の際、クオリティを担保するために様々なテストを走らせる取り組みもしています。

Q．Modern Data Stackで注目しているツールや分野について

三重野：FivetranはSalesforceなどのSaaSとの接続で使っています。dbtは使っていませんが、いずれは導入したいと考えています。ただAirflowはすでに導入しているので、両者の切り分けを整理しながら進めたいと考えています。

長谷川：dbtには注目していて、同じようにAirflowやDataform との棲み分けを考えています。弊社ではアナリストがDigdagというツールを使い、データマートを作成したり、DWHを整えています。エンジニア以外でもWebベースでいろいろと作業できるツールは、活用していきたいと思っています。

太田：コミュニティを通じて定点観測をして、常にどういったプロダクトやライブラリが登場しているかを、チェックしています。個人的な検証になりますが、データクオリティのモニタリングツールに注目しています。特にデータのパイプライン、パイプライダーのようなライブラリを組み込めないかと検討しています。

Q．セキュリティ面の対応について

長谷川：社内基盤の仕組み、社内の情シスであるIT戦略部が導入している、Google Workspaceを活用しています。組織を異動したら自動で棚卸しをしてくれますし、利用者が退職したら自動でアカウントが無効になります。

三重野：PayPayでもGoogle Workspaceを活用しています。一方で、手動での管理も行っています。BigQueryのデータセット、スキーマ単位でオーナーを決めており、承認フローが必要です。カラム単位まで権限を設定すると運用が大変になると考え、現状ではこの体制としています。

太田：センシティブなデータを扱う基盤は、持ち出しができないVDI（Virtual Desktop Infrastructure）に閉じ込めるような対応をしています。一方で、そこまでセンシティブなデータを扱わない環境はカジュアル基盤と呼び、Google Workspaceで管理しています。

いずれはカラムレベルで権限付与が行えるGCPのIAM Conditionsのような機能を使い、セキュリティレベルで分離した基盤ではなく、1つの基盤で柔軟に対応できる環境を目指していきたいと考えています。

株式会社primeNumber
https://primenumber.co.jp/

株式会社primeNumberの採用情報
https://primenumber.co.jp/recruit/

TROCCO®お問い合わせ先
https://trocco.io/inquiry/new