はじめに
初めまして、株式会社リクルートでデータプランナーとして勤務する酒井と申します。
2020年度新卒でリクルートに入り、2022年現在は、美容/旅行領域において、データ活用施策の立案から運用やプロダクトマネージャーをしています。
本記事では、私が新卒入社してから半年で立案〜運用まで主担当した「データマート品質モニタリングシステム」の整備について、プロジェクトの一連の流れをご紹介します。
きっかけは「データマート大規模障害」
今回のプロジェクトの発端は、美容事業のデータマートの大規模障害でした。
当時美容事業ではデータマートのAWS環境からGCP環境への移行が行われていました。その際、分析で頻繁に使われるいくつかのデータマートで移行前後での数値が不一致となっている障害が発生していました。
幸い、まだ新しいデータマートへの運用移行が完了していなかったためカスタマーやクライアントへの影響はありませんでした。
しかし、データマート自体は美容事業にとって重要なので、新卒の私も障害対応チームへアサインされました。
社会人初の仕事がまさかの大規模障害対応とは夢にも思わず、当時は不安になりながら障害対応を進めることになりました。
実際に担当したのは障害対象の明確化
私が最初に担当したのは、移行前後のデータマートの差分結果の可視化です。
当初は「データマートの移行前後で差分が起きているが、どのデータマートがどのくらい差分があるのか」が明確にわかっていなかったので、それを明確にするのが私の役割となりました。
そして、実際に作成したのが以下のようなダッシュボードです。移行前後のレコード数を比較するクエリを作成し、それをTableauで可視化しています。
このダッシュボードによって、障害対応チーム内で「今異常が起きているデータマートはどれか」がすぐに特定できるようになり、素早い調査と障害対応ができるようになりました。
こうして、各メンバーの尽力もありデータマート大規模障害は3ヶ月ほどで全ての対応が完了することになります。
障害を振り返って
障害は無事解決しましたが、重要なのは「今回の障害から何を学び、事前対策や同じような事態が起きた時にどう対処するか」です。
今回のデータマート大規模障害を踏まえ、私は課題点とあるべき姿を以下のように考えました。
課題点
- データマートの異常検知は問い合わせベースで、モニタリングがされていなかった
- データマートの異常調査は異常が発生する度に、SQLでクエリを書いて調査していたので工数負荷が大きかった
あるべき姿
- データマートの異常を素早く検知し対応する仕組みを作ることで、データマートの品質を保つこと
以上大規模障害の教訓を活かし、「データマートの品質を担保する仕組み」を作っていくことになります。
まずは要件定義から
「データマートの品質を担保する仕組み」はまだ存在していなかったため、まず要件定義から検討を始めました。
データマートの品質とは何か
データマートの品質を担保するといっても「データマートの品質とは何か」「品質をどうやって担保するのか」をまず決める必要があります。
あらゆる項目をモニタリングし品質を完璧に担保する仕組みを作るのは困難なので、「品質の観点を定義し、異常となる状態を定義すること」の判断軸が重要となります。
私は以下のように4つの判断軸・状態を定めました。
- 最新であること：作成時間が大幅に遅延していないか
- 欠損がないこと：レコード数が大幅に増減していないか
- 重複がないこと：一意キーが重複していないか
- 異常値がないこと：一意キーにNULLや空白が混入していないか
そもそもどうやって実装すれば良いのだろう
モニタリング項目が決まったら次は手段の選定です。 dbt というETLサポートツールがデータ品質チェック等の機能もあるというのを偶然ネットで発見し、活用できないか検討しました。
しかし、既存のインフラには未導入のツールであった為、dbtを使うとなると開発工数が一定かかりデリバリーが遅れると判明しました。一方で品質を担保できていない状況を野放しにするわけにもいかず、社内に存在する既存の仕組みを組み合わせることにしました。
とりあえず作ってみたが運用が大きな壁となる
私が初期バージョンとして作成した仕組みは、TableauとBigQueryを使ったものでした。
最初経験したデータマートの大規模障害でも使用しましたし、何より私が得意とするツールだったので、この構成を採用しました。構成を簡単に図示したのが以下です。
それらしいものが出来て、自信満々にしていた私ですが当時のマネージャーやチームリーダーにこの仕組みは却下されます。
何故なら、この仕組みを運用することが出来るのが、私だけでかなり属人的な仕組みであった為です。新しくモニタリングしたいデータマートが誕生した時に、私が都度SQLを作成し設定しないといけないのも再現性に欠けました。
誰でもいつでも簡単に運用できるものに
「データマートの品質を担保する仕組み」は仕組みそのものに加え、「どうやって運用し組織で広げていくか」も重要になってきます。
「要件を満たすが属人性が高いシステム」を作るだけでは、継続的な運用が難しいと痛感した私は「誰でもいつでも簡単に運用出来る」仕組みを作ろうと思い至ります。
こうして実際に構築した「データマート品質モニタリングシステム」の構成は以下です。社内に存在する複数のデータ基盤を組み合わせた構成となっています。
データマートが存在する状態から、品質をモニタリング出来るようになるまでの流れを簡単に整理すると、次のようになります。
- データマート作成担当者が指定のマスタファイル(csv)に情報(データマートのパスや主キーなど)を入力
- 指定のGithubにpushする
- Knile*が1のマスタファイルを元にモニタリング用のクエリをPythonを使って自動生成
- BigQueryにてクエリを実行し、結果テーブルを毎日生成
- 結果テーブルを可視化したものをTableauServer上に展開
- 異常を検知したらメール&Slack通知し障害対応
*Knileとはデータエンジニアリンググループが開発したGCPを活用した、分析・モデリング・学習パッチ実行環境の名称を指します。詳しくは以下の資料を参考にしてください。
リクルートのデータ活用を加速させるセルフサービス型 A/B テスト基盤の設計と実装
以上のように既存のデータ基盤を複数組み合わせ、かつGithubでマスタファイルを管理することで、「属人性を逓減したデータマート品質モニタリング環境」が完成しました。
仕組みの構築に加えて、マスタファイルを更新する作業を業務に組み込むために「データマートのリリースフロー」の整備も行いました。担当者はマスタファイルにデータマートの情報を入力するだけで、モニタリングをすることができます。
このシステムは属人性をなるべく排除するべく、当初却下されたTableau+BigQueryの構想に加えてPythonも活用しています。
私は文系出身なのもあり、Pythonを業務で使ったことはありませんでしたが、他部署の方にレビュー&相談に付き合っていただき、なんとかスタートしてから2ヶ月ほどで実装にたどり着きました。
リクルートには様々な得意領域・バックグラウンドを持つ方がいて、いつでも相談に乗っていただける環境でもあるので、データを扱う身としては最高の環境であると思います。
運用が始まってから
「データマート品質モニタリングシステム」は、私が新卒1年目の終わりに開発を終了させ、運用をスタートさせています。
当初ターゲットとしていた美容領域以外にも、飲食領域・旅行領域・SaaS領域と他事業へも横展開し、多くの領域のデータマートの品質をモニタリングできるようになりました。2022年現在も絶賛稼働中です。
実際に使用しているダッシュボードは以下の通りです。(一部)
それが功を奏し、データ推進室にて新人賞を頂くことができました。評価された理由としては、以下の2点かなと私は考えています。
- 事業のデータ活用を支える、データマートの品質をモニタリングする初のソリューションを作ったこと
- 属人性を極力排除した仕組みを作り、組織として継続運用できるようにしたこと
データマート品質の取り組みなど、データマネジメントの活動というのは非常に重要である一方、成果が定量化しづらく地味なものだと感じています。
しかし、そういった取り組みもこのような形で表彰していただけることは、「組織としてデータ活用の守りの領域であるデータマネジメントも重視している」と私は考えています。
おわりに
以上が取り組みの内容になります。
新卒1年目ながら、壮大なテーマを任せていただけたなと思っています。
リクルートでは、経験年数・年次問わず、やり切る力さえあれば規模の大きなデータ活用プロジェクトを担当できると思いますし、別組織・別職種の優秀な先輩方が、全力で助けてくれる素晴らしいデータ組織であると思います。
様々な職種のエンジニアも募集していますので、興味のある方は、以下の採用ページをご覧ください。
データプランナー、プロダクトマネージャー
Yusuke Sakai
リクルートの美容/旅行領域事業にて、データ活用施策の立案〜運用やプロダクトマネージャーをしています。
この記事をシェア
