Zenn
🤔

Terraformで管理するSnowflakeリソースについて考える

2024/10/10に公開
Terraform
IaC
Snowflake
idea

はじめに

Terraformを使ったIaC化は「属人性の排除・再現性・情報共有の簡便化」に繋がります。
ですが、いざTerraformで運用していると意外とTerraformのみでリソースを操作するのが難しい状況がありますよね。。
今回は私が触ったTerraform+Snowflakeの環境を通して

  • 管理しやすいリソース
  • 条件付きで管理が可能なリソース
  • 管理が難しいと思うリソース

を備忘録として残しておきます。
今からSnowflakeのリソースをTerraformで管理するぞ！みたいな人は参考にしてもらえると幸いです。

管理しやすいリソース

独占的に管理出来るリソースはTerraform管理したほうが良い。
(ここでは、リソースの追加・変更・削除の操作をTerraformのみから実行できる状態を独占的と言ってます。)
Snowflakeにおいては下記のリソース管理は独占的に管理しやすい。

リソース名 管理しやすい理由
ロール RBACの作成・管理は独占的に管理しやすい。権限の編集をする人は限られることが多いため。
リソースモニター PJの初期や契約更新時に変えるため、更新頻繁が低く独占的に管理しやすい。
ウェアハウス PJ初期や定期メンテナンスで作成・削除をするぐらいのため、独占的に管理しやすい。
データベース PJ初期に定義することが多い、DEV,(TEST),STG,PRODと多くてもリソースが3,4つに絞れるため独占的に管理しやすい
スキーマ モダンデータスタック位置づけのSnowflakeなら各DBにINTERFACE,{LAKE/RAW},DWH,{MART/ANALYSIS}のように3,4つのスキーマしか管理しないため独占的に管理しやすい
ストレージ統合 ACCOUNTADMINが所持する権限のため、操作できる人が限られる。また頻繁に更新をしないため独占的に管理しやすい。
通知統合 同上

条件付きで管理が可能なリソース

  • みんなで追加・変更・削除のルールが守れる
  • Snowflake Providerが対応している
    下記の部分はしやすいと思います。
リソース名 必要な条件
ユーザ ユーザ作成のフローがある。非エンジニア向けにデータシリアライズ言語に落とし込むGUIがある。このようなサポートやルールが必要。エンジニアのみであればルール提示のみで良さそう
ユーザとロールの紐づけ 同上
ファイルフォーマット テーブルと合わせてアドホックに作られる可能性が高い。外部テーブルのselectには必須のためシステム化まで話が進んだ場合に管理する。
UDF・ストアプロシージャ 同上
外部ステージ 同上

管理が難しいと思うリソース

ルールを作成してると作業が滞ってしょうがないパターン

リソース名 管理が難しい理由
テーブル/ビュー dbtを使う場合、管理範囲が被る。
データをアドホックに触りたいときにTerraformが壁となってしまう。

こごと

TerraformでIaC管理をやっていくうちにそのプロダクトのIaCをいじれる人は一人だけ・・・という怖い話に繋がらないようがんばります。。。
うまく使えば、属人性の排除・再現性・情報共有の簡便化と素晴らしいところが多いですしね〜
私はTerraformを使って管理することが多いですが、それ以外のIaCツールでも独占的に管理できるかは同じように検討できると思います。

Discussion