中央集権体制からDataOpsへの転換 / centralized-to-dataops-transformation

Slide 1

Slide 1 text

中央集権体制から DataOpsへの転換 DataOpsがもたらす事業価値我が社が考える最強のデータ基盤 '24最新版

Slide 2

Slide 2 text

データ基盤が成長フェーズに入り始めるとこういうことに直面しませんか？

Slide 3

Slide 3 text

大量のモデルと多様なドメイン。正直、把握が難しい。

Slide 4

Slide 4 text

「このアラートは、緊急度高いやつ？」「このデータは、どういうデータ？」

Slide 5

Slide 5 text

データ基盤チームが、データの何これ？を把握するだけで、時間が溶けていく。

Slide 6

Slide 6 text

本来やりたい開発ができない。

Slide 7

Slide 7 text

「せや、DataOpsや」

Slide 8

Slide 8 text

アジェンダ ● 自己紹介 ● データ基盤で発生していた課題 ● DataOpsとは ● DataOps導入のアプローチ ● まとめ

Slide 9

Slide 9 text

アジェンダ ● 自己紹介 ● データ基盤で発生していた課題 ● DataOpsとは ● DataOps導入のアプローチ ● まとめ

Slide 10

Slide 10 text

自己紹介ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) CARTA HOLDINGS/CARTA MARKETING FIRM 開発局データ部部長 2024 Snowﬂake Data Superheroes

Slide 11

Slide 11 text

今日話すこと ● DataOpsがどういうシチュエーションで効くのか ● 実務に適用する場合の攻め方

Slide 12

Slide 12 text

話さないこと ● 細かい話。（時間が足りない・・・ｗ）

Slide 13

Slide 13 text

アジェンダ ● 自己紹介 ● データ基盤で発生していた課題 ● DataOpsとは ● DataOps導入のアプローチ ● まとめ

Slide 14

Slide 14 text

弊社におけるデータ基盤の位置づけ弊社には、複数の広告プロダクトを開発するチームが存在します。各チームは自身のプロダクトに対して責任を持ち、設計から実装までを一貫して担当しています。データ基盤は、複数のプロダクトを横断したプラットフォーム的な存在として位置付けられています。

Slide 15

Slide 15 text

データ基盤「Vision」社のテックブログで、どういうデータ基盤かについて、詳しくまとめています。 Snowﬂake、dbtを使っている人には、参考になる部分もあるかも？ https://techblog.cartaholdings.co.jp/entry/snowflake-data-platform-vision

Slide 16

Slide 16 text

中央集権体制で始まったデータ基盤データ基盤を用意するだけでは、データ基盤は使われません。データマネジメントに精通してるわけではないプロダクトチームに、いきなり委譲するのは現実的ではないため、基盤チームがデータに関する意思決定プロセスに介入する体制にしていました。これの狙いとしては、プロダクトチームとのコラボレーション推進、強制力のあるプラクティスの標準化、最終的に、スケール可能な基盤をゴールとして、中央集権的な体制で、データ基盤を組織へ浸透させていきました。

Slide 17

Slide 17 text

データ基盤が動き出してから、ちょうど一年くらい経ったタイミングで、この体制のデメリットが目立ち始めます。

Slide 18

Slide 18 text

中央集権の限界データ基盤の活用が進み、データの種類が増加し、ユースケースも多様化したことで、基盤チームが認知の限界を超え始める。 ● dbtモデルが500個増加 ● 分析、機械学習、レポーティングなど、多岐にわたるユースケース例えばデータ品質一つをとっても、ユースケースに応じて適切な管理方法は異なる上、ドメインも理解しなければ、適切な判断ができません。このような意思決定全てに対して介入することは、段々と負荷になってきて、最終的には無茶になりました。

Slide 19

Slide 19 text

具体的な問題事例ある軽微なdbtモデルのテスト失敗への対応でさえ、問題が顕在化しました。基盤チームは、モデル（≒データ）に詳しくないので、緊急度やテストの妥当性を判断できず、対応に手間取る。一方、データの作成者は、モデルには詳しいので、緊急度やテストの妥当性はわかりますが、起きてる問題の原因の特定に、苦労していました。

Slide 20

Slide 20 text

なぜか？

Slide 21

Slide 21 text

問題に対応するのに必要な情報が揃ってない基盤チームが全てを把握してる内は良かったですが、あるタイミングから、次のような状態になりました。基盤チームはパイプラインには精通しているものの、ドメインに関する知識が不足しています。そのため、データの問題が発生した際、データの内容について作成者に確認する必要があります。一方、データ作成者はドメインには詳しいものの、パイプラインへの理解が乏しいため、問題の原因を特定するためには、基盤チームの助言を仰ぐ必要があります。

Slide 22

Slide 22 text

こういった積み重ねが、業務全体のオーバヘッドになる。

Slide 23

Slide 23 text

コミュニケーションが必ず発生する構造を壊す必要が出てきた。

Slide 24

Slide 24 text

解決策を調べてたら、 DataOpsと出会った。

Slide 25

Slide 25 text

