Zenn
♻️

Terraformとdbtを活用してデータ基盤整備の生産性が向上した話

2024/02/29に公開
Terraform
Snowflake
dbt
tech

はじめに

私が所属しているライフイズテックのデータ基盤グループで、ここ2年ほどでdbtとterraformを活用してDataOpsを進め、データ基盤の整備の生産性が向上した話をまとめます。

導入前の状況と課題

弊社のデータ基盤ではデータ基盤が綺麗に整備されていることよりも、プロダクトや事業に貢献できているかを重要と考え、まずデータを使える状態にすることを目指したサービスの導入や基盤構築を行いました。
考え方としてはこちらの
DWHにおけるデータモデリングで大事にしている考え方に書かれている内容に近い考え方になります。
そのため、データモデリングの前にRedashやCRM AnalyticsというBIツール向けにデータレイクからデータマートを先に構築していました。
導入前の構成
terraformとdbt導入前は、図のような流れで

  1. SQLでSnowflake上にDBやスキーマなどを作成
  2. ELTサービスとしてすでに導入していたtroccoのデータマート機能を使いデータレイクからデータマートを構築する
  3. データマートのデータをRedashやCRM Analyticsから参照する
    a. CRM AnalyticsはSalesforceが提供している製品のため、Salesforceとの親和性からビジネスチームで利用しています。
  4. ビジネスチーム独自で出したいデータについてはCRM Analytics内でデータ変換・集計を行い可視化する

導入前の構成の利点

導入済みのtroccoの利用とGUIでデータ変換できるCRM Analyticsの導入は、当時データ基盤は一名体制だったことが大きいですが、次のような利点がありました

  • 素早くデータを使える状態にできたこと
  • ビジネスチームが自チームでほしいデータをデータの知識なくつくることができたこと

導入後の課題

その後チーム体制に移行し、ステージング層などのデータを整備していく中で次のような課題が出てきました。

  • 現状の状態の確認が難しい
    • SQLでSnowflakeを構築した場合、SnowSightあるいはSQLでの実行で確認する必要があるため、状態確認が面倒というのがありました。これによりすでにオブジェクトと同様の設定のオブジェクトを作成する際の確認方法を確認する
  • チームメンバー全員に強い権限が必要
    • SQLで操作するオブジェクトによってはACCOUNT ADMINなどの権限が必要なため、チームメンバー全員が強い権限を持っており、ミスによる意図しない操作を防ぐことが難しい状況でした
  • データを複数人でメンテナンスすることが難しい
    • troccoのデータマート機能はレビューを挟むワークフローを組めないことから、属人的なデータパイプラインとなっていました
    • CRM Analyticsでのデータ処理が複雑化していき、どういう処理を行っているのかビジネスチームの担当者しかわからないという状態になっていました
  • データの依存関係の解決が難しい
    • データマート機能自体にはデータの依存関係を解決する方法がないため、各データマート機能の処理を確認して依存関係を泥臭く解決する必要がありました
  • データ処理のエラーや意図しないデータが入った場合の対応工数が大きい
    • 複数のサービスによってデータパイプラインが構築されていたため、エラー時の復旧で各サービスそれぞれで復旧を行う必要がありました
    • データ利用者からデータが想定と異なるという連絡を受けた場合にどの処理でそうなっているのかの原因特定を複数サービスにまたがって確認する必要がありました

導入後のアーキテクチャ

上記の問題を解決するために、Snowflakeの管理にはTerraformを導入し、データパイプラインはdbtに１本化しました(まだ一部CRM Analyticsに残っていますが、移行中です)
導入後の構成

導入後の変化

  • チームでの開発のしやすさ
    • git管理ができレビューを挟むワークフローを組むことができるようになりました。それによりチームメンバーの権限を最小限に抑え、レビューと合わせて意図しないミスを防ぐことができるようになりました。
    • 次の状態確認のしやすさと合わせて、新規で作業するときに既存のソースコードから既存オブジェクト・モデルを参考にすることができ、新しくジョインしたメンバーでもオブジェクトやモデルの修正・追加をしやすくなりました。
  • 依存関係や状態の確認のしやすさ
    • Snowflakeの各種設定やdbtのモデルをコードから確認できるようになり、開発時にソースコードを確認するだけでよくなり、開発時の確認に必要なアクションが減りました。
  • デバッグのしやすさ
    • モデルが一元管理されることで想定と異なるデータがある場合の問題点を確認しやすくなりました。
    • CRM Analyticsでは一つ一つのステップで設定されたデータや出力されたデータを確認していました。
      CRM Analyticsでのデータ変換・集計

  • 暗黙的な知識・設定が減った
    • ソースコードで設定が管理され明示的になったために、担当者のみが知っていた情報が減りました。(設計意図や背景情報については別途ドキュメントに残す必要があることに変わりはありません)

導入後の課題

  • Snowflakeのterraformプロバイダーが不安定
    • まだ実験的な立ち位置ということもあり、プロバイダーのバージョンを上げるとエラーが発生するケースやプロバイダーで対応していないSQLもあり、terraform apply後にエラーが出るということもよくあります
  • terraform modulesでのコードの共通化ができていない
    • 各種オブジェクトで似たオブジェクトが複数あるというケースが多いのですが、modulesの活用ができておらず、コピペをするようなケースも多々ある状態です

宣伝

ライフイズテック サービス開発部では、月毎に気軽にご参加いただけるカジュアルなイベントを実施しています。開催予定のイベントは、 connpass のグループからご確認ください。興味のあるイベントがあったらぜひ参加登録をお願いいたします。皆さんのご参加をお待ちしています！

Discussion