将来に備えるデータ基盤のススメ - Techmee vol.6 で発表したスライドになります。
2023/03/10 土川稔生、石井正浩タイミーの未来を支えるデータ基盤プロダクト@tvtg_24, @marufeuille
View Slide
目次● プロダクトとしてのデータ基盤● 将来に備える運用と改善活動2
1 プロダクトとしてのデータ基盤
導入プロダクトとしてのデータ基盤
土川 稔生 (Tsuchikawa Toshiki)● 株式会社タイミーに2020年入社● DRE (Data Reliability Engineering) チーム○ データエンジニアとしてデータ基盤プロダクトを構築○ 現在はプロダクトオーナーとして、データ基盤プロダクト作りに励む● Twitter: @tvtg_245自己紹介
タイミーのデータ基盤プロダクトニーズ経営の意思決定施策の効果検証データの提供データサイエンスデータ基盤プロダクト・・・
どんなデータ基盤が必要になっていくか。Mission:「信頼性の高いデータ基盤を整備し、活用のための環境を提供する」
信頼性高いとは?使いやすいデータ基盤品質の高いデータ利用データ基盤の安定運用
信頼性高いとは?使いやすいデータ基盤品質の高いデータ利用データ基盤の安定運用howとしては- モデリングや、Lookerでの品質担保- 様々なテスト導入など
品質の高いデータ提供のために適時性 一意性 完全性元データが更新されてからどのくらいの遅延で分析可能になるかデータに重複はないか データに欠損はないか
13Service Level Indicatorサービスの品質を守るための指標SLISLASLOService Level AgreementSLIで定義した指標に関するサービス提供者との契約 (破った時にどうするかなど)Service Level ObjectiveSLIで定義した指標の具体的な目安一般的なSLI, SLA, SLOの定義
14Service Level Indicatorデータパイプラインの適時性 (データソースの更新からどのくらい遅れて転送先で実用可能になるか)SLISLASLOService Level AgreementデータソースごとにBigQuery使用者と結ばれた適時性に関する契約破った場合はポストモーテムを実施例: データソースAは1日の適時性での転送Service Level ObjectiveDREチーム内で決定されたデータソースごとの適時性の目標例: データソースAは2hourの適時性での転送DREチームにおけるSLI, SLA, SLOの定義
現在のデータ基盤概要
将来に備えるための開発体制についてDREスクラムチームPOSM Dev- アジャイルな開発を目指すためのスクラム体制- 専属スクラムマスター- ユーザーストーリー導入https://www.slideshare.net/masahiroishii39/datatechjpcasualtalks04pdf
2 将来に備える運用と改善活動
石井 正浩 / @marufeuille2022/8入社データ基盤の開発・運用やってます2月に第2子生まれました 🎂
将来に備える運用と改善活動対応データ基盤障害作業・改善依頼
将来に備える運用と改善活動対応データ基盤頑張りすぎれば疲弊する障害作業・改善依頼
将来に備える運用と改善活動対応データ基盤放置すれば利用者が迷惑する頑張りすぎれば疲弊する障害作業・改善依頼
将来に備える運用と改善活動① SLAを定義した運用② トイル作業の可視化とその改善③ ポストモーテムによる改善
SLAのない世界ユーザ※ 弊社の事例ではありませんし、私の周りでは見たことないです。念の為データは絶対に最新!必要な作業はすぐやってほしい!怠惰なわたしできるだけゆるーく、やれるときにやれるだけでいいよねちょうどいい感じのバランスを取る必要がある
SLAの設定SLAは利用者が満足できる「最低限の」数値- 利用者要件を鑑みた上でエンジニアから提案し、中長期的に無理にならないものを提供- 改善は前提だが、最初の SLAがそのまま期待値になるので注意する
SLAをベースにした運用例) 更新頻度3日以内 = 簡単に言うと所定のテーブルが 3日に1回以上更新されていれば OK適時性SLI = テーブルが何時間前に更新されたか1日2日3日転送パイプライン実行障害この間に転送できれば良いSLAが定義されていない場合・判断がつかないのでエラー毎に対応・もしくは詳しい人だけやらなくても良い判断ができるSLAが定義されている場合・適切なSLAが設定されていれば不要な休日や夜間帯の対応をできる限り避けることも可能
運用に関わる作業をして思うこと毎回同じことばっかりしてる手作業多すぎて開発に工数割けない...
運用に関わる作業をして思うこと毎回同じことばっかりしてる手作業多すぎて開発に工数割けない...トイルの解消が必要
トイルの定義引用: SRE サイトリライアビリティエンジニアリング P.51より手作業で繰り返し行われ、自動化可能することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つもの
トイル撲滅の目的① データ基盤プロダクト開発にかける時間をふやす② 会社の規模増に対して無限のエンジニアリソースを 必要とする状態を回避する③ 同じ作業によるモチベーション低下を避ける
トイル作業の可視化とその改善ロードマップタスクに使える時間を「増やす」というKPIが設定されているそれぞれの軸で、重たそうなトイル作業の内訳を可視化し、次の改善のベースにしている
障害対応を終えて思うこともっとよくできたな
ポストモーテム実施の目的① 何が起こったかをチームで理解する② 改善について議論し、よりよい対応ができるようにする③ ステークホルダーを巻き込み、利用者へ対応改善の共有
ポストモーテムによる改善事実の整理この後ろにタイムライン等を記載事実の読み合わせ後、振り返りNextActionの決定
タイミーの未来を支えるデータ基盤プロダクトを提供するために人を並べて疲弊するチームではなく、スマートな開発・運用をできるチームに
もしこの発表を見てタイミーに興味を持った方がいればこちらをご覧ください!Timee Product Org Entrance Bookhttps://timee.notion.site/timee/Timee-Product-Org-Entrance-Book-b7380eb4f6954e29b2664fe6f5e775f9