はじめに
はじめまして、4/1からデータチームでデータエンジニアとして働いている @shoso です。
突然ですが、みなさんデータ基盤って開発したことありますか？
私はheyに来るまでなかったのですが、チームの経験あるメンバーと毎日話しながら（助けてもらいながら）開発する中でようやく少し分かって来たような気がします。
（覚えることが大量にあり大変とても楽しいです！）
今回は、データ基盤開発経験のある方はもちろん、普段サービス開発など他の開発をメインでされている方にも伝わる形で、heyの統合データ基盤と今後やっていきたいことについてご紹介できればと思います。
これまでにも、統合データ基盤のいくつかのトピックについて記事を公開していますが、この記事では統合データ基盤そのものについてより詳細が伝われば幸いです。
統合データ基盤ってなに
一言でいうと、社内に蓄積するあらゆるデータをスムーズ・横断的に活用できる基盤 になります。
データの種類
heyの社内には様々な種類のデータが存在します。
まず、heyではEC/決済/予約/レジの４サービスを展開していますが、それらの各DBに蓄積されるデータがあります。
特にEC/決済/予約は元々別会社として長年開発・運用してきたサービスなので、それらのテーブルを合わせるとかなりの数になります。
また、サービスが共通利用するプラットフォームであるID基盤のDBデータ、Google Analytics等の各種SaaSで収集した各サービスにおけるトラッキングデータも存在します。
さらに、サービスの利用を検討していただいている方々の問い合わせデータであったり、オーナーさんのサポート状況なども、セールス・カスタマーサクセス・サポート部門が利用する各種ツールに蓄積されています。
データ活用の種類
これも色々なものが存在します。
- 経営・事業上の意思決定に活用するための分析
- 各種マーケティング活動に関する分析
- 上記のセールス・カスタマーサクセス・サポート部門などに関して
- 目標に対する進捗などの各種指標のモニタリング
- より良いご提案やサービスを提供するためのオーナーさん・過去データの分析
- プロダクト開発において開発方針を決めるための、サービス機能の利用頻度や使われ方に関する分析
- 不正な利用などの事業リスクを検知・防止するための分析
- 経理に必要な各種集計
などが挙げられます。
具体的なところだと、
オーナーさんが何かに迷った時にカスタマーズ部門のメンバーと接点を持つことになります。そこですぐオーナーさんのステータスがわかって連携されていたら、もっといいサービスができる ...
これまでにどんなことに困っていて、どんなコミュニケーションをしてきて、どういう活動をしているかなどがわかれば、オーナーさんと一対一のコミュニケーションができますから。
(hey note: heyが総力をあげて内製する基幹システム「ファミトラOS」について──道廣敬典・藤村大介対談 より)
といったことがやりたいことになります。
上記はあくまで例ですが、社内のほとんど全ての部門の業務にデータ活用の余地があるため、用途は非常に多岐に渡るものになっています。
また、「こういう場合に○○のデータを使うと良いのではないか？」というようなアイデアも日々発案されており、開拓できてない用途もまだまだ数多くありそうです。
こういった要望に対し、基本的には全社員が簡単にデータを活用できる状態を目指しています。
（機械学習や高度な統計などの専門的な分析が必要なケースでは、同じデータチームに所属するアナリストが担当し他チームに結果を提供することが多いです）
そのため、基盤としては以下のようなことが求められてきます。
- データ提供元の一元化
- 「ここを見れば全てのデータがある」という状態に近づける
- 例えば、複数サービスを利用するオーナーさんのサービス毎の利用状況など、複数データソースにまたがる解析が簡単にできるようにする
- 操作・分析手法などの共通化
統合データ基盤の構成
上記のコンセプトを踏まえて、現状の統合データ基盤の構成は以下のようになっています。
以下、主要なコンポーネントについて説明します。
BigQuery
データレイク、データウェアハウス、データマートと広い用途に利用しています。
様々なデータソースから抽出されたデータがここに集約されることにより、（BigQueryで利用できる）SQLさえ扱えれば全データを活用することが可能となっています。
選定理由としては、広く使われており経験者やナレッジが世の中的に多いこと、現状の分析利用頻度を踏まえるとコスト面や処理速度の面でバランスが取れているということがあります。
また、heyではデータパイプラインモデルとしてELT（Extract, Load, Transform）を採用しており、Transform部分をほぼ全てBigQuery上で実行するようにしています。
これによって、データエンジニア以外のメンバーでもSQLが書ければ変換処理を書くことが可能であったり（人数の比較的少ないデータチームでも柔軟な対応が可能に）、ETLモデルにおけるTransform用の実行環境（一般的にDWHの外に構築する）といったもの別途構築・運用する必要がない、というメリットがあります。
BigQueryの中に存在する各種データセットには、比較的社内公開しやすいものから個人情報を含むセンシティブなものまであるため、データセット毎にCloud IAMで適切に権限管理することによりセキュリティを担保しています。
データチームのアナリストが行う複雑な分析もBigQuery上でやることが多いので、便利に使えるような工夫を色々行っています。 tech.hey.jp
GKE (Google Kubernetes Engine)
統合データ基盤上で稼働させるサービスの実行環境として利用しています。
Kubernetesが今後さらに広く使われていきそうな技術であること、基盤開発に関わるメンバーに経験者もいたことから採用されています。
後述のMetabase、Digdag、各種データアプリケーション等はこの上で稼働させています。
最近、運用コストを下げるためにAutopilotも導入しています。 tech.hey.jp
Metabase
BIツールとして利用しています。
社内の様々なダッシュボード作成・共有に利用していますが、シンプルで使いやすいUI・豊富なグラフ描画機能が特徴です。
SQLを使っての複雑な分析はもちろん、簡単な解析であればUI操作のみでも可能なため、社内でのデータ活用の文化をより浸透させようとしている現段階において適したツールと考えています。
データはBigQueryに集約されているため、MetabaseはBigQueryのみを参照しにいく形になります。
セキュリティ面ではCloud IAPを用いて社員のみがアクセスできるように制限をかけています。
Digdag
ELT処理などで、
- 複数のバッチ処理をシーケンシャルに実行する
- 特定ステップのみを並列で実行する
- それらのジョブを決まった時間にキックする
等の要件があり、そのようなワークフローを実行するエンジンとして利用しています。
データの反映頻度の変更要件に柔軟に対応できるよう、ELT処理のタイミングは全てDigdag上でコントロールする方針で開発をしています。
元々、この統合データ基盤ができる以前からEC単体向けの旧データ基盤があり、そこでのワークフローエンジンとしても活用されていました。
ECに関しては旧データ基盤上のワークフローを移行しているところですが、基盤開発を進める中で課題がいくつか見えてきているので、近々新しい技術の選定も視野に入れた再検討を行う予定です。
データアプリケーション
BigQuery上のデータを取得し各種処理を行うアプリケーションを、GKEにデプロイして稼働させています。
現状は機械学習ベースの不正検知アプリケーション(Python)、社内向けにリッチなサマリのSlack通知を行うアプリケーションのみですが、今後用途に応じてガンガン増やしていく予定です。
同じGCP内なので当たり前と言えば当たり前ですが、データアプリケーションからのBigQueryデータ取得はクラウド内で閉じて行われます。
設計の選択肢として各種アプリをAWS側で動かすことも考えられたのですが、GCP側で動かすとセキュリティ・パフォーマンス・ネットワーク料金の面でメリットがあって良いなと思っています。
各データソースの抽出(Extract)部
上の図のAWSやSaaSの箇所になりますが、データソース毎に実装が異なります。
一つのパターンとしては、Embulkを使って直接データソースにアクセスし、GCS経由でBigQueryにロードさせるものがあります。
セキュリティの観点でGCP環境から直接アクセスできないサービスDBに関しては、サービス側のAWS環境にデータ抽出を担うECSバッチを配置し、S3を挟んで連携することが多いです。
サービス側のDBについては複数存在したり様々な種類のものがあるため、各々に対応した抽出バッチを実装する必要があります。
したがって、上の図で書いているよりも実際には多くのワークフローが稼働しています。
Google Spreadsheetに保存されたデータをBigQuery上で扱いたいケースもあり、こちらはメンバーが実装したGoogle Apps Script(GAS)ツールを利用して実現しています。
統合データ基盤の今後の展望
統合データ基盤の現状については前述の通りなのですが、まだまだ提供できてない機能や改善余地が山のようにあります。
未連携データの連携を進める
冒頭で挙げたデータの中で、まだ一部のデータしか連携できていないものや、最低限の分析ができるようにアドホックな連携方法をとっているものがあり、整備していく必要があります。
また、特にサービスDBについてはサービス側の機能拡張によってテーブルが増えることも多々あるので、テーブル増加に効率良く対応していくことも求められます。
前半で触れた基幹システムのファミトラOSとも、データ連携することになると思います。
さらに、データの連携頻度も一部データを除いては24時間に1回と低頻度に留まっているため、今後様々な用途を開拓する意味でも頻度を上げていく開発が必要となってきます。
インフラの最適化
ETL処理や、データ連携が完了した直後に実行したいバッチ処理など、連携データの種類・データアプリケーションの増加によってDigdagが管理するワークフローがどんどん増えてきています。
これらのステップの一部は、常時稼働のDigdagインスタンス内で実行しているのですが、必要となるシステムリソースは時間によって波があるため、Kubernetesの機能を生かして動的にプロビジョニングを行う・スケーリングさせられるような設計にしていくのが望ましいと考えています。
データカタログの整備
データ利用者の立場だと、どういうデータが存在するのか・そのデータの定義・どういう条件でどういうデータが入るのか、 といった情報が一元化されていると理想的なのですが、現状は一部の主要なデータに限ってようやくまとまりつつあるという状況です。
特にサービスDBのデータがメインになりますが、各サービスの開発エンジニアと連携をとったり、実際にサービス側のソースコードを読みながら整備していく必要があります。
個人的にはこのあたりはサービス開発経験が活かしやすいかなと思っています。
業務ユースケースでのデータ連携支援
現状、統合データ基盤の用途は分析が中心ですが、セールス・カスタマーサクセス・サポート部門等の日常業務においてもデータ活用を推進する方向です。
各チームの要望や業務フローを理解しつつ、データ基盤としてどういう情報が出せるのか・データの連携方法の議論や、データの抽出部分の実装にデータエンジニアも取り組んで行く必要があります。
サービスレベルの向上
前述のように、分析がユースケースの中心である現状においては、基盤に求められるサービスレベルは実はそこまで高くない状況ではあります。
しかしながら、ほぼ常時データを利用し続ける業務ユースケースでの利用が増えていくと、障害 = 即業務停止 となってしまうため、サービスレベルを向上させていく必要があります。
具体的には、監視システム・体制の強化やフォールバック機能の拡充、利用しているOSSに起因する問題などについてコードレベルで調査を行い対応していく等のアクションが求められてきます。
収集すべきだけどできていないデータの収集
データ分析には色々なユースケースがありますが、多くのユースケースで求められるデータとして、サービス上でのユーザーの行動データがあります。
行動データはGoogle Analytics (Google Tag Manager)やサービスDBで保存していますが、分析上欲しいけどデータが取れていない、、といったものもあります。
こういったデータを収集できるようにサービスの開発エンジニアと連携、議論していくことも重要です。
まとめ
今回はheyの統合データ基盤について、今後やっていきたいことについてご紹介しました。
現状データエンジニアは業務委託を合わせて3人なのですが、これら山積みの課題に一緒に取り組んでくれる方を絶賛大募集してます！
既にデータ基盤開発経験があり「それやったことあるわ〜」という方、基盤の開発経験はないが面白そうだと思った方がいましたら、ぜひまずは気軽にデータチームのメンバーとカジュアル面談させていただけると嬉しいです！
