株式会社タイミーにおけるFivetran導入の契機と得られた効果
参考になった
9
株式会社タイミー / marufeuille
メンバー / インフラエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
| 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
データ転送,変換 | 10名以下 | 2022年12月 | B to B B to C |
アーキテクチャ
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
データ連携は主にembulkをベースとしていたが、結果として以下の様な課題があった
- 連携元が対応していないものに関しては都度検討が必要
- API limitのハンドリング等の対応が弱く、日々再実行のトイルが発生
- インフラ等本来管理外にしたい部分の対応工数がかさむ
どのような状態を目指していたか
- データ連携に関するデータエンジニアの工数を最小に開発・運用できる状態にし、より価値提供に近い部分の業務を行えるようにする
比較検討したサービス
- TROCCO
- BigQuery Data Transfer Service
比較した軸
- 連携したいSaaSに対応できること
- エンジニアの工数を最小に設定や運用が行えること
選定理由
- 使用感を検証し、現状抱えている上記の課題を解決できるため
導入の成果
改善したかった課題はどれくらい解決されたか
- 全体的に解決できた
どのような成果が得られたか
利用できるコネクタ数は標準でも多いが、国内SaaS等未対応なものについても by request program により対応することも可能で、データ連携の際のファーストチョイスになり、散らばっていた連携をある程度まとめることができた
設定や運用に関する工数を削減できた。特に運用に関して言えば、導入前後の半年の比較でembulkの頃は約7人日分のタスクがあったのに対し、Fivetranにすることで1.5時間分まで削減できた
結果として、浮いた工数を他の開発に回すことにより開発速度の向上や、アラートに伴う運用が減ったことにより精神的なツラさの解消に繋がった
load後にdbt cloudのJobを実行するtransformationの利用により、lake to stagingのリアルタイム性を向上させられた
導入時の苦労・悩み
- 使った量に比例して値引き率が上がっていくので、費用感がわかりにくかった
- 導入当時はterraformのproviderが弱く、コード管理がしにくかった
導入に向けた社内への説明
上長・チームへの説明
検証した結果として、特に納期感、工数感に関して、これまでのアーキテクチャでかかるものとFivetranに移行した場合の想定を並べて
- コネクタが豊富であるため比較的短納期にできやすく、設定が簡易でありエンジニア工数を低く実装できそうなこと
- 運用もインフラやAPIエラーのハンドリング等気にすることが大きく減らせてエンジニア工数を大幅に削減できそうなこと
の2点から説明を行い承認されました
活用方法
寄稿時点で 34 コネクタが動作しています
よく使う機能
- データ転送機能
- データ転送後にdbt cloudのJobを走らせるtransform機能
ツールの良い点
- エンジニアでなくても利用できそうなくらい設定が容易
- 開発が盛んで、当初なかった機能(terraformのprovider拡張、dbt cloud連携)やソリューション(lite connector) により日々便利になっている
- コネクタ設定時にトライアル期間が14日あるので費用の確認やそもそも要件にあうのか等検証が行いやすい
ツールの課題点
Adjust, Braze等変更レコードが多いツールではコストが膨大になり、予算内で利用できないものがあった(現状、Brazeでは予算的に転送できそうなもののみ連携)
株式会社タイミー / marufeuille
メンバー / インフラエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
よく見られているレビュー
株式会社タイミー / marufeuille
メンバー / インフラエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法