Snowflake オブジェクト管理あれこれ

この記事は Snowflake Advent Calendar 2020 の21日目の記事です。

Snowflake を中心に据えたデータ基盤を整える上で、様々な Snowflake オブジェクトの管理をどのように進めていくかという点はやはり気になるところです。
本記事では、実際に Snowflake を導入するにあたってこのあたりをどのように管理しようか、と検討/調査した内容を共有してみようと思います。
より良い方法があればぜひ教えて下さい :)

declarative か imperative か

Snowflake ではすべてを SQL によって操作することができます。
そこで、RDBMS などと同様に DevOps や CI/CD の加速をさせるためにデータベースチェンジマネジメント(DCM)ツールを使うことを検討するのが自然だと思います。

こうした DCM ツールには一般に declarative なものと imperative なものが存在するのですが、現状 Snowflake の周辺ツールにおいては、declarative に SQL ベースで管理できるツールは存在しません。
また、体感として imperative な DCM ツールですべての Snowflake オブジェクトを管理しようとすると、中には imperative な管理が適していないものがあるという印象です。
具体的には、ユーザやロール、権限周りに対しては特にそのように感じていて、意図しない状態になることを防ぐ意味でも一覧性を保つ意味でも declarative に管理しておきたいです。
実際に、下記の記事でも同様の文脈で下図のように Snowflake のオブジェクトを分類し、グループごとに扱い方を変えると良いのではないかと提案されています。

https://medium.com/@jeremiahhansen/a-new-approach-to-database-change-management-with-snowflake-8e3f0fee281 より

ではそれぞれをどのように管理していこうか、というところを見ていきたいと思います。

Users and Roles

Snowflake では SCIM を活用できます。

https://docs.snowflake.com/en/user-guide/scim-intro.html

私自身の所属組織ではカスタム IdP を選択することができるので、このあたりは同様の方法を取りたいなと思いつつ、現状は Terraform を使って管理しています。
SQL ですべて管理できるものを HCL で記述する気持ち悪さはありつつも、社内ですでに Terraform を全面的に使っていること、declarative にしたい種のオブジェクトであることが理由で導入しています。

provider snowflake {
  alias    = "SECURITYADMIN"
  region   = "ap-northeast-1.aws"
  username = var.username
  account  = var.account
  password = var.password
  role     = "SECURITYADMIN"
}

resource snowflake_role sandbox_admin {
  provider = snowflake.SECURITYADMIN

  name = "SANDBOX_ADMIN"
  comment = "sandbox データベースの管理ロール"
}

実行時のロールを指定するために provider を複数用意して alias を設定しているのがやや工夫ポイントかもしれません。

ちなみに Terraform v0.13 以上を使えるようであれば、3rd-party な Terraform プロバイダも簡単に扱えて便利です。

• 参考:
  • https://www.hashicorp.com/blog/automatic-installation-of-third-party-providers-with-terraform-0-13
  • https://github.com/chanzuckerberg/terraform-provider-snowflake#for-terraform-v013-users

Grants

やはりこちらも declarative に管理したいです。現状はどうしようかなと悩んでいるところですが、既存ツールとしては下記を発見しました。

• Snowflake-Labs/snowflake-rbgm
• gitlab-data/permifrost

開発自体は後者のほうが活発なようです。
機能も豊富ですし、設定の見通しも悪くなく管理しやすさもあるので、個人的には後者を採用したいところです。
あるいは、User and Roles ですでに Terraform を使っている場合は Terraform ですべてやってしまっても良いでしょう。

Other Database Objects

雑な分類ですが、残り全てです。(もう少し細分化しても良さそうですが...)
このグループに属しているオブジェクトは(相対的に) imperative な管理でも良さそうなので、ツールとしては Snowflake 対応をしていれば何でも良く選択肢はやや多めでしょうか。有名どころだと flyway や liquibase などが対応されているようです。

一方、私自身は現在は Snowflake-Labs/snowchange を試してみています。
Snowflake 公式ではないものの、中の人がメンテしているようなので一定の安心感があるというのが理由として大きいところでしょうか。

It follows an Imperative-style approach to Database Change Management (DCM) and was inspired by the Flyway database migration tool.

と README に書かれている通り、flyway のような一般的なツールと似通っているので、導入自体も容易です。履歴テーブルに実行履歴を保持していくというよくあるやつです。

2021/01/27追記: 現在はやはり snowchange ではなく Terraform に寄せようと検討中です。

おわりに

たくさんツールを導入して大変そうという感覚はなきにしもあらずですが、適材適所に使い分けていけると運用におけるリスクやコストを削減できるので、しばらくは情報を追っていきつつ改善できればと思っています。(本当は skeema や ridgepole, sqldef のような declarative なもので、かつ Snowflake に対応したツールがほしいところですが...！)

また、紹介した記事内ではここからさらに Dataset Object というグループに細分化しているようなのでそのあたりも調査してみたいところです。

ちなみに Snowflake は日本ではまだ情報が少ないので、普段は Reddit で情報収集することが多いです。興味があればぜひ見てみてください。

参考

• https://www.skeema.io/blog/2019/01/18/declarative/
• https://www.snowflake.com/blog/embracing-agile-software-delivery-and-devops-with-snowflake/
• https://medium.com/@jeremiahhansen/snowchange-a-database-change-management-tool-b9f0b786a7da
• https://medium.com/@jeremiahhansen/a-new-approach-to-database-change-management-with-snowflake-8e3f0fee281
• https://www.youtube.com/watch?v=vGqRyMlvYjo