What is DRE? - Road to SRE NEXT@広島

Slide 1

Slide 1 text

2024/07/20 Yu Nakamura - chanyou What is DRE? @chanyou0311

Slide 2

Slide 2 text

Yu Nakamura - chanyou ● スタートアップでデータエンジニアとして交通データ分析基盤の構築‧運⽤を経験 ● その後2024年3⽉に株式会社タイミーの DRE チームにジョイン ● モデリング済みのデータを各種ツールに送出する Reverse ETL の実装などを担当 ● 広島在住。趣味はおうち Kubernetes クラスタ ● YAPC::Hiroshima 2024 のスタッフなども

Slide 3

Slide 3 text

タイミーとは 3 ｢働きたい時間｣と｢働いてほしい時間｣をマッチングするスキマバイトサービス従来の「求⼈サイト」でも「派遣」でもない

Slide 4

Slide 4 text

タイミーの特徴 4

Slide 5

Slide 5 text

タイミーの実績スキマバイト No.1 ※1 ※2 [調査⽅法]インターネット調査 [調査期間]2024 年 2 ⽉ 9 ⽇~11 ⽇ [調査概要]スキマバイトアプリサービスの実態調査 [調査委託先]株式会社マクロミル利⽤率 ‧リピート率 ※1 ※2 導⼊事業者数 98,000企業ワーカー数 700万⼈

Slide 6

Slide 6 text

DRE とはなにか？

Slide 7

Slide 7 text

DRE とは ● Data Reliability Engineering の略 ○ データの信頼性を確保する新しいアプローチのこと ● SRE のプラクティスをデータに適⽤する試み

Slide 8

Slide 8 text

目次 ● DRE チームが担う役割 ● データの信頼性とは ● DRE チームで実践しているプラクティス

Slide 9

Slide 9 text

1 DRE チームが担う役割

Slide 10

Slide 10 text

DRE チームのミッション “私たちDREは、DataOpsによる、パイプライン構築、⾃動化、監視、デプロイメントの迅速化、データ品質の向上などの取り組みにより、信頼性（スピード、品質‧安定、ユーザビリティ）の⾼いデータ基盤プロダクトをユーザに提供します。”

Slide 11

Slide 11 text

タイミーにおけるデータのライフサイクル

Slide 12

Slide 12 text

ワークフロー管理‧Extract / Load

Slide 13

Slide 13 text

データクレンジング

Slide 14

Slide 14 text

Reverse ETL

Slide 15

Slide 15 text

モニタリング

Slide 16

Slide 16 text

リソース管理‧IAM

Slide 17

Slide 17 text

DRE が連携する社内関係者 ● データを扱うチーム ○ アナリティクスエンジニア ○ データアナリスト ○ データサイエンティスト ● プロダクト‧エンジニアリング本部 ○ Dev Platform Squad ○ その他 Squad

Slide 18

Slide 18 text

DRE が連携する社内関係者 ● マーケティング部⾨ ○ toC toB の両⽅にアプローチ ■ ユーザーマーケティング ■ クライアントマーケティング ● 営業部⾨ ○ 600名を超える営業組織 ○ セールスシステム ● コーポレート部⾨ ○ 法務 ○ セキュリティ

Slide 19

Slide 19 text

社内の全⽅位と向き合う必要がある ● 部署で使うデータはどこから供給されるのか？ ○ 外部SaaSなのか、当社プロダクトなのか ○ いつ、どのように供給されるのか ● 供給されたデータは、いつどのように使われるのか？ ○ 毎⽇参照されるのか、⽉次で参照されるのか ○ システム連携したいのか、意思決定を伴うのかデータの理解も重要だが、組織と業務プロセスの理解がより重要

Slide 20

Slide 20 text

2 データの信頼性とは

Slide 21

Slide 21 text

信頼性が低下すると ● Webアプリケーションにおいて信頼性が低下すると ○ 「アクセスできないよ…」 → リクエストの可⽤性 ○ 「サイト重くない？」 → リクエストのレイテンシ ● ⼀⽅、データ基盤において信頼性が低下すると ○ 「昨⽇まで⾒れてたダッシュボードが今朝から表⽰できなくなったよ…」 ○ 「前⽇分のデータがまだダッシュボードに反映されてないよ…」 ○ 「なんかデータ、ダブってない？」

Slide 22

Slide 22 text

DMBOK を拠り所にデータの信頼性を紐解く ● データマネジメント知識体系ガイド第⼆版 [⽇経BP社] ○ 様々なデータ品質の評価軸が紹介されている

Slide 23

Slide 23 text

タイミーで重視しているデータ品質の評価軸特性定義完全性⽋損したデータの割合適時性データ参照時と現実のデータとの時間差⼀意性重複したデータの割合⼀貫性型、タイムゾーン、表記揺れなどの値の書式が統⼀されていない割合

Slide 24

Slide 24 text

その他のデータ品質 ● メタデータ ○ テーブルやカラムの意味や制約などの補⾜情報 ● データガバナンス ○ 最⼩権限の原則 ● データダウンタイム ○ データが⽋落したり不正確な状態の期間

Slide 25

Slide 25 text

