こんにちは。データ基盤グループの香川です。
本記事は、MonotaRO のデータ基盤の歴史についての社内での発表の文字起こし記事の後編になります。
前編の記事：
前編では
- データ基盤の変遷の概要
- 2010年頃のデータ基盤
- 販促基盤とDWH（2010~2015)
- データ基盤構想とBigQueryの導入（2015~2017年)
- 同期システムの改良とBigQueryデータ基盤の展開（2018)
までお話しましたが、後半たる本記事では以下について説明をしていきます。
- 他システムへのデータ提供とEC基盤の展開(2018)
- 2020年におけるデータ基盤へのデータ同期と利用状況
- データ基盤の課題：データの管理体制の未整備による局所最適化
- データ管理のグループ発足、Looker導入・DWH構築
- 歴史を振り返っての学び
- 歴史を振り返ることの意義
- 最後に
最後までお付きあいいただけますと幸いです。
語り手 データ基盤グループマネージャー：香川
他システムへのデータ提供とEC基盤の展開(2018)
2018年の分岐した上のほうに入っていきます。 他システムへのデータ提供とEC基盤の展開についてです。
この頃に Web APIによるBigQueryのデータ提供を始めました。
BigQuery上で事前にデータサイエンスグループによって作成されたデータをMySQLにエクスポートしておいて、ECサイトのアプリケーションから利用できるよう、GAE上に構築したアプリケーションからWeb APIとして提供するというようなものでした。 データ基盤を利用して作成したデータサイエンスの成果物をGCPから簡単にECサイトに提供するというシステムで、新たなデータ基盤の可能性を示すものとなっていました。
話は変わりますがちょうどこの頃、基幹システムの方で一部パッケージの導入など含むアーキテクチャの変更の計画が進みだしていました。
大まかには今まで巨大なモノリスとして構築されていたシステムを徐々に分割していこうというものです。
今まで基幹、ECサイトのシステムはそれぞれがモノリシックなアーキテクチャで構築を進めていましたが、モノリスを分割すると、今度はシステム間でデータのやりとりをどう行うのかというのが新たな課題となってきました。
この時すでにBinaryLogによる同期によって、基幹システム、ECサイトのシステムのデータをニアリアルタイムにGCP上で統合することが可能になっていて、また先程説明した簡単にデータ提供をするためのシステムもできていたため、システム間のデータのやりとりを解決するために、データ基盤を基にデータ連携基盤を構築するという構想が企画されました。
この構想をもとに構築されたのが Data Delivery Platform 、社内では DDP と呼ばれてるものになります。
これは Bigtable 上に Key-Valueの形式で保存された大規模なデータを低レイテンシーで配信するようなシステムになっています。
このシステムは今のレコメンダーシステムにもつながっていくのですが、その話はまた別の機会に預けます。
2020年におけるデータ基盤へのデータ同期と利用状況
やっと2020年までやってきました。ここで一度現状のデータ基盤について少し説明をしたいと思います。 まず今どんなデータがBigQuery、データ基盤にあるかについて説明します。 MySQLからだいたい30スキーマ、1500近くのテーブルがニアリアルタイムで同期されています。あとは、ウェブサーバー、アプリケーションサーバーのログであったりとか、Akamai(CDN)のログが同期されています。他にもGoogle Analytics などのデータがエクスポートされていたり、WMS(倉庫管理システム) やそのほかパッケージなど社内のシステムのほとんどのデータが同期されています。加えてそれらを分析や機械学習の学習データなどで利用し、新たに作成されたデータなどもBigQueryに保存しています。
利用人数としては、毎月利用しているユーザーは350人ぐらいで、アナリストやデータサイエンティストはもちろんエンジニア、経理からカスタマーサポート、物流や商品採用や開発など全部門が利用しています。今全社員が550人ぐらいなので大体 2 / 3 が利用していることになります(2021/09 当時)。
ユースケースとしては、分析はもちろん業務オペレーション用のツールだったりとか、システムのメトリクスを保存したりなど多岐にわたります。 クエリの実行数は毎月270万回以上です。土日や祝日も合わせて考えると一日 9万回以上実行されていることになります。実行クエリのほとんどのケースでは Flat-rate という定額プランで実行していますが、一部はオンデマンドで実行しています。
データ基盤の課題：データの管理体制の未整備による局所最適化
ここまでの説明の通りそれなりの規模で利用していますが、万事順調というわけでもなく問題もたくさんあります。大きいものとしては、まずデータと指標が管理されていないという問題です。
データに関する情報が集約管理されていないため、データや指標の管理において局所最適化が進んでいます。 それにより、他部署とのコミュニケーションが難しくなっていたり、同じようなデータや指標を各組織で作成したりといった現象が起きています。 例えば受注数という基本的な指標にしても、「キャンセル含むかどうか」が部署ごとに違うといったことがあり、混乱の元になっています。
こういった問題の要因としては、端的に管理体制が未熟という点があります。 データ管理として、やるべきことに対して目指すべき体制や状態が明確でない、ポリシーやルールがない、そもそも管理に関わるメンバーが足りないというのが現状です。
現状の問題について説明しましたが、ここでデータ基盤の歴史の全体図を見て、その中でユーザーの利用状況やデータ基盤に関する問題がどのように変遷してきたのかについて見ていこうと思います。
まず2010年以前はデータの抽出はエンジニアに依頼してExcelで集計するといった形で本当に一部の方のみしか利用できない状態になっていました。 2010年頃に販促基盤が構築されたことで限定的に一部の部署がデータが使える状態になりました。この頃に社内でデータを活用するスキルと文化が醸成し、2017年のBigQuery導入によって、誰でも自由に使えるようになりました。
そして、2018年から2019年にかけてデータの拡充によるユースケースの拡大や、SQL勉強会などでユーザのスキルアップなどを行うことで、より多くの人が自由にデータを使える状況になりました。 2020年になって社内のユーザーも部署もさらに増えて、スキルやユースケースについてもバリエーションがでてきました。現状では MySQL から同期しているテーブルだけでも1,500 程度あり、特定のデータを出したい場合に「どのテーブルとどのテーブルをどの条件でジョインすればいいのか」といった知識が足りず、間違ったデータを出してしまって、そこから意思決定してしまうといった問題が発生しはじめました。
結果として、「自由につかえるが簡単にはなかなか使えない」という状況になっていきました。
歴史を振り返り、現状のデータ管理ができていないという問題とそれが発生するまでの流れが認識できたところで、ここから再び歴史の話の延長としての現在の話に戻ります。
データ管理のグループ発足、Looker導入・DWH構築
2021年に入ってから、データ基盤グループではデータ管理を専門に行うグループとして組織の役割と業務を新たにして再スタートしました。いわば新しい組織の立ち上げのような取り組みを行っています。 「DMBOK」というデータ管理の知識が網羅的に体系化された本があるのですが、これを参考とするとデータ管理には 11の領域があります。データ統合やメタデータ管理、 マスタ管理やDWHやデータセキュリティなどなど。データ管理を専門に行うとしてもデータ管理がカバーする領域はとても広く、すべてを一気にやろうとすると行き当たりばったりでうまくいかないため、「DMBOK」を基にアセスメントを行い、データ管理のロードマップを作成しています。
またこれは昨年から行っているのですが他部門のアナリストやマーケターと一緒に LookerというBIツールの導入とデータマートの構築をすすめていてます。 今年に入ってからはそれ以外にも dbt というツールを使ってDWHの構築を進めています。
歴史を振り返っての学び
歴史の話が現在までたどり着いたところで、先程の歴史の全体像に戻ってみたいと思います。先程の説明の通り、ユーザの利用状況と問題の変遷を確認すると、発展とともに問題がいろいろ変わっていて、またその変わっていく問題を順番に解決し、解消しているのが分かります。ゆっくりではあるんですけど着実にデータ基盤が進歩しているといえます。
全体を振り返っての学びについて少し話します。
まず最初に、BigQueryでデータ基盤の構築をはじめてからこれまで、順調に進んでいるように見えますが、その要因を考えてみるとタイミングや状況がよかったというのがあります。
当時のメンバーのスキルや興味が偶然 BigQuery や Binlog を使った同期など、やりたいことにマッチしていたり、BigQueryでのデータ基盤構築時にはすでに販促基盤を基にデータ活用の文化が醸成されていたり。 「組織として大きい取り組みに成果を出すために、自分やチームのアクションだけで完結して成果をだせる領域ってそんなに多くない」と皆さんもいろいろ業務されてる中で感じるところが多いんじゃないかなと思います。ですが、これを踏まえるとプロジェクトやタスクを始めようという時に、その時の状況やタイミングを把握し、その状況に至っているコンテキストをちゃんと見極めてアクションを適切に起こしていくというのが重要です。 つまり、自分やチームのアクションやスキルばかり振り返って改善させても周りをちゃんと見ないことには解決できる問題は増えていかないということです。また、よい状況やタイミングというものをいかに自分で作っていけるようにするかというのも重要だと思います。
あとは歴史を振り返ることそのものについて学びがあるんですが、歴史を振り返り、曖昧な”課題感”を時間の流れとして捉えることによって、”論理的な根拠がある具体的な課題”として認識することができるようになり、新しい領域にも確信を持って進むことができるようになるというのがありますした。改めて、歴史を振り返ることの重要性を理解しました。
ということで本発表では、MonotaROにおけるデータ基盤の歴史とその中で課題がどう変遷してきたが、それらを振り返ることでどういう学びがあったかについて説明をしてきました。 長くなりましたが、発表は以上です。 ありがとうございました。
歴史の振り返りの発表はここまでとなります。
前編から、簡単にではありますが約10年に渡るMonotaROのデータ基盤の歴史を振り返り、学びをまとめました。
歴史を振り返ることの意義
私は今年でMonotaROに入社して6年目になりますが、社内ではそこそこ古いメンバーになってきています。そんな古くからいるメンバーでは当たり前となっていることでも、新しいメンバーからすると初めて知ることだったりすることも多く、そこから情報格差が生まれコミュニケーションが円滑にいかなくなるといったこともしばしばあります。 こういった問題を解消しながら組織の全員が目的を理解し目線を揃えて進むためには、我々がどこからきて今どこにいるのかということについて、古いメンバーも新しいメンバーも一緒に認識を揃えていく必要があります。そのためにも社内の取り組みの歴史を振り返り、それをまとめて発表するというのはとても重要だと考えています。
最後に
歴史の振り返りとしては前編と、後編となる本記事で終わりですが、データ基盤グループでは当然現在進行系で多方面にデータ管理をすすめています。 特に今年は DWH構築に力を注ぎましたが、すすめるなかで様々な課題があることがわかってきました(これについては先日同じグループのメンバーである吉本さんが Data Engineering Study で発表しました)。
www.slideshare.net
この課題も踏まえたうえで今後どういったことに取り組んでいこうと考えているかについては記事として書こうと思っていますので、どうぞご期待ください。 また振り返りの中では MLシステムとEC基盤との取り組みについて、重要ではありますが、あまり触れることができませんでした。そちらも機会があればどこかで記事として公開したいと思います。
データ基盤グループでは、一緒にデータ管理に取り組んでいただけるメンバーを募集しています！
本記事にグッと来た方は是非ご応募お願いします。
またカジュアル面談も受け付けておりますので、データ管理やMonotaROについて質問や議論したいというかたはこちらのフォームからご応募お願いします。
