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

【イベントページ】
https://chatwork.connpass.com/event/311948/
我が社が考える最強のデータ基盤'24最新版

Chatworkは約2年前よりデータ基盤の刷新プロジェクトを推進してきました。 スモールスタートで始まったプロジェクトは、今や拡大期を迎えています。 このイベントでは、そのプロセスや直面した壁などを大公開！ さらにゲストには大西氏、CARTA HOLDINGSのPei氏を迎え、各社の考え方やこれからのアーキテクチャについて激論を交わします！

Transcript

1. 中央集権体制から DataOpsへの転換 DataOpsがもたらす事業価値 我が社が考える最強のデータ基盤 '24最新版
2. データ基盤が成長フェーズに入り始めると こういうことに直面しませんか？
3. 大量のモデルと多様なドメイン。 正直、把握が難しい。
4. 「このアラートは、緊急度高いやつ？」 「このデータは、どういうデータ？」
5. データ基盤チームが、 データの何これ？を把握するだけで、 時間が溶けていく。
6. 本来やりたい開発ができない。
7. 「せや、DataOpsや」
8. アジェンダ • 自己紹介 • データ基盤で発生していた課題 • DataOpsとは • DataOps導入のアプローチ • まとめ
9. アジェンダ • 自己紹介 • データ基盤で発生していた課題 • DataOpsとは • DataOps導入のアプローチ • まとめ
10. 自己紹介 ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) CARTA HOLDINGS/CARTA MARKETING FIRM 開発局 データ部 部長 2024 Snowflake Data Superheroes
11. 今日話すこと • DataOpsがどういうシチュエーションで効くのか • 実務に適用する場合の攻め方
12. 話さないこと • 細かい話。（時間が足りない・・・ｗ）
13. アジェンダ • 自己紹介 • データ基盤で発生していた課題 • DataOpsとは • DataOps導入のアプローチ • まとめ
14. 弊社におけるデータ基盤の位置づけ 弊社には、複数の広告プロダクトを開発するチームが存在します。 各チームは自身のプロダクトに対して責任を持ち、 設計から実装までを一貫して担当しています。 データ基盤は、複数のプロダクトを横断したプラットフォーム的な 存在として位置付けられています。
15. データ基盤「Vision」 社のテックブログで、 どういうデータ基盤かについて、 詳しくまとめています。 Snowflake、dbtを使っている人には、 参考になる部分もあるかも？ https://techblog.cartaholdings.co.jp/entry/snowflake-data-platform-vision
16. 中央集権体制で始まったデータ基盤 データ基盤を用意するだけでは、データ基盤は使われません。 データマネジメントに精通してるわけではないプロダクトチームに、 いきなり委譲するのは現実的ではないため、 基盤チームがデータに関する意思決定プロセスに介入する体制にしていました。 これの狙いとしては、プロダクトチームとのコラボレーション推進、 強制力のあるプラクティスの標準化、 最終的に、スケール可能な基盤をゴールとして、 中央集権的な体制で、データ基盤を組織へ浸透させていきました。
17. データ基盤が動き出してから、 ちょうど一年くらい経ったタイミングで、 この体制のデメリットが目立ち始めます。
18. 中央集権の限界 データ基盤の活用が進み、データの種類が増加し、 ユースケースも多様化したことで、基盤チームが認知の限界を超え始める。 • dbtモデルが500個増加 • 分析、機械学習、レポーティングなど、多岐にわたるユースケース 例えばデータ品質一つをとっても、ユースケースに応じて 適切な管理方法は異なる上、ドメインも理解しなければ、 適切な判断ができません。このような意思決定全てに対して介入することは、 段々と負荷になってきて、最終的には無茶になりました。
19. 具体的な問題事例 ある軽微なdbtモデルのテスト失敗への対応でさえ、問題が顕在化しました。 基盤チームは、モデル（≒データ）に詳しくないので、 緊急度やテストの妥当性を判断できず、対応に手間取る。 一方、データの作成者は、モデルには詳しいので、 緊急度やテストの妥当性はわかりますが、 起きてる問題の原因の特定に、苦労していました。
20. なぜか？
21. 問題に対応するのに必要な情報が揃ってない 基盤チームが全てを把握してる内は良かったですが、 あるタイミングから、次のような状態になりました。 基盤チームはパイプラインには精通しているものの、 ドメインに関する知識が不足しています。 そのため、データの問題が発生した際、 データの内容について作成者に確認する必要があります。 一方、データ作成者はドメインには詳しいものの、 パイプラインへの理解が乏しいため、問題の原因を特定するためには、 基盤チームの助言を仰ぐ必要があります。
22. こういった積み重ねが、 業務全体のオーバヘッドになる。
23. コミュニケーションが必ず発生する 構造を壊す必要が出てきた。
24. 解決策を調べてたら、 DataOpsと出会った。
25. アジェンダ • 自己紹介 • データ基盤で発生していた課題 • DataOpsとは • DataOps導入のアプローチ • まとめ
26. DataOpsとは データ分析のプロセスを自動化・最適化し、 データの品質と利用可能性を向上させることで、 データドリブンな意思決定を促進し、 ビジネス価値の実現までのリードタイムを短くするための方法論です。
27. DataOpsフレームワーク 計画から監視までのライフサイクル 全体を通して、データチームと ビジネス部門が協力してより信頼性の 高いデータ分析を提供することを 目指します。 DevOpsのライフサイクルを 参考にしつつ、データの性質に 合わせて異なる技術やプロセスを 取り入れることで、データ品質の向上とイン サイトの迅速な提供を実現します。 https://www.montecarlodata.com/blog-what-is-dataops/
28. DevOps != DataOps DevOpsの成果物は、ソフトウェア。 DataOpsの成果物は、分析業務そのもの。 DevOpsは、ソフトウェア開発と運用の連携を強化し、 アプリケーションの構築・テスト・リリースの自動化を推進することで、 より迅速で効率的なソフトウェアデリバリを目指します。 一方、DataOpsは、データ分析ワークフロー全体の最適化に焦点を当て、 データの収集から分析、価値創出までのリードタイムを短縮することを目的として います。
29. DataOpsを実現する過程で、 DevOpsを当たり前に実施するので、 DevOpsよりも実現難易度は上がります。
30. アジェンダ • 自己紹介 • データ基盤で発生していた課題 • DataOpsとは • DataOps導入のアプローチ • まとめ
31. DataOpsになぜ取り組むのか。
32. DataOps導入の目的 分析業務を円滑に進めるために、 利用者の利便性とデータの品質を向上させることが目的です。 円滑な状態とは、適切かつ迅速にデータが提供され、 分析に集中できる環境が整っている状態を指しています。 ※以降、利用者はデータ基盤の利用者を指すものとします。
33. 円滑な状態とは、どのような状態か？
34. 利用者は価値創出に集中でき、 基盤チームは仕組み作りに集中できる状態である。 と定義しました。
35. 円滑な状態の実現 データに関する意思決定は、データのドメインを理解している データ作成者が行うことで、迅速かつ適切に行えるはずです。 仕組みに関する意思決定は、 基盤チームが幅広くユースケースを把握し、 実装に精通していることから、妥当な判断ができるはずです。 これらの性質を加味すると、それぞれの得意分野に注力することで、 円滑な状態を実現できる（はず）です。 この状態を実現することが、自然とDataOpsにつながると考えました。
36. DataOps実現のために 何をやっていくと良いか？を整理する
37. DataOpsフレームワー クで足りない要素を確認 まずは、弊社として取り組むべき部分を 整理しました。 https://www.montecarlodata.com/blog-what-is-dataops/
38. DataOpsフレームワークと当時の業務実態の比較 • Planning: データ作成者が計画・実行 • Development: データ作成者が構築（dbt, Terraform, Fivetran, etc..） • Integration: GitHubのmainブランチへのpushで自動反映 • Testing: dbt testでデータのテスト • Release & Deployment: GitHubのmainブランチへのpushで自動反映 • Operate: Snowflakeユーザーを払い出して、利用者に委ねる。 • Monitor: DataDog、Elementaryを使ってアラートを出している。
39. 実はかなりDataOpsを実践できていた。 では、何故うまく行ってる感がないのか。
40. 一つ、明確に課題がある領域があった
41. ラストワンマイルはDataObservability。
42. DataOpsにおけるDataObservability パイプラインの全段階で、データの鮮度、分布、量、スキーマ、リネージを 監視することで、データの品質と信頼性を理解し、 問題に先手を打って対処する能力のことです。 これにより、データのライフサイクル全体を通してデータの 健全性を把握し、信頼できるデータを提供することができます。 DataObservabilityは、DataOpsの戦略的な取り組みにおいて、 パイプラインの信頼性を確保するための中核的な役割を果たします。
43. DataObservabilityが解決すること 「なぜデータ更新されていないのか？」を答えるには、 様々な情報が必要です。 まず、データの鮮度が想定の範囲に 収まっているか、データパイプラインは正しく動き続けているのか、dbt testは 実施されているかなど。 問題発生時に原因を特定するのは簡単ではありません。 仮に何が起きているのかを、適切に回答できる仕組みがあれば、 問題の解決はずっと容易になるはずです。 そのような課題にDataObservabilityは非常に有効です。
44. まさに何が起きているのかを簡単に理解で きないことが、コミュニケーションを 発生させる原因だった。
45. どのようにDataObservabilityを実現するか？
46. 選ばれたのは、Elementary Cloud。
47. 灯台下暗しのElementary 実はElementary OSSは、1年間ほど使用しており、 主な利用者は基盤チームという状況でした。 これらを全利用者が使えるように整備し直すだけで、 DataOpsを支える仕組みが出来上がります。 いずれ必要になるだろうというのと、 基盤チームの運用にも必要不可欠だったので導入していたのですが、 まさかDataOpsへの移行時にも必要不可欠になるとは・・・
48. Elementary Cloudを日本で初導入 Elementary Cloudを採用しました。（日本で初めてだったらしい） 当初は基盤チームだけが使用する程度の想定だったので、 基盤の根幹を担うという位置づけではなかったElementary。 DataOpsへの移行をきっかけに、重要なコンポーネントになりました。 そのため、今後もElementaryの開発が継続されることが重要です。 Elementary Cloudを採用することで、 サービス継続に必要な資金を 提供しつつ、 密接なコラボレーションを実現することにしました。
49. 手札は揃った。 あとは、どのように体現していくか。
50. まず、「DataOpsを導入する」ことを周知。
51. 「DataOpsを導入する」ことの周知 データ基盤関係者に対し、 まず最初に周知を行いました。DataOpsと は何か、これまでの働き方がどう変わるの か、なぜ導入するのか などをDesignDocにまとめました。 実は今日の資料は、ほとんどこの DesignDocの内容そのままです。
52. ゴールは、データオーナーの 自律的な運用を可能にする基盤の構築。
53. 具体的なアクション（重要な点に絞って紹介） • データオーナーの明示化 • データの情報化 • DataObservabilityツールの民主化 • ドキュメンテーション
54. データオーナーの明示化
55. データオーナーの明示化 これまでも暗黙的に、データを作成した人がデータの管理を 行う雰囲気がありましたが、これを明示的に規定することにしました。 つまり、データを作成したチームが、そのデータの運用と説明責任を 負うということです。結局のところ、データのドメインに関して 最も詳しいのは、データを作成した人またはチームであるため、 その人たちに運用を任せることにしました。
56. データの情報化
57. データの情報化 データオーナーにデータの運用を任せる上で、 「ここのログを確認してください」といった、 仕組みに詳しくないと 対応できないようなオペレーションは徹底的に排除しました。 例えば、どのdbtモデルがどのようなコンテキストで 実行されたかといった情報は、サーバーのログを直接確認しなくても、 クエリやダッシュボードを見れば把握できる状態にしました。 このようなパイプラインに関する情報化は、 Elementary dbt artifactsが大いに役立ちました。
58. DataObservabilityツールの民主化
59. DataObservabilityツールの民主化 これは主にElementary Cloudに関連する内容ですが、 データ基盤チームだけが使用するツールから、 データ基盤に関わる全ての人々に公開する形に移行しました。 そのため、Elementary Cloudの使い方を、基盤チームだけでなく 様々な人が使用することを想定した方法に再設計しました。 ここに関して、話し始めると数時間くらい行きそうなので、 興味ありそうな人が多ければ、別の形でまとめるかも？
60. ドキュメンテーション拡充
61. ドキュメンテーション拡充 データ基盤の利用者が確実に増加するため、都度口頭で説明したり、 利用者に振る舞いをコードで、理解してもらうのは現実的ではありません。 そこで、よくある質問や全員が知っておくべきことはドキュメント化しました。 また、運用上の問題への対処方法を、誰でも読めば実行できる状態を目指し、 PlaybookやRunbookを整備しました。 ドキュメント化にはそれなりのコストがかかりましたが、 利用者だけで完結できる作業が大幅に増えたことや、暗黙知の減少、 ドキュメント作成過程での考慮漏れの発見など、良いことは多かったです。
62. アジェンダ • 自己紹介 • データ基盤で発生していた課題 • DataOpsとは • DataOps導入のアプローチ • まとめ
63. まとめ DataOpsは、分析業務のリードタイム短縮を目指す方法論であり、 DevOpsとは異なる概念です。 導入には利用者の責務増大を伴うことがあるため、環境整備が不可欠です。 また、安定運用にはDataObservabilityが鍵となります。 弊社では、データ作成者への意思決定権委譲という形で、 DataOpsを実現していってます。 まだまだ、道半ばですがこれからも頑張ります。
64. もっと詳しく話聞きたい？
65. 「DATA ENGINEER NIGHT #0」やります！！！！！ https://cartaholdings.connpass.com/event/313401/