Treasure Data から Snowflake へ
移行の理由・比較・工程・つまずきどころ

データ基盤の移行は、規模や要件に合わせた計画づくりから。大手人材サービス企業での経験をもとに、候補の比較・検証から段階的な切り替え、運用改善までの進め方を紹介します。

規模と要件に合わせて、段階的に移行する

移行スケジュールの一例。工程ごとの確認を重ね、切り替えまでの見通しを立てます。

  1. 01 移行前

    現状調査・検証

    データ・連携・利用状況を棚卸し。候補製品をPOCで確かめる。

    移行対象と優先順位を整理
  2. 02 移行前

    設計・移行準備

    新基盤と運用を設計。検証方法、切替手順、切り戻し条件を決める。

    手順と判定基準を合意
  3. 03 移行

    段階移行・切り替え

    対象を分けて移し、並行稼働でデータと業務への影響を確認する。

    本番切替・安定稼働を確認
  4. 04 移行後

    運用・改善

    監視と保守を続け、コストや処理性能、データ活用を改善する。

    必要に応じて高度化を計画

期間は、現状を確認してから。データ量・連携数・既存処理の複雑さ・検証範囲・契約更新時期に応じて、スケジュールを個別に組み立てます。

図は進め方を一般化したもので、各工程の長さを表すものではありません。移行後の高度化は、切り替え完了とは分けて計画します。

基盤の切り替え前後の構成。移行前はTreasure DataとAWS S3、移行後の主な製品はSnowflake、TROCCO、AWS S3・Glue・Lambda。年間利用コスト1/5、データ処理速度1.5倍という、この移行に帰属する成果を示します。
Treasure DataからSnowflakeへの移行基盤の切り替え前後の構成。移行前はTreasure DataとAWS S3、移行後の主な製品はSnowflake、TROCCO、AWS S3・Glue・Lambda。年間利用コスト1/5、データ処理速度1.5倍という、この移行に帰属する成果を示します。図を拡大して見る ↗
図の内容をテキストで読む

何から何へ移したか

移行前
Treasure Data
AWS(S3)
  • 導入時の想定と現場の要求がずれていた
  • 為替の影響もあり利用コストが上昇
  • 使っていない機能も含めて課金
移行後
Snowflake
TROCCO
AWS(S3 / Glue / Lambda)
  • 年間利用コスト 1/5
  • データ処理速度 1.5倍
案件の基礎情報を開く(業種・支援範囲・立場・体制・担当工程・使った製品)
業種人材派遣・職業紹介事業
案件データ基盤の刷新(Treasure Data + AWS → Snowflake + TROCCO + AWS)
支援範囲POC・現行基盤の保守から、移行、移行後の運用改善・高度化まで
立場フリーランス。設計/テックリード(移行プロジェクトリード)
体制チーム8名(うち開発4名)/関係者を含む全体10名
担当工程要件定義・基本設計・詳細設計・実装・単体・結合テスト・総合テスト・保守運用(全工程)
主な製品・技術Snowflake、Treasure Data、TROCCO、AWS(S3 / Glue / Lambda)、Python、SQL(Presto / Hive)、Linux、Salesforce、Marketo
成果(フェーズ別)移行=年間利用コスト1/5、データ処理速度1.5倍。移行後の高度化=Salesforce / Marketo 向けのデータ連携を数時間から10分以内へ。移行前の現行基盤保守=データ前処理を1時間から30分へ。
製品比較

候補を並べて、POCで確かめてから決めた

データウェアハウスの候補
Snowflake採用Amazon RedshiftAmazon Athena
ワークフロー・データ連携の候補
TROCCO採用AirflowPresto

現状調査、新基盤に求める要件の策定、比較資料づくり、そして実際に動かしての検証。比較の軸は自社の使い方から決めます。カタログスペックを並べるだけでは決まりません。

移行後の高度化

ツールで届かないところを、作って埋めた

Snowflakeのステージ出力からS3へ。S3イベントをLambdaが検知しGlueを起動、Salesforce・MarketoへAPI連携する流れ。64並列は模式表現です。数時間以上から10分以内は、この連携処理単体の結果であり基盤全体の処理時間ではありません。
移行後の高度化:データ連携を64並列へSnowflakeのステージ出力からS3へ。S3イベントをLambdaが検知しGlueを起動、Salesforce・MarketoへAPI連携する流れ。64並列は模式表現です。数時間以上から10分以内は、この連携処理単体の結果であり基盤全体の処理時間ではありません。図を拡大して見る ↗
図の内容をテキストで読む

