Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
タイミーの未来を支えるデータ基盤プロダクト
Search
Toshiki Tsuchikawa
March 12, 2023
Technology
1
830
タイミーの未来を支えるデータ基盤プロダクト
将来に備えるデータ基盤のススメ - Techmee vol.6
で発表したスライドになります。
Toshiki Tsuchikawa
March 12, 2023
Tweet
Share
More Decks by Toshiki Tsuchikawa
See All by Toshiki Tsuchikawa
タイミーのデータ活用を支えるdbt Cloud導入とこれから
ttccddtoki
2
630
タイミーにおけるデータ活用の未来
ttccddtoki
0
110
急成長する組織を支えるデータ基盤のこれまで、これから
ttccddtoki
6
740
アジリティの高いデータ基盤を目指して
ttccddtoki
4
1.6k
DMBOKを参考にしたデータマネジメントの取り組み
ttccddtoki
6
2.7k
dbt_Cloudとdbt_Core併用の試み
ttccddtoki
3
1.3k
データ品質を重視したデータ基盤プロダクト開発
ttccddtoki
8
2.4k
datatech-jp Casual Talks #3
ttccddtoki
0
1.1k
Lookerとdbtの共存
ttccddtoki
1
1.4k
Other Decks in Technology
See All in Technology
KCD Brazil '25: Enabling Developers with Dapr & Backstage
salaboy
1
120
モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま
panda_program
7
2k
Amazon EKS Auto ModeでKubernetesの運用をシンプルにする
sshota0809
0
110
一人QA時代が終わり、 QAチームが立ち上がった話
ma_cho29
0
290
アプリケーション固有の「ロジックの脆弱性」を防ぐ開発者のためのセキュリティ観点
flatt_security
28
10k
日本MySQLユーザ会ができるまで / making MyNA
tmtms
1
360
大規模プロジェクトにおける 品質管理の要点と実践 / 20250327 Suguru Ishii
shift_evolve
0
280
ソフトウェア開発現代史: なぜ日本のソフトウェア開発は「滝」なのか?製造業の成功体験とのギャップ #jassttokyo
takabow
2
1.6k
バックエンドエンジニアによるフロントエンドテスト拡充の具体的手法
kinosuke01
1
710
Cloud Native PG 使ってみて気づいたことと最新機能の紹介 - 第52回PostgreSQLアンカンファレンス
seinoyu
2
200
Go製のマイグレーションツールの git-schemalex の紹介と運用方法
shinnosuke_kishida
1
410
モンテカルロ木探索のパフォーマンスを予測する Kaggleコンペ解説 〜生成AIによる未知のゲーム生成〜
rist
4
1.1k
Featured
See All Featured
Music & Morning Musume
bryan
46
6.4k
Making Projects Easy
brettharned
116
6.1k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
It's Worth the Effort
3n
184
28k
Navigating Team Friction
lara
184
15k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.3k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Testing 201, or: Great Expectations
jmmastey
42
7.4k
A Philosophy of Restraint
colly
203
16k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
51
2.4k
Adopting Sorbet at Scale
ufuk
75
9.3k
Transcript
2023/03/10 土川稔生、石井正浩 タイミーの未来を支える データ基盤プロダクト @tvtg_24, @marufeuille
目次 • プロダクトとしてのデータ基盤 • 将来に備える運用と改善活動 2
1 プロダクトとしてのデータ 基盤
導入 プロダクトとしてのデータ基盤
土川 稔生 (Tsuchikawa Toshiki) • 株式会社タイミーに2020年入社 • DRE (Data Reliability
Engineering) チーム ◦ データエンジニアとしてデータ基盤プロダク トを構築 ◦ 現在はプロダクトオーナーとして、データ基 盤プロダクト作りに励む • Twitter: @tvtg_24 5 自己紹介
None
None
タイミーのデータ基盤プロダクトニーズ 経営の意思決定 施策の効果検証 データの提供 データサイエンス データ基盤プ ロダクト ・ ・ ・
どんなデータ基盤が必要になっていくか。 Mission: 「信頼性の高いデータ基盤を整備し、活用のための環境を提供する」
信頼性高いとは? 使いやすい データ基盤 品質の高い データ利用 データ基盤 の安定運用
信頼性高いとは? 使いやすい データ基盤 品質の高い データ利用 データ基盤 の安定運用 howとしては - モデリングや、Lookerでの品質担保
- 様々なテスト導入 など
品質の高いデータ提供のために 適時性 一意性 完全性 元データが更新されてからどの くらいの遅延で分析可能になる か データに重複はないか データに欠損はないか
13 Service Level Indicator サービスの品質を守るための指標 SLI SLA SLO Service Level
Agreement SLIで定義した指標に関するサービス提供者と の契約 (破った時にどうするかなど) Service Level Objective SLIで定義した指標の具体的な目安 一般的なSLI, SLA, SLOの定義
14 Service Level Indicator データパイプラインの適時性 (データソースの更新からど のくらい遅れて転送先で実用可能になるか) SLI SLA SLO
Service Level Agreement データソースごとにBigQuery使用者と結ばれた適 時性に関する契約 破った場合はポストモーテムを実施 例: データソースAは1日の適時性での転送 Service Level Objective DREチーム内で決定されたデータソースごとの適 時性の目標 例: データソースAは2hourの適時性での転送 DREチームにおけるSLI, SLA, SLOの定義
現在のデータ基盤概要
将来に備えるための開発体制について DREスクラムチーム PO SM Dev - アジャイルな開発を目指すためのスク ラム体制 - 専属スクラムマスター
- ユーザーストーリー導入 https://www.slideshare.net/masahiroishii39/dat atechjpcasualtalks04pdf
2 将来に備える運用と 改善活動
石井 正浩 / @marufeuille 2022/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 Book https://timee.notion.site/timee/Timee-Product-Org-Entrance-Book-b7380eb4f6954e29b2664fe6f5e775f9