データウェアハウスの構築、より広く言えばデータプロダクト全般の開発は、通常のソフトウェア開発との境界がどんどん薄れてきています。つまり、ソフトウェアエンジニアリングで長年当たり前とされてきたソフトウェア開発ライフサイクルの考え方を、データプロジェクトにも適用できる、そして多くの場合適用すべき段階に入ったということです。本記事のテーマはSnowflakeのDevOps。Snowflakeはこの数年でこの領域を大きく強化しており、DevOps、より厳密にはDataOpsの原則に沿ってデータプロジェクトを運用できる機能を次々と投入しています。
第1回となる本記事では、SnowflakeがDevOps向けに用意している機能を整理します。次回は実装編として、CI/CDパイプラインの構築方法やSnowflakeインフラのデプロイ手順を取り上げる予定です。その前にまず、DevOpsとDataOpsという基本概念を簡単に振り返っておきましょう。
DevOpsとは
DevOpsは、開発と運用を一体化させ、ソフトウェアをより速く、より確実にビルド・テスト・リリースするための考え方です。柱となるのは自動化、コラボレーション、そして本番リリース時の障害リスクを抑えること。複数領域のベストプラクティスを束ねた方法論で、目指すゴールは明確です ― 自動化できるものはすべて自動化し、プロセス全体をカバーすること。コードは必要なだけ何度でもビルド・デプロイ・テストされるべきです。DataOpsは、この発想をデータチームに持ち込んだものです。アプリケーションコードを管理するだけでなく、データパイプラインや変換処理、分析までもソフトウェアと同じように扱い、バージョン管理し、テストし、自動でデプロイする ― 一言で言えば、データ世界のDevOpsです。Snowflakeにはすでに、自動化されたデータパイプラインの構築やインフラデプロイの管理に組み合わせて使える機能が数多く揃っています。それらを一つずつ見ていきましょう。
宣言的な変更管理
まず取り組むべきは、Snowflakeやデータベースのインフラをコードで定義することです。そのためにSnowflakeが用意しているのがCREATE OR ALTERです。これは、Snowflakeのオブジェクトを宣言的に定義できる機能。宣言的とは、バージョン管理や差分の段階的な反映を自分で気にする必要はなく、「最終的にこうあってほしい」という状態だけを書けばよい、ということです。たとえばテーブルスキーマやタスク、ビューの「あるべき姿」を記述すれば、あとはSnowflakeが現状と定義を自動で突き合わせ、必要な差分だけを裏側で適用してくれます。
CREATE OR ALTER
CREATE OR ALTERでは、このキーワードを使ったDDLスクリプトを書くだけで、実行後にオブジェクトが定義どおりの状態になることをSnowflakeが保証します。再作成は不要です。これは特にテーブルのようなオブジェクトで重要で、列の追加や削除といったスキーマ変更のたびにDROPして作り直していては、データ消失のリスクがあります。CREATE OR ALTERなら既存の状態を保ったまま、必要な変更だけを適用できます。
大まかに、CREATE OR ALTERは次のように動作します。
- スクリプトとデータベース上の現状を比較
- オブジェクト更新に必要なDDL文を生成
- そのDDL文を実行
Snowflakeは、CREATE OR ALTERで定義できるデータベース/アカウントレベルのオブジェクトを幅広くサポートしています。主なものは次のとおりです。
- Warehouse
- Database
- Schema
- Table
- View
- Stage
- Role
- Database Role
- Application
- Function
- External Function
- Procedure
⠀…対応オブジェクトは今も継続的に追加されています!
EXECUTE IMMEDIATE FROM
SnowflakeのDevOps機能としてもう一つ強力なのがEXECUTE IMMEDIATE FROMです。これは、内部ステージやGitHubリポジトリに置いたファイルからSQLコマンドを直接実行できる機能で、ファイルには標準SQLだけでなくSnowflake Scriptingブロックも記述できます。
これはまさにSnowflakeへのオブジェクトデプロイにうってつけの機能です。複雑なインポートの仕組みを用意しなくても、オブジェクト定義を含むDDLスクリプトをステージに置き、そこから直接実行できる ― シンプルで効率的です。最近の強化点として、Jinjaテンプレートのサポートが加わりました。Jinjaテンプレートを使えば、次のような要素を取り入れて、SQLスクリプトやDDL定義を大幅に動的にできます。
- 変数
- ループ
- 条件分岐
- マクロ など
たとえば環境変数を使えば、デプロイをパラメーター化してターゲット環境を動的に切り替えられます。ループを使えば、ユーザーやウェアハウスなどのオブジェクトを反復処理でき、作成・保守がぐっと楽になります。テンプレート内でステージ上の別ファイルの内容を取り込むこともでき、活用の幅はさらに広がります。
EXECUTE IMMEDIATEは、自動デプロイを組む際に大きな武器になります。では次に必要なものは何でしょうか。当然、DDLスクリプトをバージョン管理下に置きたくなるはずです。何が起こるかわからない以上、変更を巻き戻せること、何が変わったかを追えること、誰が変えたかを把握できることは欠かせません。バージョン管理は、デプロイに透明性・説明責任・安全性をもたらします。
GIT連携
SnowflakeにはネイティブのGit連携も用意されています。リモートリポジトリにコードを置きつつ、それを内部ステージと同期できるため、すべてのファイルをSnowflake内から直接実行可能な状態で扱えます。現時点では一部例外を除き読み取り専用ですが、完全に自動化されたデプロイパイプラインを組むうえで欠かせないピースを埋めてくれます。
では、GIT連携とEXECUTE IMMEDIATEを組み合わせて、リポジトリのユーザー作成スクリプトを実行してみましょう。
1: users.sqlファイルを作成
CREATE USER joe;
GRANT ROLE developer TO USER joe;
2: 変更をリポジトリにコミット
git add users.sql
git commit -m "Adding new user"
git push
3: リモートリポジトリの更新をSnowflakeのリポジトリステージに取り込む
1ALTER GIT REPOSITORY snowflake_git_demo FETCH;
4: Snowflakeでファイル内のコードを実行
1EXECUTE IMMEDIATE FROM @snowflake_git_demo/branches/main/sql/users.sql;
詳しくは別のブログ記事で解説しています。SnowflakeのGit連携機能の全体像とステップバイステップのガイドを掲載しており、次のような内容を学べます。
- SnowflakeのGit連携とは何か
- なぜこれほど注目に値する機能なのか
- ストアドプロシージャのハンドラーを手軽にデプロイする使い方
- Snowflake内でサポートされている操作
- 現時点での制限事項
- Git連携の多彩なユースケース
ここまでで、インフラをコードとして定義し、実行し、バージョン管理する方法を押さえました。では、まだ足りないものは何でしょうか。最後のピースがオーケストレーションで、ここには2つの視点があります。
1. Snowflake側の視点 ― どう接続し、どのファイルを選び、どうクエリを実行するか2. プロセス側の視点 ― それらをまとめて、さまざまなイベントから起動できる単独のパイプラインに仕立てる方法
ここではまずSnowflake側の視点に絞ります。プロセス側は、ゼロからパイプラインを組み立てる次回の記事で取り上げます。
SnowSQL
SnowSQLは元祖のSnowflake CLIクライアントで、UIで行える操作の多く ― クエリ実行、オブジェクト管理、データのインポート/エクスポートなど ― をコマンドラインから実行できます。主要なOSをサポートし、各種の認証方式にも対応しています。長年、特に管理者にとって定番のツールでしたが、そろそろ世代交代の時期です。新しい標準はSnowflake CLIであり、今後SnowSQLには追加されない機能も出てくる可能性があるため、これからはSnowflake CLIを優先するのが賢明です。
Snowflake CLI
こちらはオープンソースのプロジェクトで、当初はコミュニティ主導で開発されていましたが、現在はSnowflakeが完全にメンテナンスしています。CLIは主に、Snowflake内のさまざまなコード ― ストアドプロシージャ、関数、Native App、Streamlitアプリ、Snowpark、Snowpark Container Services、Gitリポジトリなど ― を扱う開発者向けインターフェースとして機能し、Snowflakeにおけるコードとインフラ管理を楽にする幅広いユースケースをカバーします。DevOpsの観点では、どちらのCLIでもSnowflakeに対してクエリを実行できるので、選択は好みの問題になることが多いでしょう。本記事ではCLIクライアントを使ってSnowflakeに接続し、次の操作を行います。
- Gitステージをリモートリポジトリと同期する
- EXECUTE IMMEDIATEコマンドでコードをデプロイし、ロール、ウェアハウス、データベースなどのインフラオブジェクトを作成する
Infrastructure as Code:素のSnowflake SQL以外の選択肢
ここまで、SnowflakeがDevOps領域で提供している基本パーツを見てきました。これらを組み合わせれば、堅牢で自動化されたパイプラインを組み、Snowflakeインフラを管理できます。とはいえ、選択肢はSnowflakeのネイティブ機能だけではありません。ほかにも強力なツールが多数あります。全体像をつかむため、代表的なものを順に見ていきましょう。
Terraform
Terraformは、この用途で最も広く使われているツールと言ってよいでしょう。Snowflakeオブジェクトをコードとして定義し、他のクラウドインフラと同じやり方で管理できます。すでにInfrastructure as Code(IaC)に慣れているチームには、ごく自然な延長として受け入れられるはずです。クラウドインフラの管理にすでにTerraformを使っているなら、それをSnowflakeまで広げるのは合理的な選択であり、多くのチームにとって第一候補になります。公式のSnowflakeプロバイダーはこの数年で大きく成熟し、最近GA(一般提供)に到達。新しいオブジェクトへの対応も継続的に追加されています。SnowflakeでのTerraform活用をさらに掘り下げたい方は、専用のブログ記事をご覧ください。
Permifrost
Permifrostは、Snowflakeの権限管理をコードで行うために設計されたオープンソースツールです。Python製で、ロール、付与、所有権をYAMLファイルで定義できます。権限をコードで管理するアプローチは、UIで手作業で設定したり生のSQLでGRANTを書いたりするのに比べて、スケーラブルで統制も効きやすくなります。Permifrostは宣言的なモデルでSnowflakeの権限を扱いますが、対応範囲は権限とロールに限られ、オブジェクトの作成や削除には踏み込みません。その点で、ほかの選択肢に比べると守備範囲は限定的です。
Titan
Titanも、Snowflakeインフラをコードでデプロイするためのオープンソースツールの一つです。Pythonで書かれており、Terraformの弱点をいくつか解消することを目指しています。たとえばロール間の動的な切り替え(SECURITYADMINとSYSADMINの使い分けなど)に対応し、Pythonベースの定義方式を採用しているため新しい言語や構文を覚える必要がなく、SQLにも対応。さらに、Terraformのようなstateファイルにも依存しません。
ただし、Titanはリソースの識別に名前を使うため、リソース名を変えると新しいリソースとして再作成されてしまいます。また現在も活発に開発中で、一部リソースへの対応はまだ限定的です。
もう一点補足すると、このプロジェクトは主に一人のメンテナーが支えており、その方は現在別の事業に注力しています。選択肢を比較検討する際は、その点も頭に入れておくとよいでしょう。
Schema change
最後に紹介するのは、おそらく最も歴史のあるツールです。Schema ChangeはPythonベースの命令型ツールで、元のオブジェクトに対する一連の変更(ALTER文)としてデプロイを行います。バージョン付きのスクリプトを管理し、変更がどう適用されてきたかの履歴を保持する必要があり、Schema Changeは履歴と比べて新しい差分だけを適用します。たとえば、Schema Changeでテーブルを作成し、後から列の追加・削除などの変更を入れたい場合は、新しいバージョン番号を付けたALTERスクリプトを書くことになります。
Schema Changeが扱うスクリプトは2種類。バージョン付きスクリプトと、繰り返し適用可能(repeatable)なスクリプトです。repeatableスクリプトは、ツール実行のたびに(変更が検出された場合に)毎回デプロイされます。これは、再作成が破壊的変更とみなされないビューなどで便利です。もう一つの重要な概念が、適用済みスクリプトの履歴で、これはデータベース上のテーブルに保存されます。
ここで、これらの代替ツールのメリットとデメリットを表にまとめてみましょう。
表を見るとわかるとおり、最適なツールは、自動化したい対象(インフラ、権限、SQLスクリプトだけ、など)、既存のスキル、プラットフォーム要件など、さまざまな要素で変わってきます。それぞれのツールに、フィットするシナリオがあるということです。
まとめ
ここまで、SnowflakeのDevOps向けネイティブ機能と、市場で利用できる代替ツールを取り上げ、SnowflakeにおけるDevOps全般の見取り図を整理してきました。次回は、ステップバイステップの実装ガイドに踏み込みます!
Tomáš Sobotík・Senior Data Engineer & Snowflake SME at Norlys
Tomasは長年にわたりSnowflake Data SuperHeroとして活動する、Snowflake全般のスペシャリストです。データ分野での経験は10年以上におよび、さまざまな業界・技術のプロジェクトで、Snowflakeデータエンジニア、アーキテクト、管理者として活躍してきました。コミュニティの中核メンバーとして自身の知見を積極的に共有し、多くの人にインスピレーションを与えています。O'Reillyのインストラクターとして、ライブのオンライントレーニングも担当しています。