Slide 1

Slide 1 text

データパイプラインの課題をなんとかした話 IVRyエンジニア忘年 LT大会2024 Issei Naruta / mirakui

Slide 2

Slide 2 text

成⽥ ⼀⽣ (なるた いっせい) / @mirakui 株式会社 IVRy / Principal Engineer 2008-2023 クックパッド ‧インフラ, バックエンドエンジニア ‧執⾏役CTO (2016-2022) 2024/2- IVRy ‧SRE + データ基盤 趣味: パン作り、ルービックキューブ 、ボルダリング

Slide 3

Slide 3 text

BigQuery Spreadsheet BigQuery Data Transfer Before (2024/2 入社時点) BI ETL Aurora S3 DynamoDB

Slide 4

Slide 4 text

これまでの データ基盤 / データパイプライン の課題

Slide 5

Slide 5 text

①BigQueryのコストが 異様に⾼い BigQuery

Slide 6

Slide 6 text

BigQueryのコストが異様に⾼い このサイズのスタートアップでなんでこんなにBQ代払ってるの??? 主な原因 ● 全社ダッシュボードで創業以来の着電ログを毎回フルスキャンしており 誰かがダッシュボード開くたびに数千円が⾶ぶ状態 →地道に⽇々スロークエリを追い、データマート作成で軽量化 ● 料⾦プランが初期状態(On-demand)のままだった →スロット課⾦(Editions)に切り替え 料金を1/5程度に削減成功

Slide 7

Slide 7 text

②転送ワークフローが 複雑でメンテナンス困難

Slide 8

Slide 8 text

転送ワークフローが複雑でメンテナンス困難 ● Terraform で⽣成された難解な転送フロー ○ ジョブ開始時間がハードコーディングされているため 転送頻度を上げたいのに上げられない ● 実⾏状況がわかりにくく、エラーが起こっても対処が困難 BigQuery BigQuery Data Transfer Aurora S3 DynamoDB

Slide 9

Slide 9 text

③スキーマ変更が⼿動 アプリ側と⼆重管理が必要 BigQuery Aurora

Slide 10

Slide 10 text

スキーマ変更の⼆重管理問題 ● アプリケーション側でテーブルやカラムが増えたら、 BQ側のスキーマもその都度変更する必要がある →⾯倒だし、忘れる →うっかり漏れがあると転送が壊れる。つらい BigQuery Aurora

Slide 11

Slide 11 text

TROCCOの導入で 転送ワークフローを改善した

Slide 12

Slide 12 text

TROCCO ● ローコードな国産 ETL サービス → UI が分かりやすく、エンジニアでなくても扱いやすい → Embulk (OSS) ベースなので挙動がまあまあ想像しやすい ● 転送時に(半)⾃動でスキーマ追従ができる →テーブルやカラムが増減しても問題ない ● コード管理や dbt の実⾏もできる →ある程度規模が⼤きくなっても⼤丈夫そう

Slide 13

Slide 13 text

移⾏作業のようす

Slide 14

Slide 14 text

既存パイプラインで転送したテーブルと TROCCO で転送したテーブルを共存さ せ、データの整合性を確認したら社内にア ナウンスしてガッと置き換える ←当日の自分用手順書

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

BigQuery Spreadsheet BigQuery Data Transfer Before (2024/2 入社時点) BI ETL Aurora S3 DynamoDB

Slide 18

Slide 18 text

Aurora S3 DynamoDB dbt Aurora BigQuery BigQuery ETL Reverse ETL BI - test - datamart - DWH After (2024/12 現在)

Slide 19

Slide 19 text

What’s next?

Slide 20

Slide 20 text

データパイプラインやっていき ● データの鮮度を上げたい → TROCCO 導⼊では結局1⽇1回転送だったのを3時間に1回転送   の改善が限度だった ● テーブル転送(洗替)をやめたい → 遅いしエコじゃない → CDC か Data Lakehouse パターンに移⾏チャレンジしたい ● Snowflake に⾏きたい…かも → なんだかんだ BQ は使いやすいが   クラウドまたぎ転送にいつまで消耗するんでしょうか

Slide 21

Slide 21 text

Appendix: TROCCOのここがつらいよ

Slide 22

Slide 22 text

TROCCOつらみリスト ● エラーが分かりにくい ○ 転送エラーログが Embulk の内部エラーの⽣ログを直接⾒せられるので結局どのレコードが問題だったのか全然わからん ● 通知が不⼗分 ○ 基本は失敗通知だけでよくて、失敗していたジョブが成功したときだけ成功通知が欲しいけどできない。メール通知をparseしてご にょごにょしようかと思ったけど、メール通知がhtml tableレイアウトなのでparseしてなんかするのも困難。webhook対応してほ しい ● 各種コネクタの出来のばらつきが激しい ○ 対応してはいるけど本番運⽤が困難な仕様のものもちょいちょいある。転送元SalesforceコネクタはCSVを経由するせいで⽂字エン コードのノイズに弱すぎるとか、そもそもスキーマ追従ができなかったりとか、転送元DynamoDBはテーブルをスキャンしてしま うので本番では使えないとか ● コード対応が中途半端 ○ 転送フローやデータマートはコード管理できるけど⼀番コード管理したいワークフローは未対応。というか変更履歴すらないのは 厳しい ● ユーザ管理機能が不親切 ○ 初期パスワードの⾃動⽣成くらいして欲しいし、ユーザがログイン後じゃないとリソースグループに⼊れられないのも⾯倒すぎる ● スキーマ推定が中途半端 ○ 転送元にスキーマがあっても参照されずあくまでレコードからスキーマが推定されるため、新規テーブルでまだレコードが無い場 合は推定がうまくいかず、レコードが⼊ってきたときにこける ● ワークフローのスケジュール指定が扱いづらい ○ 例えば「3時間に1回実⾏したい」というようなときはスケジュールを8個設定する必要があるが、メンテナンス作業で⼀時的に⽌め たいときは8個を消して、メンテが終わったら8個をまたポチポチ作る必要がある。cron形式とかで書けるようになって欲しいし、 スケジュール削除しなくてもオンオフができるようになって欲しい

Slide 23

Slide 23 text

おわり