アジェンダ ● 自己紹介 ● データ基盤で発生していた課題 ● DataOpsとは ● DataOps導入のアプローチ ● まとめ

Slide 26

Slide 26 text

DataOpsとはデータ分析のプロセスを自動化・最適化し、データの品質と利用可能性を向上させることで、データドリブンな意思決定を促進し、ビジネス価値の実現までのリードタイムを短くするための方法論です。

Slide 27

Slide 27 text

DataOpsフレームワーク計画から監視までのライフサイクル全体を通して、データチームとビジネス部門が協力してより信頼性の高いデータ分析を提供することを目指します。 DevOpsのライフサイクルを参考にしつつ、データの性質に合わせて異なる技術やプロセスを取り入れることで、データ品質の向上とインサイトの迅速な提供を実現します。 https://www.montecarlodata.com/blog-what-is-dataops/

Slide 28

Slide 28 text

DevOps != DataOps DevOpsの成果物は、ソフトウェア。 DataOpsの成果物は、分析業務そのもの。 DevOpsは、ソフトウェア開発と運用の連携を強化し、アプリケーションの構築・テスト・リリースの自動化を推進することで、より迅速で効率的なソフトウェアデリバリを目指します。一方、DataOpsは、データ分析ワークフロー全体の最適化に焦点を当て、データの収集から分析、価値創出までのリードタイムを短縮することを目的としています。

Slide 29

Slide 29 text

DataOpsを実現する過程で、 DevOpsを当たり前に実施するので、 DevOpsよりも実現難易度は上がります。

Slide 30

Slide 30 text

アジェンダ ● 自己紹介 ● データ基盤で発生していた課題 ● DataOpsとは ● DataOps導入のアプローチ ● まとめ

Slide 31

Slide 31 text

DataOpsになぜ取り組むのか。

Slide 32

Slide 32 text

DataOps導入の目的分析業務を円滑に進めるために、利用者の利便性とデータの品質を向上させることが目的です。円滑な状態とは、適切かつ迅速にデータが提供され、分析に集中できる環境が整っている状態を指しています。 ※以降、利用者はデータ基盤の利用者を指すものとします。

Slide 33

Slide 33 text

円滑な状態とは、どのような状態か？

Slide 34

Slide 34 text

利用者は価値創出に集中でき、基盤チームは仕組み作りに集中できる状態である。と定義しました。

Slide 35

Slide 35 text

円滑な状態の実現データに関する意思決定は、データのドメインを理解しているデータ作成者が行うことで、迅速かつ適切に行えるはずです。仕組みに関する意思決定は、基盤チームが幅広くユースケースを把握し、実装に精通していることから、妥当な判断ができるはずです。これらの性質を加味すると、それぞれの得意分野に注力することで、円滑な状態を実現できる（はず）です。この状態を実現することが、自然とDataOpsにつながると考えました。

Slide 36

Slide 36 text

DataOps実現のために何をやっていくと良いか？を整理する

Slide 37

Slide 37 text

DataOpsフレームワークで足りない要素を確認まずは、弊社として取り組むべき部分を整理しました。 https://www.montecarlodata.com/blog-what-is-dataops/

Slide 38

Slide 38 text

DataOpsフレームワークと当時の業務実態の比較 ● Planning: データ作成者が計画・実行 ● Development: データ作成者が構築（dbt, Terraform, Fivetran, etc..） ● Integration: GitHubのmainブランチへのpushで自動反映 ● Testing: dbt testでデータのテスト ● Release & Deployment: GitHubのmainブランチへのpushで自動反映 ● Operate: Snowﬂakeユーザーを払い出して、利用者に委ねる。 ● Monitor: DataDog、Elementaryを使ってアラートを出している。

Slide 39

Slide 39 text

実はかなりDataOpsを実践できていた。では、何故うまく行ってる感がないのか。

Slide 40

Slide 40 text

一つ、明確に課題がある領域があった

Slide 41

Slide 41 text

ラストワンマイルはDataObservability。

Slide 42

Slide 42 text

DataOpsにおけるDataObservability パイプラインの全段階で、データの鮮度、分布、量、スキーマ、リネージを監視することで、データの品質と信頼性を理解し、問題に先手を打って対処する能力のことです。これにより、データのライフサイクル全体を通してデータの健全性を把握し、信頼できるデータを提供することができます。 DataObservabilityは、DataOpsの戦略的な取り組みにおいて、パイプラインの信頼性を確保するための中核的な役割を果たします。

Slide 43

Slide 43 text

DataObservabilityが解決すること「なぜデータ更新されていないのか？」を答えるには、様々な情報が必要です。まず、データの鮮度が想定の範囲に収まっているか、データパイプラインは正しく動き続けているのか、dbt testは実施されているかなど。問題発生時に原因を特定するのは簡単ではありません。仮に何が起きているのかを、適切に回答できる仕組みがあれば、問題の解決はずっと容易になるはずです。そのような課題にDataObservabilityは非常に有効です。

Slide 44

Slide 44 text

まさに何が起きているのかを簡単に理解できないことが、コミュニケーションを発生させる原因だった。

