0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

SnowflakeにおけるTerraform管理とGit管理の棲み分けを整理してみた

0
Posted at

はじめに

Snowflake環境をTerraformで構築した後、
実際の開発資産をどのように管理するかで悩みました。

  • Terraformでどこまで管理するのか
  • Gitでどこを管理するのか

この境界が曖昧に感じたため、
今回は Terraform管理とGit管理の棲み分け について整理してみました。


管理対象の整理

Snowflakeで扱う主な対象を整理すると、以下のようになります。

  • Database / Schema
  • Warehouse
  • Role / User / Grant
  • Table / View
  • Procedure / Function
  • Task / Pipe
  • Stage / File Format
  • Policy(Masking / Row Access等)
  • Integration(Security Integration / External Integration等)
  • Workspace

基本方針

結論として、以下のように整理しました。

Terraformは「環境を構成する要素」
Gitは「開発資産や処理ロジック」


Terraform管理とGit管理の棲み分け

■ Terraform管理(インフラ)

環境そのものを構成する要素はTerraformで管理します。

  • Database
  • Schema
  • Warehouse
  • Role
  • User
  • Grant
  • Stage
  • File Format
  • Policy
  • Integration

これらは「その環境に存在していてほしい土台」であり、
変更頻度も比較的低いためTerraformでの管理と相性が良いと感じました。


■ Git管理(開発資産)

SQLロジックや変更頻度が高いものはGitで管理します。
(SQLファイルとして定義を管理)

  • Table(DDL)
  • View
  • Procedure
  • Function

これらは以下の理由からGit管理が適していると感じました。

  • 差分レビューがしやすい
  • 変更履歴を追いやすい
  • ローカルで編集・検証しやすい

グレーゾーンの整理

■ Task / Pipe

このあたりは少し悩みどころでした。

● Task

Taskは以下のどちらにも寄せられます。

  • スケジュール定義(インフラ寄り)
  • 処理ロジック(SQL寄り)

そのため、以下のように分けるのが良さそうです。

  • 単純にプロシージャを呼び出すだけ → Terraform管理
  • SQLロジックが増える → Git管理

また、Taskの追加頻度や更新頻度も判断材料になると感じました。

Taskが比較的固定的で、環境の一部として管理したい場合はTerraform管理と相性が良い一方で、
追加や修正が頻繁に発生する場合は、Git管理に寄せた方がレビューや変更履歴の管理がしやすいと考えています。


■ Table定義

テーブル定義もケースによって分かれます。

  • 固定的なテーブル → Terraform
  • 業務ロジックに密接 → Git

今回は後者のケースを想定し、Git管理としています。

Terraformは「最終状態を一致させる」思想であるため、
変更手順ではなく結果に基づいてリソースを更新します。

この特性により、テーブル定義の変更が意図しない動作を
する懸念があるため、Terraform管理する場合は注意が
必要になります。
(例:再作成が発生し、データが消える可能性など)


■ Workspace(補足)

SnowflakeのWorkspaceはGit連携機能を持っており、
Workspace単位でGitリポジトリと連携することが可能です。

Workspaceについても、内容によってはGit管理に含める価値があると感じています。

特に、分析用SQLや定常作業の手順、障害対応時の確認SQLなどは、
再利用性が高く、変更履歴も残したいため、Git資産として管理しやすい対象です。

一方で、一時的な調査や検証用のSQLまで無理に管理対象にすると運用が重くなるため、
残す価値のあるものに絞って管理するのがよさそうです。


まとめ

TerraformとGitの管理対象は、以下のように整理しました。

■ Terraform

  • 環境の構成要素(低頻度・影響大)

■ Git

  • 開発資産(高頻度・レビュー重視)

このように役割を分けることで、
安全性と開発効率のバランスが取りやすくなると感じました。

※今回の内容はあくまで一例なので、
チーム構成や運用方針に応じて調整するのが良いと思います。


おわりに

Terraformで環境構築を行った後、
「何をどこで管理するか」は次の大きな課題だと感じました。

次回は、今回整理した方針をもとに、
SnowflakeのSQL資産をGitで管理する方法についてまとめてみたいと思います。

※本記事は運用前の設計整理としてまとめています。
実際の運用結果によっては、より適した棲み分けが見えてくる可能性があります。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?