「Bigfoot」の需要が増えたことにより設立された「データ基盤チーム」
堤利史氏：本日は「データ基盤チームの設立と直近の取り組み」というテーマでお話しします。技術部データ基盤チームに所属しています、堤と申します。データエンジニアとして2020年12月に入社しました。どうぞよろしくお願いします。
本日お話しするのはこちらの3点です。1つ目がデータ基盤チームの設立についてです。2つ目がチームの直近の取り組みについてで、最後にこれからどうしていくかをお話ししようと思います。
まずはデータ基盤チームの設立と、ログ活用基盤である「Bigfoot」について紹介します。弊社には以前よりBigfootというログ活用基盤が構築されていて、これはペパボ研究所と技術部技術基盤チームが中心となって開発しました。2020年に「Google Cloud Platform」をベースに再構成して、「BigQuery」と「Cloud Composer」が中心のアーキテクチャになっています。
ペパボ研究所のブログに経緯が詳しく書かれているので、気になる方はぜひ見てもらえればと思います。その記事から抜粋した構成図がこれです。インフラは「Terraform」で管理していて、ワークフローとしてCloud Composerが入っているので、メタデータの管理の仕組みまで構築されています。
日本CTO協会により「DX Criteria」が提言されて、弊社もデータ駆動に全社的に注力していく方針になりました。データ駆動に注力するとなると、Bigfootを最大限に活用していくことになります。これについてもブログで取り上げているので、気になる方はぜひ見てください。
そういう事情もあって、前回の「Pepabo Tech Conference」でも「SUZURI」のデータ基盤事情について発表があったり、テックブログでもBigfootを使ったZendeskデータの可視化について紹介がありました。時間があったらぜひ見てみてください。
社内事情を簡単に表すとこうなります。Bigfootへの需要が多くて、供給がぜんぜん追いつかない状態になりました。
その結果、2021年1月にデータ基盤チームが設立されました。「"データ駆動"の実現を担う事業部横断組織」というビジョンで、「社内のあらゆるデータの意味付け」「データによる意思決定を支援するプラットフォームの構築」「すべてのパートナー（従業員）への提供」をミッションに掲げています。
チームを強固にするための取り組み
こうして設立したデータ基盤チームが、直近で取り組んだ内容について今回は2つ紹介します。1つ目がチーム運営と基盤の改善です。2020年の段階では、Bigfootの開発に関わっていたメンバーは2人だったんですが、体制強化により私を含めて倍の4人に増えました。
手数が増えてプルリクエストも増えるのは、活気があってすごくいいことなんですが、テスト環境が1個だったので、CIで渋滞するという問題が発生しました。また、連携元のシステムやサービスなどが増えて、依存関係が複雑で把握するのが難しかったり、新規メンバーがキャッチアップする必要があったり、全体的に何らかの対策が必要になりました。
そこでこの2ヶ月でやったことが、ここに上がっている内容です。CIの環境を移行したり、テスト環境を増設したり、マルチクラウド対応ということでAWSのチーム利用を開始したりしました。ほかにも「Sentry」によるエラーマネジメントを開始して、エラー通知からの情報の確認や起票がスムーズにできるようになりました。
そういったシステム的な対応だけでなく、チームをより強固にするためにアーキテクチャ共有会を定期的に開催したり、ドキュメントの拡充を意識的に行ったりしました。
こうした対応をすることで、状況がかなり改善してきたなという実感はあるので、今後のチーム体制や社内の状況に合わせて柔軟に対応しながら、引き続き取り組んでいければなと思っています。
オリジナルグッズ作成・販売サービス「SUZURI」のKPIダッシュボードを作成
続いてチームの外にフォーカスした内容として、SUZURIにおけるKPIダッシュボード作成についてお話しします。まずSUZURIというサービスについて簡単に紹介します。SUZURIは画像をアップロードするだけでオリジナルのグッズを作ったり、グッズの売り買いができたりするサービスです。作るのもすごく簡単で、クリエイターさんもおもしろいアイテムを作っているので、ぜひ覗いてもらえればと思います。
SUZURIを展開していく中で、さまざまな施策を打つんですが、サービスの状態をデータで把握して、施策のPDCAを円滑にするために、ダッシュボードを作成したいという要望がありました。ダッシュボードを作るとなると、ここに上がっているようなビッグデータ特有の要件が並ぶことになるので、Bigfootの出番です。
今回構築したデータパイプラインを図にしたものがこれです。SUZURIからデータを受け取って、真ん中のBigfootでいい感じに加工して、ダッシュボードで可視化しています。Bigfootでは概念的にデータを3層に分けていて、生データをData Lake層に入れて、構造化したデータをData Warehouseに入れます。ユーザを利用しやすいように、加工したデータをData Martへという流れで加工して、データを格納しています。
BIツールである「Data Studio」が参照するのは、Data Martにあるデータです。ダッシュボードのデータが更新されたら、サマリーとともに「Slack」に通知する仕掛けを今回開発しました。
ここからはどう構築したかをお話ししていきたいと思います。全部で4ステップあります。ステップその1ですが、まずSUZURIを理解することから始めます。すぐに手を動かしたくなるんですが、どうやって作るかはいったん頭の片隅でぼんやり考えるぐらいで我慢します。
事業を知らなければ、何をダッシュボードで表現すればいいのかがわからないので、ビジネスモデルや用語の定義を一つひとつ確認して、認識の齟齬がないようにします。教えてもらうばかりではなくて、サービスを実際に体験してみたり、データ構造を理解するためにひたすらSELECT文を投げてみたりと手を動かすことも並行して行いました。
ちなみに今日着ている服はSUZURIで買ったものです。ちょっとPythonのバージョンが古いところが気に入っています。
本題に戻って、ステップその2がドラフト版の作成ですね。Data StudioがBIツールです。Data Studioは簡単にBigQueryとデータ連携ができるので、実際に動くのを見ながらビジネス要件を確認します。どんなダッシュボードが欲しいかはヒアリング済みなんですが、やっぱり動くものを見ないと何とも言えないところがあるかなと思います。
カスタムクエリという、データソースをSQLで直接指定するモードがあるんですが、そこにハードコードして、実際に触れるダッシュボードを少ない手数で作るのを優先的にやっていきます。そのあと意見交換をして、どんなアウトプットが良いかがわかってきたら、Cloud Composerでワークフローを構築して、データ加工処理を最適化していきます。
このCloud ComposerがGoogleが提供するフルマネージド「Airflow」です。たくさんの種類のOperatorが用意されているので、それを合わせてワークフローの定義をしていきます。スケジュールの概念がけっこう独特で、私は初めて触ったので苦戦しました。これを使ってData Lake、Data Warehouse、Data Martの方向にデータを加工していきます。
最後にSlack通知の部分を実装しました。実装したのは、Cloud ComposerでData Martの作成が終わったあとにSlack通知を行うというものです。Slack通知のときに、サマリーとダッシュボードのURLを一緒にくっつけて送るというかたちです。
通知のときにはSlackアプリの「Incomming Webhook」を使用するんですが、このときにちょうどいいAirflowのOperatorがなかったんですね。SELECT文を実行した結果を加工して、Slackに送るOperatorはなかったので、今回Custom OperatorというOperatorを自作しました。
Airflow Connection、mention、header、bodyの4つのパラメータをOperatorに渡すだけで通知ができる機能になっています。
Slackに通知が行ったときのイメージはこんな感じです。ダッシュボードのURLがあって、その下にKPIのサマリーが並んでいる通知内容になっています。サマリーやダッシュボードを見ながらそのままSlackで議論ができたり、社内共有も簡単にできたり、実際に議論がここで展開されているのを見たりできるので、個人的にはけっこう便利なんじゃないかなと思っています。
ダッシュボードはいったん我々が作りますが、実際に使う人が編集ができるので、ベースだけ作る感じです。以上が取り組みの紹介でした。
データ基盤チームが目指すこれから
最後にデータ基盤チームのこれからについて少しお話しします。こちらは再掲なんですが、冒頭のビジョンとミッションですね。実際にチームが立ち上がって、これをどうやって実現していくかをいったん考えようと話し合いをしたんですが、そのときの結論として、この3つをやっていこうとなりました。
まず1点目として、Bigfootをさらに活用してもらうための取り組みをやっていこうと思っています。データや基盤は活用するためにあるものです。なので、活用するにはどんな方法があるのか、実際にデータを流し込むにはどうすればいいのか、松・竹・梅ではないんですが、そういう選択肢を提示して、開発手法や費用感のイメージをつかんでもらうことに注力していこうと思っています。
2点目がチームの認知度を上げるための取り組みです。どんなメンバーがいて、何をしているのかを知ってもらうのは、相談のしやすさという意味で重大なポイントなんじゃないかなと思っているので、今後は社内だけではなく、社外への情報発信をちょっとがんばっていこうかなと思っています。
最後に「至高のデータ基盤を目指して」と書きましたが、技術的なチャレンジを忘れずに、さらなる高みを目指すのも目標として掲げていきたいと思います。先ほど紹介した図で、すでにかたちはできているんですが、そこに甘んじることなく新しい技術を取り込んでいきながら、さらに活用してもらえる基盤に育てられればいいかなと思っています。
このような感じで、データ基盤チームは今後もさらに活動の幅を広げていきたいと思っています。以上で発表を終わります。ありがとうございました。