移行後にいちばん効いた作り直し

連携ツールのコネクタでは数時間以上かかっていた処理を、64並列で組み直した。

移行直後連携ツールのコネクタ数時間以上
作り直しAWS Glue / Lambda64並列の非同期処理として設計・実装
いま同じ連携処理10分以内

Salesforce / Marketo 向けのデータ連携。この連携処理単体の数字で、基盤全体の処理時間ではありません。「数時間以上」は正確な計測値ではないため、長さの比では描いていません。

ほかに、関連会社向けS3出力の5GB制約に対して S3マルチパートアップロードとチャンク分割方式を設計しました。Snowflakeのステージ出力 → S3 → Lambdaトリガー → Glue起動 → API連携、というイベント駆動の流れに組み直しています。

つまずきどころ

移行を検討している方に、先に言っておきたいこと

  1. 01期日を決めるのは技術ではなく契約現行基盤の更新日から逆算すると、検証・並行稼働・切り戻しに使える期間が決まる
  2. 02ツールのコネクタは必ずどこかで足りなくなるこの案件では Salesforce / Marketo 連携と、5GBを超えるファイル転送
  3. 03権限・データ分類・マスキングを後回しにしない終盤に「この列は誰に見せてよいか」を決め始めると止まる
  4. 04棚卸しをしないと費用は下がらない使っていない機能を残したまま移すと、移行先でも同じ額を払う
  5. 05切り替え後の運用まで設計しておく監視・保守の体制を整え、追加の改善・高度化は優先度に応じて計画する
実績の読み方

この事例の前提と範囲

実績の主体合同会社クラウドラブ設立後、代表・岩森吏央がフリーランスのエンジニア(テックリード)として個人で参画した案件です。CloudLabという会社としての受注実績ではありません。
担当範囲現状調査/製品比較とPOC/移行計画・段階計画の策定/新基盤のアーキテクチャ設計(全体構成・ネットワーク・AWSアカウント・セキュリティポリシー・DB設計)/運用設計(監視・権限・運用フロー・障害対応方針)/ガバナンス設計(権限・データ分類とタグ・マスキング)/構築のレビューと品質統制/移行の実行リード/移行後の運用保守と高度化。
プロジェクト体制チーム8名(うち開発4名)、関係者を含む全体10名。代表は設計・テックリードとして参画しています。POCから移行、移行後の運用改善・高度化まで関与しました。
数字が指すシステム「年間利用コスト1/5・データ処理速度1.5倍」は、Treasure Data + AWS(S3) から Snowflake + TROCCO + AWS(S3) へ移した基盤全体を比べた数字です。「数時間 → 10分以内」は移行後の高度化フェーズで、Salesforce / Marketo 向けのデータ連携を AWS Glue / Lambda の64並列処理で作り直したときの、その連携処理単体の数字です。基盤全体の処理時間ではありません。「1時間から30分」は移行前、現行の Treasure Data 基盤でデータ前処理を改善したときの数字です。
守秘のため一般化した部分発注元の社名・部署名・扱っているデータの中身は伏せ、「大手人材サービス企業」と業種で書いています。製品名(Treasure Data・Snowflake・TROCCO・AWS Glue / Lambda / S3・Salesforce・Marketo)は伏せていません。
関連事例

小売・流通グループのカード会社で、データ統合基盤を内製で立ち上げた

こちらは移した側ではなく、ゼロから作った側の事例です。大手SIerの提案総額と比べて投資・運用コストを約1/3に抑えた案件の、体制と工程を書いています。

この事例を読む →

サービス

データ基盤の現状診断・移行計画・第三者レビュー

移行するかどうかを決める前の段階からご相談いただけます。費用の分解、候補比較とPOCの設計、ベンダー提案の第三者レビューをお引き受けしています。

サービスの内容を見る →

移行を検討している段階でも

「移すべきかどうか」から一緒に考えます。現行の契約更新日と、止められない処理が分かれば、だいたいの段取りはその場でお話しできます。

相談する 実績・事例の一覧へ