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
データパイプラインをなんとかした話 / Improving the Data Pipeline...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Issei Naruta
December 11, 2024
Technology
650
2
Share
データパイプラインをなんとかした話 / Improving the Data Pipeline in IVRy
2024/12/11 IVRy エンジニア忘年LT大会 2024
https://connpass.com/event/333537/
Issei Naruta
December 11, 2024
More Decks by Issei Naruta
See All by Issei Naruta
mairuでつくるクレデンシャルレス開発環境 / Credential-less development environment using Mailru
mirakui
5
800
インフラからSREへ
mirakui
32
14k
Cookpad TechConf 2022 Keynote
mirakui
0
4.1k
ドライイーストを使わずにパンを焼けるか? 〜天然酵母のパン作りを支える技術〜
mirakui
0
3.7k
関東積みについて/How to build Kanto-stacking
mirakui
0
790
先折りGTRについて/How to build left-GTR transitions
mirakui
3
1.1k
サービス開発速度に着目したソフトウェアアーキテクチャ/Software architecture for effective service development at Cookpad
mirakui
5
7.3k
Beyond the Boundaries
mirakui
1
1.4k
Cookpad Under a Microscope
mirakui
6
8.7k
Other Decks in Technology
See All in Technology
PHP と TypeScript の型システム比較:AI 時代の「型」は誰のためにあるのか? #frontend_phpcon_do / frontend_phpcon_do_2026
shogogg
1
230
Spring Boot における AOT Cache 活用テクニックと 起動時間改善事例
ntt_dsol_java
0
200
はじめてのDatadog
kairim0
0
260
Javaで学ぶSOLID原則
negima
1
260
オンコールの負荷軽減のためのBits Assistant 活用方法 / How to Use Bits Assistant to Reduce the Workload on On-Call Staff
sms_tech
1
370
関西に縁あるMicrosoft MVPsが語るCopilotの未来
kasada
0
970
『家族アルバム みてね』における インシデント対応との向き合い方 / Approach incident response in Family Album
kohbis
2
290
AI駆動開発でなんでもハンズオン環境をつくってみた
yoshimi0227
0
190
コードレビューを制するチームがソフトウェアデリバリーのフローを制す / Beyond Code Review: Distributing Its Responsibilities Across the SDLC
mtx2s
3
590
【Gen-AX】20260530開催_JJUG CCC 2026 Spring
genax
0
310
Strands Agents超入門
kintotechdev
1
150
TypeScript Compiler APIとPHP-Parserを活用し、TypeScriptとPHPで型を共有する
shuta13
0
320
Featured
See All Featured
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.9k
WENDY [Excerpt]
tessaabrams
11
38k
What's in a price? How to price your products and services
michaelherold
247
13k
So, you think you're a good person
axbom
PRO
2
2k
Odyssey Design
rkendrick25
PRO
2
660
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Faster Mobile Websites
deanohume
310
31k
Fireside Chat
paigeccino
42
3.9k
New Earth Scene 8
popppiees
3
2.3k
Docker and Python
trallard
47
3.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Amusing Abliteration
ianozsvald
1
190
Transcript
データパイプラインの課題をなんとかした話 IVRyエンジニア忘年 LT大会2024 Issei Naruta / mirakui
成⽥ ⼀⽣ (なるた いっせい) / @mirakui 株式会社 IVRy / Principal
Engineer 2008-2023 クックパッド ‧インフラ, バックエンドエンジニア ‧執⾏役CTO (2016-2022) 2024/2- IVRy ‧SRE + データ基盤 趣味: パン作り、ルービックキューブ 、ボルダリング
BigQuery Spreadsheet BigQuery Data Transfer Before (2024/2 入社時点) BI ETL
Aurora S3 DynamoDB
これまでの データ基盤 / データパイプライン の課題
①BigQueryのコストが 異様に⾼い BigQuery
BigQueryのコストが異様に⾼い このサイズのスタートアップでなんでこんなにBQ代払ってるの??? 主な原因 • 全社ダッシュボードで創業以来の着電ログを毎回フルスキャンしており 誰かがダッシュボード開くたびに数千円が⾶ぶ状態 →地道に⽇々スロークエリを追い、データマート作成で軽量化 • 料⾦プランが初期状態(On-demand)のままだった →スロット課⾦(Editions)に切り替え
料金を1/5程度に削減成功
②転送ワークフローが 複雑でメンテナンス困難
転送ワークフローが複雑でメンテナンス困難 • Terraform で⽣成された難解な転送フロー ◦ ジョブ開始時間がハードコーディングされているため 転送頻度を上げたいのに上げられない • 実⾏状況がわかりにくく、エラーが起こっても対処が困難 BigQuery
BigQuery Data Transfer Aurora S3 DynamoDB
③スキーマ変更が⼿動 アプリ側と⼆重管理が必要 BigQuery Aurora
スキーマ変更の⼆重管理問題 • アプリケーション側でテーブルやカラムが増えたら、 BQ側のスキーマもその都度変更する必要がある →⾯倒だし、忘れる →うっかり漏れがあると転送が壊れる。つらい BigQuery Aurora
TROCCOの導入で 転送ワークフローを改善した
TROCCO • ローコードな国産 ETL サービス → UI が分かりやすく、エンジニアでなくても扱いやすい → Embulk
(OSS) ベースなので挙動がまあまあ想像しやすい • 転送時に(半)⾃動でスキーマ追従ができる →テーブルやカラムが増減しても問題ない • コード管理や dbt の実⾏もできる →ある程度規模が⼤きくなっても⼤丈夫そう
移⾏作業のようす
既存パイプラインで転送したテーブルと TROCCO で転送したテーブルを共存さ せ、データの整合性を確認したら社内にア ナウンスしてガッと置き換える ←当日の自分用手順書
None
None
BigQuery Spreadsheet BigQuery Data Transfer Before (2024/2 入社時点) BI ETL
Aurora S3 DynamoDB
Aurora S3 DynamoDB dbt Aurora BigQuery BigQuery ETL Reverse ETL
BI - test - datamart - DWH After (2024/12 現在)
What’s next?
データパイプラインやっていき • データの鮮度を上げたい → TROCCO 導⼊では結局1⽇1回転送だったのを3時間に1回転送 の改善が限度だった • テーブル転送(洗替)をやめたい
→ 遅いしエコじゃない → CDC か Data Lakehouse パターンに移⾏チャレンジしたい • Snowflake に⾏きたい…かも → なんだかんだ BQ は使いやすいが クラウドまたぎ転送にいつまで消耗するんでしょうか
Appendix: TROCCOのここがつらいよ
TROCCOつらみリスト • エラーが分かりにくい ◦ 転送エラーログが Embulk の内部エラーの⽣ログを直接⾒せられるので結局どのレコードが問題だったのか全然わからん • 通知が不⼗分 ◦
基本は失敗通知だけでよくて、失敗していたジョブが成功したときだけ成功通知が欲しいけどできない。メール通知をparseしてご にょごにょしようかと思ったけど、メール通知がhtml tableレイアウトなのでparseしてなんかするのも困難。webhook対応してほ しい • 各種コネクタの出来のばらつきが激しい ◦ 対応してはいるけど本番運⽤が困難な仕様のものもちょいちょいある。転送元SalesforceコネクタはCSVを経由するせいで⽂字エン コードのノイズに弱すぎるとか、そもそもスキーマ追従ができなかったりとか、転送元DynamoDBはテーブルをスキャンしてしま うので本番では使えないとか • コード対応が中途半端 ◦ 転送フローやデータマートはコード管理できるけど⼀番コード管理したいワークフローは未対応。というか変更履歴すらないのは 厳しい • ユーザ管理機能が不親切 ◦ 初期パスワードの⾃動⽣成くらいして欲しいし、ユーザがログイン後じゃないとリソースグループに⼊れられないのも⾯倒すぎる • スキーマ推定が中途半端 ◦ 転送元にスキーマがあっても参照されずあくまでレコードからスキーマが推定されるため、新規テーブルでまだレコードが無い場 合は推定がうまくいかず、レコードが⼊ってきたときにこける • ワークフローのスケジュール指定が扱いづらい ◦ 例えば「3時間に1回実⾏したい」というようなときはスケジュールを8個設定する必要があるが、メンテナンス作業で⼀時的に⽌め たいときは8個を消して、メンテが終わったら8個をまたポチポチ作る必要がある。cron形式とかで書けるようになって欲しいし、 スケジュール削除しなくてもオンオフができるようになって欲しい
おわり