Amebaのデータマネジメント戦略 : 地道な実践と進化の軌跡

データを適切に活用するためには、データマネジメントが欠かせません。しかし、そのために必要な取り組みは非常に多岐にわたり、無計画に進めることはできません。AmebaのデータマネジメントチームはDMBOKを基本方針として採用し、それに独自の解釈を加えて取り組みを進めてきました。データマネジメントの取り組みを進化させデータの活用を強化するためにどのように取り組んできたのか、地道ながらも面白い活動の軌跡についてご紹介いたします。

Transcript

1. Amebaのデータマネジメント戦略 地道な実践と進化の軌跡 加藤　寿明 CA DATA NIGHT #2 2023/12/07
2. 加藤 寿明（かとう ひさあき） 自己紹介 • 2023年03月中途入社 • Amebaでデータマネジメント • 好きなもの：お酒 / 料理 / 旅行 株式会社サイバーエージェント > メディア統括本部 > Data Science Center (DSC) @hisaaki__k
3. 1.Amebaについて 2.何をやることにしたのか 3.具体的な取り組みの紹介 4.取り組みの評価 5.最後に
4. 1. Amebaについて
5. Amebaについて https://speakerdeck.com/kakerukaeru/the-road-to-ameba-system-renovation-aws-summit-online?slide=5
6. Amebaについて https://ameblo.jp/ ライフログを中心とした 日本最大級のブログメディア 240種以上の装飾でお洒落な ブログが簡単にかける 毎月約45,000人の方が ブログでおこづかい稼ぎ中
7. Amebaについて https://www.cyberagent.co.jp/news/detail/id=29417 2024年09月には20周年を迎える
8. 歴史が長いサービス 蓄積されているデータは膨大 データフローも複雑 Amebaについて
9. Amebaについて 当然、大きなデータ負債※も抱えている ※ https://johnladley.com/a-bit-more-on-data-debt/
10. Amebaについて 専任のデータマネジメントチーム が立ち上がっており データをキレイにしたい意思は強い
11. 今日話すこと そんな歴史あるAmebaというサービスで データをキレイにするためにデータマネジメントチームが どんな活動をしてきたのか、 その具体事例を共有できたらと思っています ※ 正直かなり地味で地道な話です。
12. • データマネジメントってなに？ • 何のためにやるの？(その重要性や意義) • チーム立ち上げや社内認知の拡大など 割愛させていただくこと
13. 話すことイメージ 立ち上げ 運用 改善 データマネジメント活動の流れ ココらへん
14. 話すことイメージ 立ち上げ 運用 改善 データマネジメント活動の流れ ココは 別セッション※にて ※セッション3：「データ活用で事業貢献するためのデータマネジメント立ち上げ」
15. 2. 何をやることにしたのか 　 何を(今は)やらないことにしたのか
16. データマネジメント業務は幅広い 01. データガバナンス 02. データアーキテクチャ 03. データモデリング 04. データ統合と相互運用性 05. データストレージとオペレーション 06. データウェアハウジングとBI 07. 参照データとマスターデータ 08. データ品質 09. ドキュメントとコンテンツとメタデータ※ 10. データセキュリティ ※ 独自解釈による
17. とにかくやればいいわけではない 全部やるぞ、、、気合いで！！
18. とにかくやればいいわけではない 何をやるべき (やらないべき) か 一定の軸から注力領域を決める必要がある
19. 大きく4つの観点 1. データ利用者の観点 2. DMBOKの成熟度観点 3. 組織的な観点 4. Peter Aikenのフレームワーク観点 Amebaの注力領域を決める軸
20. データは利用されて初めて価値を生む • データ利用者の満足度 (利便性) に直結する領域は注力 した方が良さそう • 言い換えればこれは成果の見えやすさでもある 　 データマネジメントの成果をアピールしやすい 例. データ統合 データを使いたい時に使いやすく利用するためには移動の管理は必須。 恩恵を受ける利用者も多かった。 1. データ利用者の観点
21. データは利用されて初めて価値を生む • 逆に言えば利用者の利便にすぐに直結しない領域は 今は注力しなくても良さそう (注力しない≠何もしない) 例. データセキュリティ もちろん超重要。けれど前提として利用規約に即したデータしか流さないように なっているなど最低限のルールはあり、比較的後回しでも良さそう 1. データ利用者の観点
22. 2. DMBOKの成熟度観点 成熟度の観点 レベル0 遂行能力がない状態 レベル1 場当たり的な状態 レベル2 標準化された状態 レベル3 自動化された状態 レベル4 拡張可能な状態 情報公開 わからない 公開されていない 公開されている 自動化について公開されている 他の事業で実施できている 情報理解 わからない 1人以上が把握できている データ活用者が把握できている 自動化がデータ活用者が把握でき ている 他の事業で実施できている 再現性 わからない ない（属人的） データ活用者が反復可能、再現可 能。 自動化される (成果物が自動生成される) 他の事業で実施できている 責任の所在 わからない 明確ではない 明確になっている 自動化について明確になっている 他の事業で実施できている ニーズ わからない 明確ではない 整理され、ガバナンスと関連づけ られている 自動化について整理され、ガバナ ンスと関連づけられている 他の事業で実施できている 育成 わからない 自ら調べることができず誰かに問 い合わせが必要 活用者が自ら調べることができる 自動化について活用者が自ら調べ ることができる 他の事業で実施できている 技術 わからない ツールの標準機能など何かが実施 できる状態 技術選定をして必要なことが実施 できる状態 自動化について技術選定をして必 要なことが実施できる状態 精度を上げるための取り組みがで きている状態 独自の成熟度レベル※に従って現状を分析 ※セッション3: 「データ活用で事業貢献するためのデータマネジメント立ち上げ」にて詳しく
23. 2. DMBOKの成熟度観点 成熟度レベルの底上げのために レベルが低い領域は注力した方 が良さそう 右図は実際の運用初期の成熟度 アセスメント結果 (比較的レベルが低いと読み替えてください。お願いします。)
24. • 実は大規模なデータ基盤刷新プロジェクトが動いており、 組織の事情で優先度が高いので、関係する領域も注力度が 高くなっていた • 加えてそのタイミングで大きなデータ負債を返すチャンス でもあった 例えばログデータ(領域で言えばデータ品質) スキーマがない、スキーマ通りでない、値の意味が不明、、、etc 3. 組織的な観点
25. 4. Peter Aikenのフレームワーク観点 https://blogs.sap.com/2020/07/09/why-hr-data-management-strategy-is-important-in-your-hr-transformation/
26. 大きく4つの観点 1. データ利用者の観点 2. DMBOKの成熟度観点 3. 組織的な観点 4. Peter Aikenのフレームワーク から注力領域を決めた Amebaの注力領域を決める
27. 2. 具体的な取り組みの紹介 　 データ転送経路の移行・統合 ※ その他の領域の取り組みはぜひ懇親会で聞いてください！！
28. Amebaのデータフロー概観 ※ かなり簡略化して描いてます
29. ※ かなり簡略化して描いてます 様々なデータがオンプレのデータ レイクに投げ込まれている (歴史的経緯) Amebaのデータフロー概観
30. ※ かなり簡略化して描いてます オンプレのデータを ・Hive → BigQuery転送 ・BigQuery → BigQuery転送 して利用 (※ココをメインで話します) Amebaのデータフロー概観
31. Amebaのデータフロー概観
32. どんな課題があったのか？ Amebaのデータフロー概観
33. オンプレとGCPに跨っていること でツールの一貫性がなく 利用者にとって扱いづらい データフローについての課題
34. 管理者がバラバラで 責務範囲で明確でない オンプレ 基盤チーム データマネジメント チーム データフローについての課題
35. データフローについての課題 アナリストが私的に利用していた Digdagが重要な転送を担うように なってしまっていた
36. そのほか課題は色々 データフローについての課題
37. ジョブ管理についての課題 ジョブの設定やクエリは個人管理だった
38. ジョブ管理についての課題 ジョブの設定やクエリは個人管理だった 属人性が高くナレッジ共有されない 他の人がどんなクエリを 書いているかわからない
39. ジョブ管理についての課題 ジョブの設定やクエリは個人管理だった ドキュメント文化も無く、退職・異動に よって容易に謎ジョブが発生する ？ ？
40. ジョブ管理についての課題 ジョブの設定やクエリは個人管理だった エラーが出ても調査されないジョブが現れる このジョブずっとエラー出て ますけど、どうなってます？ もう使ってないです！ (止めといてください)
41. ジョブ管理についての課題 ジョブの設定やクエリは個人管理だった クエリレビューを経ないので当然 間違いもありうる クエリが、、、 なんか数値おかしいので 確認してもらえます？
42. 課題まとめ • 環境によって統一されないツール • 歴史的経緯もあり明確でない責務範囲 • 管理されず氾濫するジョブたち
43. 課題まとめ • 環境によって統一されないツール ◦ ツール統合したい • 歴史的経緯もあり明確でない責務範囲 ◦ Amebaのデータ転送はAmebaで管理したい • 管理されず氾濫するジョブたち ◦ ジョブの管理と運用ルール整備したい
44. 課題を解決するためのステップ 1. 統合管理できるツールの導入 2. ジョブの氾濫を防ぐ運用ルールを整備 3. データ利用者への布教 4. 既存ジョブの棚卸・移行
45. 要件 • Hive→BigQuery、BigQuery→BigQueryの転送が可能 ◦ できれば1つのツールで管理したい • ワークフローとしての基本機能 (slack通知、自動リトライ、依存関係の考慮など) • ジョブの登録が容易 (クエリと設定値) 1. ツール導入のために要件を整理
46. ツール案 • GCP製品 ◦ Cloud Composer ◦ Cloud Dataflow • 内製 ◦ 全社データ基盤チームが開発していた新バッチ処理システム 1. 統合管理できるツールの導入
47. ツール案 • GCP製品 → オンプレHiveが扱いづらい ◦ Cloud Composer ◦ Cloud Dataflow • 内製 → (管理主体が別チームだが) ツール統合できて利点も多い ◦ 全社データ基盤チームが開発していた新バッチ処理システム 1. 統合管理できるツールの導入
48. • ワークフローの基本的な実行制御にはArgo Workflowsを使用 • それを元に機能拡張 (slack通知、backfill実行など) している • KubernetesのCRDリソースとしてワークフローを管理運用 1. 内製の新バッチ処理システム
49. • オンプレHiveへのクエリ実行などの処理のテンプレート化が行いやすい • ワークフローはk8sのNamespace単位での管理・運用 ◦ yamlベースでNamespaceごとに管理・拡張できる ▪ Amebaもその1つをカスタマイズして利用 ◦ ジョブの管理のみ (≠実行基盤) に集中できる • yamlデータのためyttなどを活用してOverlay処理などを柔軟に適用できる 1. 内製の新バッチ処理システムの利点
50. • ジョブの登録に必要なものはクエリ(SQL)と設定値(yaml)のみ 1. 内製の新バッチ処理システムの利点
51. 最低限の記述 設定値(yaml)はyttによって必要な Data Valuesの設定およびOverlay 処理が行われるのでジョブ登録時 は最低限の設定だけで済む 1. 内製の新バッチ処理システムの利点
52. 全社データ基盤チームが開発していた 内製の新バッチ処理システム への移行・統合を決定 1. 統合管理できるツールの導入
53. 担当者の明確化 ジョブ担当者の記入を必須設定 にすることで、不 明なジョブの 発生を防止した。 実際にはSlackのIDをセットし 失敗時はメンションが飛ぶ 2. ジョブの氾濫を防ぐ運用ルールを整備
54. テーブル依存関係の明確化 依存関係考慮のための設定ができ、 設定値がそのまま関係の明確化に つながる (コードを見れば分かる状態) 2. ジョブの氾濫を防ぐ運用ルールを整備
55. ジョブとディレクトリ構造を関連付け ジョブの転送先テーブルとそのクエリ・設定値yamlを格納する ディレクトリを以下のようなルールで1対1に紐付けており、 ディレクトリ構造を見ればどのテーブルを更新するジョブか分かる ${GCPプロジェクト名}/${データセット名}/${テーブル名}/ 2. ジョブの氾濫を防ぐ運用ルールを整備
56. GitHub管理 これらのコードはGitHubで管理され、必ずデータマネジメント チームのコードレビューを受ける運用 2. ジョブの氾濫を防ぐ運用ルールを整備
57. レビュー項目に最低限のメタデータ確認を盛り込んだ 2. ジョブの氾濫を防ぐ運用ルールを整備
58. CIでsqlfluffを回し、SQLコーディングの品質を担保 2. ジョブの氾濫を防ぐ運用ルールを整備
59. ジョブ棚卸フローを整備し不要なものは削除するように 2. ジョブの氾濫を防ぐ運用ルールを整備
60. 3. データ利用者への布教 • 運用ルールは整えたが、ビジネス職メンバーも各種 ジョブを利用しており、普段GitHubを利用しない メンバーにとってはハードルが高い • 結果、そもそも利用されなくなっては意味がない
61. 3. 布教方法その１ - 説明会の実施 ざっくり以下を説明 • 現在どんな課題があってどう解決されるのか • どんなメリットがあるのか • どんな運用にしていこうとしているのか
62. 対面でGitHub上での操作を一緒に実行し慣れてもらった (複雑なことでなければ) また同じようにできる経験作り 3. 布教方法その2 - ペア作業の実施
63. • ペア作業などで得たフィード バックを含め、ドキュメント (手順書)を改修し続けた • 現在では手順部分だけで30枚 ほどのスクショが貼ってある 3. 布教方法その3 - ドキュメント整備&整備
64. 3. 布教(?)方法その4 - 権限変更による強制管理 旧ジョブシステムを作成する権限をメンバーから剥がし、 そもそも新システム以外にジョブを登録できなくした
65. 最後は既存ジョブを棚卸 & 新システムへの移行作業 • 個人管理の雑多なジョブが100以上 ◦ クエリや設定の書き換えが必要なジョブたくさん ◦ すでに利用されていないジョブいっぱい ◦ 担当者不在で謎となったジョブ少々 気合いでがんばる 4. 既存ジョブの棚卸・移行
66. ヒアリングしてターゲットを絞り、あとはひたすら移行していく 4. 既存ジョブの棚卸・移行
67. 結果どうなったか ツールの統合、運用見直しによって課題はほぼ解消された
68. 結果どうなったか 活用観点で • 自動リトライや失敗時の通知など利便性の向上 • メタデータ管理によるデータ利用しやすさの向上 • クエリレビューを通すことによる間違いの防止 • ただしGitHubなどジョブ登録のハードルが上がった
69. 結果どうなったか 運用観点で • ジョブの一元管理による管理性の向上 • 棚卸フローによる無駄防止・コストカット • レビューや問い合わせ対応による対応工数は増加
70. 4. 取り組みの評価
71. • 前述の成熟度評価を定期的に実施 • 右図は取り組み前 (再喝) 成熟度で見るデータマネジメントの進化
72. • データ統合以外にも取り組みを進めており、 各領域の成熟度が上がってきている or 来期に向けて上げる準備ができている 成熟度で見るデータマネジメントの進化 ◼前期 ◼今期 ◼来期(計画)
73. 成熟度で見るデータマネジメントの進化 • 成熟度評価 → 計画 → 実行のサイクルが回り始 めており、チームとしてデータマネジメントに 戦略的に取り組めるようになってきた ◼前期 ◼今期 ◼来期(計画)
74. 5. 最後に
75. • 運用ルールを決めよう • ポリシーを定義しよう • ヒアリングをして洗い出そう • ドキュメント書こう • ガバナンスを効かせて氾濫を防ごう …etc 地味で地道なことも多いデータマネジメント
76. データマネジメントがなければ • データが扱いづらい・扱える状態じゃない • データ活用が全然進まない • 正しくないデータで間違った結果を得てしまう 与える影響は全然地味じゃないデータマネジメント データ活用するためにデータマネジメントはとても大事
77. • 歴史が長く、膨大なデータが蓄積されている • まだまだ整備するべきことは山ほどある そして何より • データ活用意欲が高く、快く協力してくれるメンバーが多い Amebaのデータマネジメント データ活用、データマネジメントを進めるにはとても面白い環境
78. サイバーエージェントでは 一緒に挑戦する仲間を募集中です！ ✔オンラインでカジュアル面談実施中 ✔今すぐ転職を考えていなくてもOK！ 詳しくはコチラから👉
79. ありがとうございました