（参考）データ品質がテーマの発表資料 https://speakerdeck.com/ttccddtoki/dmbokwocan-kao-nisitadetamanezimentonoqu-rizu-mi

Slide 26

Slide 26 text

3 DRE チームで実践しているプラクティス

Slide 27

Slide 27 text

DRE チームで実践しているプラクティス ● ワークフローのステータス監視 ● データの外形監視 ● dbt によるメタデータ整備とテスト

Slide 28

Slide 28 text

ワークフローのステータス監視 ● ワークフローが失敗した場合にアラートを受け取る ○ 原因の切り分け、影響範囲の調査などの対応

Slide 29

Slide 29 text

データの外形監視 ● 定期的に転送前後のデータセットの⽐較を⾏う ○ テーブルごとに完全性、適時性、⼀意性が満たされているか検査する ■ 満たさない場合はアラートを受け取る ○ データソースの新規テーブルやカラムの検知も⾏う ● 具体例 ○ 転送元: プロダクトの RDB ○ 転送先: BigQuery ○ 検査内容: ⾏数が⼀致するか / MAX(updated_at) が条件を満たすか

Slide 30

Slide 30 text

dbt によるメタデータ整備とテスト ● dbt で宣⾔的に BigQuery 内のデータの変換を⾏う ○ タイミーでは変換内容に応じて、下図のようにレイヤリングしている ○ 各レイヤーでモデル（テーブルやビュー）が実体化される https://tech.timee.co.jp/entry/2023/10/23/143322

Slide 31

Slide 31 text

dbt によるメタデータ整備とテスト ● モデルは Jinja で拡張された SQL で定義される ● モデルごとにメタデータを YAML で定義できる ○ カラムの型や説明 ○ ⾃動テスト https://docs.getdbt.com/docs/build/documentation

Slide 32

Slide 32 text

dbt によるメタデータ整備とテスト ● データテスト ○ 実データに対して汎⽤的なテストを実施できる ■ unique ■ not_null ■ … ● ユニットテスト ○ ⽤意したテストデータに対して期待する出⼒となるか https://docs.getdbt.com/docs/build/data-tests

Slide 33

Slide 33 text

4 今後の展望

Slide 34

Slide 34 text

タイミーのデータ基盤が抱える課題 ● データソースの変更による下流への影響 ● ⼿⼊⼒データの品質保証 ● ストリーミングデータにおける完全性の担保

Slide 35

Slide 35 text

データソースの変更による下流への影響

Slide 36

Slide 36 text

知らない間に転送元のテーブルの列が削除されたら ● 途中のデータ変換で列指定されていたら？ ○ ワークフローが停⽌してしまい、適時性が損なわれる ● downstream でダッシュボードの表⽰に使われていたら？ ○ 古いデータのまま表⽰したり、そもそも表⽰できなかったりする ○ 適切な意思決定ができない ● 機械学習で使われていたら？ ○ 古いデータをそのまま利⽤したり、機械学習パイプラインが停⽌したりする ○ 予測精度の低下、機会損失を招く

Slide 37

Slide 37 text

データソースの意図しない変更をどう防ぐか ● モニタリングやテストにより、ある程度対処できている ○ ただし対処であって、予防ではない ● データコントラクトによって事前に防げないか模索中

Slide 38

Slide 38 text

データコントラクトとは ● 契約プログラミングの概念をデータに持ち込んだもの ○ データ版 OpenAPI のようなもの ○ 破壊的な変更を避けて改善活動が実施できる https://datacontract.com/

Slide 39

Slide 39 text

データコントラクトとは ● データがどのような形式で供給されるかを定義した⽂書 ● いくつかの標準がある ○ Open Data Contract Standard (ODCS) ○ Data Contract CLI ● データの所有者、形式などの記載ができる ● データ品質、サービスレベルの記載も⾏える ● YAML でマシンリーダブルに表現される ○ CLI で実データを参照して、データ品質の検証ができる https://datacontract.com/

Slide 40

Slide 40 text

データコントラクトの運⽤を⽬指す ● データ供給元と利⽤先のチーム間で、データの形式について合意を取るようにしたい ○ いくつかのプロジェクトで試験的に導⼊ ● プロダクトの CI に組み込むと？ ○ 「このテーブルの型を変えようとしているけど、社内のダッシュボードで使われているのでダメです⚠」 https://datacontract.com/

Slide 41

Slide 41 text

5 まとめ

Slide 42

Slide 42 text

まとめ ● DRE とは SRE のプラクティスをデータに適⽤する試みのこと ● 社内の多様なチームと連携しながら、データの供給から活⽤までを⽀えている ● 扱うデータの理解は重要だが、組織とその業務プロセスへの理解も不可⽋である ● DRE のプラクティスとして、ワークフローやデータそのもののモニタリングを通して、信頼性の低下にいち早く対処している ● データ基盤と組織に新しい概念を持ち込むことで、信頼性の向上を⽬指している

Slide 43

Slide 43 text

https://hrmos.co/pages/timee/jobs/1682251404118319115 積極的に採⽤中です！！データ基盤を通して、プロダクトと組織の成⻑を⼀緒に⽀えましょう！