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 Snowflake 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」
社のテックブログで、
どういうデータ基盤かについて、
詳しくまとめています。
Snowflake、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: Snowflakeユーザーを払い出して、利用者に委ねる。
● 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/