DataOps実現への道筋 持続可能な運用体制の構築 / journey-to-dataops

データ利活用のミソ DataOps実現のための取り組みとは？ Lunch LT
https://findy.connpass.com/event/323727/

Transcript

1. DataOps実現への道筋 持続可能な運用体制の構築 適材適所で協業するデータ活用へ データ利活用のミソ DataOps実現のための取り組みとは？ Lunch LT
2. DataOpsとは データ分析のプロセスを自動化・最適化し、 データの品質と利用可能性を向上させることで、 データドリブンな意思決定を促進し、 ビジネス価値の実現までのリードタイムを短くするための方法論です。
3. リードタイムを短くするために何をするか。
4. データの利用者は価値創出に集中でき、 データ基盤チームは仕組み作りに集中できる状態を作る。 ※弊社の定義
5. DataOpsへの転換 DataOpsが必要になった背景は、 過去の資料で詳しく話しているので、 どういう局面で必要になるかを 知りたい方は、こちらのスライドを 参照してください。 https://speakerdeck.com/pei0804/centralized-to-dataops-transformation
6. DataOpsはいいぞと言われても、 実際なにやったらいいの？
7. 今日は養殖ではない本物の現場で、 実際にやったことを余さず話します。
8. アジェンダ • 自己紹介 • データで振り返る当時の状況 • 効果的だった5つの施策
9. 自己紹介 ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) VP of Data @ CARTA MARKETING FIRM / CARTA HOLDINGS 2024 Snowflake Data Superheroes
10. 本日の内容 • 実際の現場でのDataOps導入で効果的だった施策の共有
11. 本日話さないこと • DataOpsの概念的なところ。 • 施策の一つ一つの具体的な実装。
12. アジェンダ • 自己紹介 • データで振り返る当時の状況 • 効果的だった5つの施策
13. DataOpsが必要になったあの頃。
14. データ基盤チーム: 3名（2024年7月に1名増えたました🎉🎉🎉） データオーナー: 10名+- 少ない週で10PR/week。多い週で50PR/week。 データ基盤の週ごとのリリース状況(2023-10~2024-07) DataOpsを考えはじめた時期
15. データ基盤の週ごとのリリース状況(2023-10~2024-07) データオーナー（黄色）によるリリースが 10PR/weekを安定して超えはじめた頃でした。 DataOpsを考えはじめた時期
16. 正直、認知の限界が来ていて、 本格的に回らなくなる前に、なんとかせねば。 当時はそういう状況でした。
17. データオーナー 20PR/week
18. DataOps戦略の立案 2023年11月15日。
19. 基盤チーム 35PR/week
20. 実際の運用に 乗りはじめたとのは、 戦略立案から3ヶ月後の 2024年2月19日。
21. アジェンダ • 自己紹介 • データで振り返る当時の状況 • 効果的だった5つの施策
22. ゴールは、データの利用者は価値創出に集中でき、 データ基盤チームは仕組み作りに集中できる状態を作る。 ※再掲
23. データ利用者が、データを自ら運用して、 意思決定できている状況を作る。 そのための足りない要素を、ひたすら整える。
24. 効果的だった5つの施策 1. ツールの導入 2. データオーナーの確立 3. Slackチャンネルの再設計 4. データ品質向上 5. Playbookの整備 実際のDataOpsの推進施策は、この順番で進めました。 なぜこの順番なのかは、それぞれのセクションで説明します。
25. 1. ツールの導入
26. ツール導入がもたらす戦略的意義 何よりも時間と人的リソースを大幅に節約しつつ、 数週間でDataOpsに必要なインフラを本番に導入できる点が重要です。 さらに、ツールが示すベストプラクティスを採用することで、 自然とアンチパターンを避け、効果的な施策を実行しやすくなります。 ただし、適切なツールを選択する目利き力は不可欠です。
27. 私の「使える」ツールを見極める4つの視点 • ドキュメントの可読性。 ◦ 読みやすさはツールの使いやすさを反映している。 • 開発元とのコミュニケーションの相性。 ◦ 頻繁に共感できる応答がある場合、長期的な協力関係が期待できる。 • 将来性。 ◦ 今後のロードマップに共感できるか。 • 費用対効果の高さ。 ◦ 重要な課題を解決できる場合、多少値が張っても安いと感じるものです。
28. DataOpsに向けて本格導入したツール ※実は既に導入していた。
30. Elementary Cloud dbt native データオブザーバビリティサービス dbtとシームレスに統合できるデータオブザーバビリティサービスです。 dbtを使っていれば、学習コストを低く抑えられることを意味しています。 主な機能は、異常検知テスト、自動モニタリング、データリネージ、 ダッシュボード、Slackアラートなどがあります。 dbtコード内で設定を管理でき、UIでの設定作業が不要な点が魅力的です。 加えてElementaryが提供するメタデータは運用上、 非常に利便性の高いものが多いので、そこもおすすめです。
31. Elementary Cloudを採用している理由 OSS版でも十分な機能がありましたが、 Cloud版の開発初期段階(β版)から参画することでアドテク特有のニーズに 対応できる可能性がありました。（実際に反映されました） もちろんロードマップも魅力的でした。（2023年時点） また、dbtネイティブなオブザーバビリティサービスは弊社にとって 重要なコンポーネントになると確信し、投資価値があると判断しました。 ※詳細な導入経験は後日記事にまとめる予定です。
33. SELECT (SaaS版) Snowflakeコスト最適化 & 可視化サービス Snowflakeの使用状況を深く可視化し、効果的なコスト管理を実現。 年間Snowflake支出の3%という明確な料金体系で、 請求額以上のコスト削減を保証。自動化された節約機能により、 導入だけで10-30%のコスト削減が可能。 多種多様なユーザーが使うからこそ、コストがかかりやすいデータ基盤の コストパフォーマンスを、わずか15分の導入で最適化できます。 効果絶大で2年目も契約更新。データ基盤運用者必見のサービスです。
34. SELECTを使った コスト可視化、最適化 どういう事業背景で、 実際にどういう課題を解いたか 気になった方は、 こちらの記事を御覧ください。 せっかく契約更新したので、 今度それについてもまとめる予定です。 https://techblog.cartaholdings.co.jp/entry/select-cloud-cost-optimize-cmf
35. 次なる課題: データオーナー データ基盤で起きている問題が見えるようになりました。 しかし、発見した問題の適切な対応者を特定することが 困難であるという新たな課題が浮き彫りになりました。 これは、データの責任所在が不明確であることに起因していました。 効率的なデータ管理と迅速な意思決定を実現するためには、 明確な責任体制の確立が不可欠です。 そこで次のステップとして、データオーナーの確立に取り組みました。
36. 2. データオーナーの確立
37. データオーナーの役割 作ったモデルを、自ら運用管理する。 具体的には以下のような責任を担います。 • モデルの品質管理と不具合対応を主導。 • モデルの仕様とロジックに対して、説明責任を負う。 • 実装、テスト、リリース、コスト最適化を実施。
38. dbtのmeta.ownerを使ったデータオーナー管理 dbt_project.ymlの例 models: jaffle_shop: +meta: owner: "@alice" models/schema.ymlの例 models: - name: users meta: owner: "@alice" ツールと連携 Elementary Cloud SELECT dbt-core
39. 次なる課題: Slackチャンネル データオーナーを設定し、データの責任所在が明確になりました。 しかし、既存のSlackチャンネル設計では、 基盤チーム向けとデータオーナー向けの通知が混在していました。 そのため、各役割の人々がどのチャンネルの通知を重点的に見るべきかが不明確でした。 効率的な情報伝達のため、各役割に必要な情報を伝達する環境整備が必要となりました。 そこで次のステップとして、Slackチャンネルの再設計に取り組むことにしました。
40. 3. Slackチャンネルの再設計
41. Slackチャンネル再設計の目的と要件 データオーナーと基盤チーム、それぞれがほしい情報が違うため、 それぞれのほしい情報を集まる場所を作る。 • データオーナーが担当領域の問題を迅速に把握 ◦ 例: モデルの問題の早期発見 • 基盤チームがシステム全体の状態を迅速に把握 ◦ 例: データパイプラインの問題の早期発見
42. 実際に行ったSlackチャンネルの再設計 • 基盤チーム向け（#info, #warning, #error, #emegency） ◦ 目的 ▪ システム全体の把握を素早くできる。 ◦ 効果 ▪ 基盤チームに特化した作りにできるようになった。 • 役割が曖昧な時はオーナーへのノイズを気にしていた。 • データオーナー向け（#data_monitoring） ◦ 目的 ▪ モデル関連問題を一元管理。 ◦ 効果 ▪ ここだけ見ればいい状態になり、情報の取捨選択が簡素化。 ▪ チーム間のナレッジシェア。
43. Elementaryの通知例 設定されたownerを使って、 Slackで通知を制御できる。 ownerをSlackグループにしておくと メンションもしてくれるので、 気づいてほしい人たちに、 情報を確実に届けることができる。
44. SELECTのコスト通知 SELECTには、User Groupという概念 があり、リソースをグルーピング できます。 これとdbtで設定したownerの設定が 連携できるので、自分たちのモデルが どれだけのコストがかかっているかを 簡単に把握することができます。
45. 次なる課題: データ品質向上 Slackチャンネルの再設計により、 発生している問題の迅速な伝達が可能になりました。 次に、そもそも問題が発生しにくい環境の整備に着手しました。 具体的には、データ品質向上に取り組みました。 これにより、より安定したデータ運用環境を目指します。
46. 4. データ品質向上
47. データ品質の向上のために行ったアプローチ • データ設計ガイドラインの確立 • 多層的なデータ品質テスト戦略 • インテリジェントなレビュープロセス
48. データ品質の向上のために行ったアプローチ • データ設計ガイドラインの確立 • 多層的なデータ品質テスト戦略 • インテリジェントなレビュープロセス
49. データ設計ガイドライン 一貫性のあるモデリングを促進し、 初期段階での品質向上を図る指針です。 高品質なデータ設計が分析プロセス全体 の効率を大幅に向上させます。 このガイドラインの導入により、 組織全体のデータ品質の底上げを 図っています。 社内向けのドキュメントで現状非公開
50. 良いデータを作る意義 データの設計の重要性については、 こちらの発表で説明しています。 興味がある方は是非御覧ください。 https://speakerdeck.com/pei0804/modeling-over-shiny-tech
51. データ品質の向上のために行ったアプローチ • データ設計ガイドラインの確立 • 多層的なデータ品質テスト戦略 • インテリジェントなレビュープロセス
52. データ入力の信頼性確保 dbt freshness 鮮度テストの実装は、信頼性の高いデータパイプライン構築の第一歩です。 これにより、後段のモデルテストの有効性が担保され、 問題の早期発見と切り分けが容易になります。 鮮度テストは問題の即時検知を可能にし、デバッグプロセスも簡素化します。 例えば、何らかのテストが失敗した場合、鮮度テストの結果によって問題の 所在を特定できます。鮮度テストが失敗していれば外部要因の可能性が高く、 通過していればデータパイプライン内の問題と推測できます。 この切り分けにより、トラブルシューティングの効率が大幅に向上します。
53. 基本的なデータ整合性の検証 dbt generic data test dbtのgeneric data testは基本的なデータ品質保証の要です。 特にビジネスキーに対するuniqueとnot_nullテストは必須であり、 これだけでも多くのデータ問題（ファントラップ等）を防げます。 弊社だと、全カラムへの網羅的なテスト適用はコスト効率が悪いため、 ビジネス上クリティカルな部分に焦点を当てるようにしています。 ※事業特性に応じて適切に判断しましょう。
54. ビジネスロジックに基づく高度なデータ検証 複雑なビジネスルールや特殊なデータパターンの検証には、 dbt expectationsなどの専門パッケージを活用します。 これらの高度な検証は、基本的なテストで対応できない課題が明確に なった時点で段階的に導入します。 過度に複雑なテストを早期に導入すると、 維持管理の負担が増大し、効果が低下する可能性があります。
55. データ品質の向上のために行ったアプローチ • データ設計ガイドラインの確立 • 多層的なデータ品質テスト戦略 • インテリジェントなレビュープロセス
56. CIによる品質保証 機械的判断可能な部分を徹底的に 自動化し、品質の一貫性を確保。 人為的ミスやばらつきを排除し、 開発プロセスの信頼性を向上。 一貫性の維持がユースケース増加時の パターン認識を容易にし、 長期的な拡張性に貢献。 詳しくは記事を御覧ください。 https://techblog.cartaholdings.co.jp/entry/snowflake-dbt-data-platform-vision
57. AIを活用したレビュー CIでは捉えにくい潜在的リスクを自 動検出。 意図しない破壊的変更や 判断を要する箇所を特定し、 開発者に再考を促す。 詳しくは記事を御覧ください。 https://techblog.cartaholdings.co.jp/entry/pr-agent-dbt-code-review-automation
58. 次なる課題: Playbookの整備 データ品質向上施策後に、問題対応プロセスの個人知識に依存している 問題が浮上しました。これは、dbtへの理解度の違いで起きる問題です。 この課題に対処するため、基本的な対応手順を明記したPlaybookを 整備し、問題対応の均一化、そして知識の共有を目指しました。
59. 5. Playbookの整備
60. Playbookの目的と効果 Playbookは、データ運用の標準化された指針です。 主な目的は • 問題対応の一貫性確保。 • 組織的な知識共有。 • ベストプラクティスの文書化。 手順と判断基準を明確化し、データオーナーのスキル向上を促進します。 結果として、問題対応の迅速化と運用品質の向上を実現します。
61. データオーナー向けに用意してるPlaybook例 社内向けのドキュメントで現状非公開
62. 6. 継続的進化
63. 継続的進化（まとめ） DataOpsに終着点はなく、常に新たな最適化の機会が生まれます。 その時々の最善策を追求し、アジャイルに実践することが重要です。 この継続的な進化のプロセスを通じて、 組織のデータ活用能力とビジネス価値の創出を着実に 向上させていくことがDataOpsの本質だと考えています。
64. 8/21に「みんなの考えた最強のデータ基盤アーキテクチャ」に登壇します。 発表内容は、「（仮）データ基盤が安定稼働した先にあるデータエンジニアリングの世界線。」 https://datatech-jp.connpass.com/event/319827/