Slide 45

Slide 45 text

どのようにDataObservabilityを実現するか？

Slide 46

Slide 46 text

選ばれたのは、Elementary Cloud。

Slide 47

Slide 47 text

灯台下暗しのElementary 実はElementary OSSは、1年間ほど使用しており、主な利用者は基盤チームという状況でした。これらを全利用者が使えるように整備し直すだけで、 DataOpsを支える仕組みが出来上がります。いずれ必要になるだろうというのと、基盤チームの運用にも必要不可欠だったので導入していたのですが、まさかDataOpsへの移行時にも必要不可欠になるとは・・・

Slide 48

Slide 48 text

Elementary Cloudを日本で初導入 Elementary Cloudを採用しました。（日本で初めてだったらしい）当初は基盤チームだけが使用する程度の想定だったので、基盤の根幹を担うという位置づけではなかったElementary。 DataOpsへの移行をきっかけに、重要なコンポーネントになりました。そのため、今後もElementaryの開発が継続されることが重要です。 Elementary Cloudを採用することで、サービス継続に必要な資金を提供しつつ、密接なコラボレーションを実現することにしました。

Slide 49

Slide 49 text

手札は揃った。あとは、どのように体現していくか。

Slide 50

Slide 50 text

まず、「DataOpsを導入する」ことを周知。

Slide 51

Slide 51 text

「DataOpsを導入する」ことの周知データ基盤関係者に対し、まず最初に周知を行いました。DataOpsとは何か、これまでの働き方がどう変わるのか、なぜ導入するのかなどをDesignDocにまとめました。実は今日の資料は、ほとんどこの DesignDocの内容そのままです。

Slide 52

Slide 52 text

ゴールは、データオーナーの自律的な運用を可能にする基盤の構築。

Slide 53

Slide 53 text

具体的なアクション（重要な点に絞って紹介） ● データオーナーの明示化 ● データの情報化 ● DataObservabilityツールの民主化 ● ドキュメンテーション

Slide 54

Slide 54 text

データオーナーの明示化

Slide 55

Slide 55 text

データオーナーの明示化これまでも暗黙的に、データを作成した人がデータの管理を行う雰囲気がありましたが、これを明示的に規定することにしました。つまり、データを作成したチームが、そのデータの運用と説明責任を負うということです。結局のところ、データのドメインに関して最も詳しいのは、データを作成した人またはチームであるため、その人たちに運用を任せることにしました。

Slide 56

Slide 56 text

データの情報化

Slide 57

Slide 57 text

データの情報化データオーナーにデータの運用を任せる上で、「ここのログを確認してください」といった、仕組みに詳しくないと対応できないようなオペレーションは徹底的に排除しました。例えば、どのdbtモデルがどのようなコンテキストで実行されたかといった情報は、サーバーのログを直接確認しなくても、クエリやダッシュボードを見れば把握できる状態にしました。このようなパイプラインに関する情報化は、 Elementary dbt artifactsが大いに役立ちました。

Slide 58

Slide 58 text

DataObservabilityツールの民主化

Slide 59

Slide 59 text

DataObservabilityツールの民主化これは主にElementary Cloudに関連する内容ですが、データ基盤チームだけが使用するツールから、データ基盤に関わる全ての人々に公開する形に移行しました。そのため、Elementary Cloudの使い方を、基盤チームだけでなく様々な人が使用することを想定した方法に再設計しました。ここに関して、話し始めると数時間くらい行きそうなので、興味ありそうな人が多ければ、別の形でまとめるかも？

Slide 60

Slide 60 text

ドキュメンテーション拡充

Slide 61

Slide 61 text

ドキュメンテーション拡充データ基盤の利用者が確実に増加するため、都度口頭で説明したり、利用者に振る舞いをコードで、理解してもらうのは現実的ではありません。そこで、よくある質問や全員が知っておくべきことはドキュメント化しました。また、運用上の問題への対処方法を、誰でも読めば実行できる状態を目指し、 PlaybookやRunbookを整備しました。ドキュメント化にはそれなりのコストがかかりましたが、利用者だけで完結できる作業が大幅に増えたことや、暗黙知の減少、ドキュメント作成過程での考慮漏れの発見など、良いことは多かったです。

Slide 62

Slide 62 text

アジェンダ ● 自己紹介 ● データ基盤で発生していた課題 ● DataOpsとは ● DataOps導入のアプローチ ● まとめ

Slide 63

Slide 63 text

まとめ DataOpsは、分析業務のリードタイム短縮を目指す方法論であり、 DevOpsとは異なる概念です。導入には利用者の責務増大を伴うことがあるため、環境整備が不可欠です。また、安定運用にはDataObservabilityが鍵となります。弊社では、データ作成者への意思決定権委譲という形で、 DataOpsを実現していってます。まだまだ、道半ばですがこれからも頑張ります。

Slide 64

Slide 64 text

もっと詳しく話聞きたい？

Slide 65

Slide 65 text

「DATA ENGINEER NIGHT #0」やります！！！！！ https://cartaholdings.connpass.com/event/313401/