[レポート] データアプリケーションのためのDevOpsの簡略化 #SnowflakeSummit

大阪オフィスの玉井です。

日本時間の2021年6月9日～10日に、Snowflake Summit 2021が開催されました。

当記事では、Simplifying DevOps for Data Applications（データアプリケーションのためのDevOpsの簡略化）というセッションのレポートをお届けします。

概要

Building, deploying, and maintaining data-intensive applications has its own set of unique challenges. It’s important to ensure app developers are equipped with the right tools to rapidly and reliably deliver applications. This session will show key capabilities of the Snowflake Data Cloud that enable developers to simplify their DevOps pipeline. It will also show how Snowflake can work with, and extend, existing tool chains that many developers use today.

You will also hear from the Chan Zuckerberg Initiative on its experience with DevOps using Snowflake.

Snowflakeのデータを利用するアプリケーションの開発には、独特の課題があります。そういったアプリ開発を「DevOps」なやり方で行うために利用できるSnowflakeの機能や外部ツールの紹介が行われました。

セッションレポート

前段

今回のセッションでは、データアプリケーションのDevOpsを簡素化する方法について説明します。私はSnowflakeのDeveloper Relation ManegerであるDaniel Meyersです。

こんにちは、SnowflakeのシニアセールスエンジニアのJeremiah Hansenです。

そして私はAllison Doamiです。Chan Zuckerberg Initiativeでデータインフラチームのソフトウェアエンジニアをしています。

今日は、DevOpsの概要、DevOpsとSnowflake、Snowflakeを使ったDevOpsのやり方、について説明します。また、DevOpsとエコシステムで使用できる一連のツールについても説明します。次に、Chan Zuckerberg Initiativeが、Snowflakeを使ってDevOpsをどのように活用しているか（具体的にはTerraformについて）説明します。また、Snowflakeを使ったDevOpsを始めるための次のステップについても説明していきます。以降は、Jeremiahにお任せします。

DevOpsとは？

まず始めに、DevOpsとは何かを説明しておきたいと思います。

業界では、色々なワードが使われていますが、これらはすべて似たような意味を持ち、重複しているのです。

私たちは、ソフトウェアアプリケーションを開発する際、人間が行うことと自動化できることとの間でバランスを取ろうとしています。つまり、何が手動で、何が自動化されているか、ということです。このスライドは、そのイメージを描くのに役立つと思います。

安全なソフトウェア開発のライフサイクルとは、 設計からデプロイ、そしてコードの監視まで、さまざまな活動を行うことです。そして、これらの活動の多くは人間の手によって行われます。ソフトウェア開発手法としてのアジャイルは、こうした人間の活動に焦点を当てています。そして、DevOpsは自動化を目的としています。では、これまで手作業で行われていたその他の活動を、どのようにして自動化することができるでしょうか。そして、それらを自動化し、より再現性の高いプロセスにするにはどうすればいいのでしょうか。

このように、アジャイルとDevOpsの区分を考える際、こういった考えは、多少なりとも参考になると思います。

さて、なぜDevOpsが重要なのでしょうか？これは、とてもよく聞かれる問いです。今日、誰もが「DevOps」について尋ねています。私は多くの見込み客や顧客に、「DevOps」と「Snowflake」をどのように行うかについて話しました。これは難しいことです。

このスライドでは、特に、データのDevOpsを行う上での課題についてお話しします。これはRedgate社が行った、2019年の調査です。ちなみに、2020年の調査でも採用率はほぼ同じでした。アプリケーション側とデータベース側では、違いがあることがわかります。アプリケーションの開発者にとっては、DevOpsのプラクティスがより成熟し、ツールもより成熟しています。そして、これらのプラクティスをより多く採用しています。

例えば、最も重要な「バージョン管理」とは、すべてのコードとアプリケーションのコードとファイルを管理することを言います。しかし、ほとんどのデータエンジニアは、いまだにコードを追跡していませんし、追跡しているとしても、半分程度です。これらはほんの少しの課題に過ぎません。しかし、私たちが目指しているのは、これらのプロセスをより多く自動化できれば、ビジネスに大きな利益をもたらすことができるということです。

スライドの左側にあるように、これらのメリットは、ソフトウェアをどれだけ早く提供できるか、そして、提供できるソフトウェアの品質と関連しています。優れたテスト手法を持つことで、データエンジニアリングの過程で作成したコードが正しいかどうかを検証することができます。そして、より早く、より自信を持ってデプロイすることができるのです。その結果、納品コストが下がり、最終的には、より良いソリューションをビジネスや顧客に迅速に提供することができるのです。

だからこそ、私たちが追い求めているのは、データためのDevOpsを行う上での課題なのです。こういったことを「DataOps」と呼ぶこともあります。

ここでは、5つのカテゴリーに分けて考えています。これらは、アプリケーション開発とは異なります。先ほどデータベースの話をしましたが、データベースを扱うには「状態（State）」に対処しなければなりません。データプラットフォームやデータウェアハウスを考えると、そこにはたくさんのデータがあるはずです。これは重要なことです。過去のデータは、ソースシステムにはもう存在しないかもしれません。アプリケーションをデプロイする際には、そこにあるコードを上書きすることができます。データベースのデプロイメントは非常に簡単ですが、データベースを失うわけにはいきません。

デプロイメントの際にダウンタイムが発生することもありません。そして、データの処理には長い時間がかかりますから、ダウンタイムなしに処理できるようにしなければなりません。

ロールバックについて。データベースのDevOpsを行う上での大きな課題の一つは、バックアップです。デプロイメントを行う前に、何か問題が発生したときに復元できるように、すべてのバージョンが保存されていることを確認しなければなりません。Snowflakeについては、次にその利点を説明します。Snowflakeを使えば、もっと簡単になります。

先ほども言ったように、DevOpsの分野ではデータのテストが常に課題となっており、私も過去に多くのフレームワークを構築しましたが、データの管理やテストケースの管理には苦労しました。DevOpsの核心は、テストを自動化することです。

その他にも、変更管理やその他の問題があります。

以上で、なぜ私たちがDevOpsを行うのか、そしてその課題について、簡単な概要をご紹介しました。次のセクションでは、Danielが、Snowflakeがこれらの課題にどのように対処するかを説明します。

SnowflakeでDevOpsを行う

従来のシステムがデータベースを管理しようとしたときに直面するであろう課題のいくつかを見てきましたが、私たちはDevOpsの哲学を使っています。興味深いことに、Snowflakeの強力な点は、私たちがクラウドの中で生きているということです。また、過去には、私たちも、同じような課題を数多く経験してきました。そのため、Snowflakeを設計・開発する際には、DevOpsを念頭に置いています。

DevOpsのライフサイクルを簡素化するためにSnowflakeがどのように設計・開発されたかについては、Ebookにまとめています。今回は、Snowflakeができる最もインパクトのある方法をいくつかご紹介します。

1. 独立環境をいくらでも作ることができる

これはどういうことでしょうか？また、それはどのようにして行うのでしょうか？

根底にあるのは、Snowflakeのユニークでパワフルなアーキテクチャです。このアーキテクチャは、いくつかの異なるレイヤーで構成されています。一番下にあるのは、特定のパブリッククラウドに依存しない層です。ここでは、SnowflakeがGoogle Cloud、AWS、Azureなどのクラウドプロバイダーと直接かつネイティブに対話します。ネイティブなAPIとネイティブな技術を、クラウドプロバイダーごとに使用することができるのが特徴です。

次に、集中型のストレージレイヤーです。これがすごいのは、構造化されたデータ、半構造化されたデータ、さらには非構造化されたデータなど、どんな形式のデータを使っていてもいいということです。そのデータを保存し、分析するための一元化された場所があるのです。

次は、マルチクラスターコンピュートレイヤーです。この層では、アプリケーションやチームが必要とするコンピューティングリソースの数を、シームレスに増減させることができます。ここでユニークなのは、Snowflakeのコンピュートは、ストレージから分離できるという点です。つまり、アプリケーションにSnowflakeを搭載することで、アプリケーションが、他のアプリケーションやシステム上の他のユーザーとコンピューティングリソースを競合しないように設定できるということです。これは、アプリケーションごとに必要なSLAが異なる場合に有効です。

この上は、クラウドサービスレイヤーです。クラウドサービスレイヤーは、Snowflakeの運用の頭脳となるものです。その下にあるコンピュートレイヤーとストレージレイヤーを活用します。Snowflakeに格納されているデータを他のチームやお客様と共有したり、コラボレーションを行うこともします。クエリの自動最適化が行われ、管理するのもこのレイヤーです。また、データのセキュリティとガバナンスを管理する場所でもあります。誰がそのデータにアクセスできるのか、データのマスキングなど、いつアクセスできるのか、などですね。ユーザー管理のトランザクションや、Snowflakeが提供する自動化されたメタデータの情報もここで行われます。これらはすべてSnowflakeのアーキテクチャの一部であり、Snowflake Data Cloudの原動力となっています。

このアーキテクチャーをDevOpsの観点から見ると、いくつかの異なる機能を備えているので強力です。

まず、コンピュートとストレージの両方を別々に弾力的にスケーリングできるということです。また、ゼロにまでスケールダウンすることも可能です。これらの要素は、コードを使って作業を自動化しようとしているDevOpsチームにとって非常に重要です。また、コストの最適化にもつながります。

次に、SLAですが、コンピュートをそれぞれ独立させることで、テスト開発、ステージング、本番環境など、アプリケーションやワークロードごとにSLAを設定することができます。Snowflakeでは、ゼロコピークローニングなど、1つのSQLステートメントでこれらの要素をすべて管理できるので、非常に強力です。また、同時実行のための拡張（オートスケーリング）が可能です。この機能は、手動で介入する必要がないほど強力です。アプリケーションが顧客からの負荷を受け始めたら、自動スケーリングが行われるように設定することができます。これにより、クエリのパフォーマンスを一定に保つことができ、お客様用のSLAに反映されます。このように、Snowflakeが提供するアーキテクチャが、SnowflakeにおけるDevOpsの簡素化を可能にしているのです。

2. VARIANT型を利用してスキーマの変更を減らす

VARIANT型とは、Snowflakeが半構造化データをネイティブにサポートするために必要な機能です。半構造化データとは、JSON、XML、Avroなどのことです。半構造化データをサポートするというアイデアは、構造化データと同じテーブルに半構造化データを保存できるという点で強力であり、私が特に気に入っている理由でもあります。ハイブリッドテーブルという概念があり、半構造化データと構造化データの両方を同じクエリで同時に照会することができます。これには、多くのデータベース管理者がすでに慣れ親しんでいる標準のSQLが使用されています。また、VARIANT型なので、テーブルのスキーマを変更することなく、データの実際の構造やJSONオブジェクトを変更することができます。とてもパワフルです。

また、「ゼロコピークローン」と呼ばれるものもサポートしています。これは、すでにディスク上にある既存のデータへのポインタを利用してクローンを作成するというものです。バイト内のビットを複製する必要がありません。つまり、追加のストレージを消費することなく、データを分離して変更できるというメリットが得られるのです。つまり、DevOpsチームにとっては、本番環境と開発環境の両方で同じデータを参照することができ、同じビットとバイトを参照しているため、コストを削減しながら、変更を分離することができるということです。

また、定期的にデータを更新する必要がないため、より新鮮なデータを得ることができます。これは、アプリ側の機能追加にも有用です。なぜなら、アプリケーションやワークロードの成長に伴い、定期的にデータを更新したり、レガシーシステムでクローンを作成したり、データを丸ごと複製したりすることができなくなるからです。ゼロコピークローニングでは、その心配はありません。追加のストレージコストをかけずに、本番データ全体を入手でき、より新鮮なデータを得ることができるのです。これは、現在のSnowflakeが持つ最大かつ最もインパクトのある機能の一つです。これにより、チームのDevOpsの負担を軽減することができます。

Snowflakeで使用できるDevOpsツール

それでは、Jeremiah氏より、Snowflakeが持つツールエコシステムと、リソースを管理するために使用できるツールについて詳しくお話していただきます。

それでは早速、ツールの話をしていきましょう。このスライドはプレイブックのようなもの…サッカーのプレイブックのようなものだと思ってください。

このスライドのポイントは、DevOpsについて考えるとき（特にSnowflakeについて考えるとき）、Snowflake以外にも考えるべきことがあるということです。つまり、エンド・ツー・エンドの観点から、データ・エンジニアリングのソフトウェア開発ライフサイクルを自動化しようとすると、いくつかの要素が絡んでくるのです。私はサッカーの専門家ではありません。だから、選手の名前をすべて挙げることはできません。しかし、ソフトウェア・オートメーション・ツールを見れば、それはクオーターバックのようなもので、起こっていることすべてを指揮するものです。これらの作業の基礎となるのは、これらの異なる分野の定義がすべてコードで管理され、自動化されたプロセスで提供されることです。前のスライドでも説明したように、これは難しいことです。ほとんどのデータベース・データ・エンジニアは、いまだに、ソース・コントロールなる仕組みで全てのコードを追跡する、というようなことはしていません。これらが基礎となる部分です。

そして、その基礎の上を見ると、管理しているものがいろいろあります。クラウド・リソースを管理しています。ストレージ・アカウントやソリューションの一部である他のクラウド・サービスがあるかもしれませんし、Snowflakeもあります。また、データベースの変更管理という側面もあり、データベース内のオブジェクトをどのように管理するかということにも関わってきます。また、データレプリケーションやデータ統合ツールなど、使用するツールに応じて、データエンジニアリングプロセスを支援する他のツールもあります。これらはすべて、ソフトウェア自動化ツールの助けを借りて、制御し、ソースコントロールで管理し、デプロイする必要があります。

このように、SnowflakeでDevOpsを実現するためには、何が必要で、何を考えなければならないのか、を理解してもらうために、最低限の説明をしました。

次に、データベースの変更管理に特化して、どのようなツールがあるのか、それぞれのツールについて簡単な説明をしたいと思います。

宣言的アプローチと命令的アプローチ

ツールの紹介の前位に、これらのツールの2つのモードについて説明します。この違いを理解することが重要です。

ずばり、宣言的なアプローチと命令的なアプローチがあります。

基本的にやっていることは同じで、テーブル、ビュー、ストアドプロシージャ、ステージなど、管理したりデプロイしたりするさまざまなオブジェクトを持っています。しかし、それらをどのように管理するかは、アプローチによって異なります。

宣言型では、すべてのオブジェクトに対して単一の定義をバージョン管理する、という考え方をします。スライドの例として、テーブルFOOがあります。このテーブルを変更する際には、同じファイルを編集して定義します。これは非常に自然な方法で、バージョン管理ツールを見れば、いつでもオブジェクトがどのように見えるべきか、宣言的バージョンの最新版を見つけることができます。

ここで問題になるのは、テーブルのデプロイ方法です。すでにオブジェクトがあり、テーブルも作成されていて、新しいカラムを追加したい場合、CREATE TABLEステートメントを再度実行することはできません。そこで必要となるのが、ソースとターゲットの2つのスキーマ間の差分を取るスキーマ差分ツールです。これらのツールは、デプロイを支援するために、ALTERコマンドや命令形のコマンドを生成します。これは宣言的なもので、命令的なものは少し違います。

あなたがすることは、基本的にバージョンスクリプトの管理です。それぞれのバージョンスクリプトは、あなたが作成したスクリプトの内容を表しています。そして、データベースにどのように移行するかを伝えることができるのです。つまり、最初のバージョンでテーブルを作成します。その後、2つ目のバージョンでは、どこでALTER文を実行するのでしょうか？それは適切なALTERコマンドを含む新しいスクリプトになるのでしょうか？

そこで問題になるのが、これらをどのようにして正しい順序で適用するか、ということです。この分野のツールは、対象となるデータベースのバージョンを追跡するのに役立つものです。そして、バージョン管理されたファイルには、これらのバージョンも含まれています。そして、どのバージョンが欠けているかを見つけ出し、正しいバージョンを正しい順序で適用することができます。

このように、2つの異なるアプローチがあります。今回紹介するツールのほとんどは命令型のアプローチをとっています。しかし、より宣言的なアプローチをとるものもいくつかあります。

Snowflakeと連携できるDCMツール

Snowflake用の人気のDCMツールはたくさんあります。これは包括的なリストではありません。お客様やパートナーとの会話の中で、最も多く質問されるツールがこれらです。そのため、これらのツールの簡単な説明をしておきたいと思います。しかし、先ほど申し上げたように、他にもたくさんのパートナーやツールがあります。その中でも特に重要なのは、これから始めようとしている人のためのツールです。

おそらく最も簡単な方法は、schemachangeやFlywayのようなツールから始めることでしょう。どちらも非常によく似た方法で動作します。どちらも命令型のツールです。

schemachangeはSnowflakeが公式に提供しているものではありません。これは、私が開発を支援したツールです。これはFlywayをモデルにしています。Flywayの方が歴史が長く、他の多くのデータベースをサポートしており、追加機能も利用できます。また、フリーミアムモデルを採用しており、いくつかの機能は無料で利用できますが、いくつかの機能は追加料金を支払う必要があります。しかし、どちらも使い始めるには素晴らしい製品です。また、先ほど言ったように、どちらも命令型のスタイルを採用しています。

Terraformは、今日のセッションの主題のようなものですが、宣言的なスタイルのアプローチを採用しています。このプロジェクトは、Chan Zuckerberg Initiativeによるオープンソース・プロジェクトです。この件に関しては、後でAllison氏から話を聞くことになると思います。次のスライドかその次のスライドで、データベース開発のライフサイクル全体の中でTerraformがどのように位置づけられるかをお話しします。しかし、Terraformは、オブジェクトをセットアップするには最適です。しかし、現時点では、テーブルに使用することはお勧めできません。Terraformに使用する言語は、HashiCorpの設定言語と呼ばれるもので、詳しくは後述します。そのため、SQLで変更を記述することはありません。その様子は後で行われるデモでもご覧いただけます。

そして、このスライドで説明する最後のツールはdbtです。これはよく出てきますね。dbtはデータベースオブジェクトの一部を管理してくれます。テーブルやコードの一部ですね。しかし、そうでないものもあります。だから、他のツールと重なる部分があるんですね。また、JinjaとSQLの組み合わせが使えます。

SQITCHは、Perlで書かれた古いツールなので、CI/CDパイプラインにあったものをデプロイする場合はコンテナが必要です。

Liquibaseも最近Snowflakeをサポートしました。もともとXMLベースの構成だったものが、他のSQLスタイルもサポートするようになったのです。

SQLAlchemy Migrateは、すでにSQLAlchemyを使用している人には良いツールで、SQLで書くのとは少し違うPythonで書かれたスクリプトを得ることができます。

SqlDBMはSaaS製品です。SqlDBMは新しいツールで、市場向けのデータ・モデリング・ツールとして開発されました。Snowflakeのすべてのオブジェクトをサポートしていますが、まだすべてのオブジェクトをサポートしているわけでは ありません。しかし、将来性はあります。宣言型のアプローチを採用しており、完全なサービスとして提供されているので、注目しておきたいですね。

これらのツールについてまとめますと、選択肢はたくさんあります。もし、あなたがこれらのツールに慣れ親しんでいて、過去に使用したことがあれば、それらは私が話したSnowflakeと連動しています。そして、それは素晴らしい選択肢となり得るのです。もしあなたがゼロから始めるのであれば、schemachange、Flyway、Terraformなどのツールが良い選択肢となるでしょう。

Terraformについて

それでは、Alison氏のパートに引き継ぐ前に、最後に一言。

Chan Zuckerberg ProjectがオープンソースのSnowflake用のコネクタを開発しました。このツールを使っているお客様の声としては、Terraformを使っている場合はTerraformを、Snowflakeを使っている場合はSnowflakeを、それぞれアカウントレベルのオブジェクトを管理するために使いたいということでした。つまり、アカウントの設定を支援するのです。例えば、ウェアハウス、ロール、データベース、パーミッションなどです。しかし、実際のテーブルについては、dbtのようなものを使うか、別のデータベース変更管理ツールに任せることになります。これは、全体をTerraformで管理するのに適した場所だと思います。それでは、Allison氏に引き継いで、Chan Zuckerberg Initiativeで取り組んできたことを説明してもらいます。

Chan Zuckerberg InitiativeのTerraformを使ったデモ

会社紹介

私の名前はAlisonです。Chan Zuckerberg Initiativeのデータ・インフラストラクチャー・チームでソフトウェア・エンジニアをしています。とても長い名前なので、私たちはCZIと呼んでいます。最初に、CZIとは何かを話します。そして、Snowflakeをどのように使用しているか、Snowflake用のTerraformプロバイダーとその貢献方法について、少しお話しします。

CZIは、 Mark Zuckerberg氏とPriscilla Chan氏によって設立されたフィランソロピーで、テクノロジー、コミュニティ主導のソリューション、コラボレーションを活用して、社会の最も困難な課題を解決するための活動を行っています。

私たちは、エネルギーを注ぐべき3つの分野を選びました。1つ目は教育。2つ目は「正義と機会」。そして3つ目は科学と教育です。

私たちは、生徒、教育者、家族と協力して、学業成績だけでなく、身体的、社会的、情緒的、そしてアイデンティティの発達をサポートする「子ども全体」の考え方を中心に、個人に合わせた学習ツールを構築し、正義と機会を提供しています。

私たちは、刑事司法制度の改革、住宅価格の適正化、移民制度の改革に取り組んでいます。これらの課題に最も深く関わっている組織やリーダーから学び、パートナーとなることで、私たちはサービスを提供するコミュニティと共に活動しています。

最後に、科学の分野では、今世紀末までにすべての病気を治療・予防することを目指しています。これは非常に大きな目標です。この目標を達成するために、私たちは分野全体を発展させるような科学研究に助成金を提供し、科学界と協力して革新的な技術を構築して資金を提供し、科学における学際的な協力関係を促進することで、進歩を加速させようとしています。

Terraform

私がこのセッションで話すメインコンテンツは、Terraform（のSnowflake用のプロバイダ）についてです。

CZIの全体の背景を少し説明すると、私たちはメインのデータウェアハウスとしてSnowflakeを使用しており、SnowflakeなどのインフラをすべてTerraformで管理しています。インフラをコードとして管理している最大の理由の1つは、AWSなどのリソースをユーザーインターフェイスで管理するのは手に負えないと考えたからです。私たちは、監査能力や行動の帰属が欠如しているため、UIでリソースを管理すべきではないと考えています。Terraformプロバイダを作成して使用する前の課題は、権限がないために何かにアクセスできないときに、自分自身にアカウント管理者権限を与えてしまうことでした。これはコードを使っていないので、権限の変更をインタビューすることもできず、基本的に誰もがAdmin権限を持つことになってしまいました。これはセキュリティ上の悪夢だと思っています。

しかし今では、Terraformプロバイダーを利用し、GRANT操作をすべてコードに落とし込むことで、誰が何にアクセスできるかをより明確にコントロールできるようになり、コードレビューでこれらのアクションを検証できるようになりました。また、Oktaと組み合わせることで、より安全なパーミッションワークフローを構築することができます。

Terraformプロバイダーを使うことには多くの利点があります。最大の頭痛の種は、他のシステムが、Fivetranや他のETLツールなどの、Snowflakeと連携するリソースに触れたときに、私たちのステートのファイルを追跡できないことです。そのため、リソースを手動でインポートしたり、ステートファイルを変更したりしなければなりません。しかし、Terraformの導入とコミュニケーションの改善により、この問題は軽減されました。

私たちはTerraformのビッグユーザーなので、Snowflake用のプロバイダを作成する必要があると考えましたが、当時は、すぐに利用可能なプロバイダがありませんでした。ですので、2019年に開発に取り掛かりました。

プロバイダを開発する際に直面した課題としては、ユーザーやロールに付与できるすべての権限のリストのように、絶えず変化するSnowflakeの付与権限に対応し、それらをすべて実装する方法を考えなければなりませんでした。また、Snowflakeが提供する様々なリソースについて、一貫したドキュメントを作成することも必要でした。幸運なことに、これらの問題のうち2つはオープンソースのソリューションで解決できました。これは素晴らしいことです。私はオープンソースのソリューションを大いに支持しています。ok-to-testというとても素晴らしいツールなのですが、これはスラッシュコマンドで、書き込み権限を持つユーザーが、外部のコントリビューターのコードをSnowflakeのテスト用のクレデンシャルを使ってテストできるというもので、環境変数として保存され、秘密が守られます。ですから、もしあなたが自分でリポジトリに貢献していて、私や他のビューアーがshaと書かれた奇妙なコマンドを見たら、それは何をしているかというと、あなたのコードを私たちのsecretの一部でテストしているのです。だから、これをテストしてもいいんです。これはとてもクールなことだと思います。これまでは、CD/CIチームの誰かがローカルでプルリクをチェックアウトし、テストを実行して、失敗したら手動でプルリクに報告し、テストが成功するまでこのワークフローを繰り返していましたからね。今では、プルリクをより効率的にテストできるようになり、とても助かっています。

次に、ドキュメントのジレンマを解決するために、Terraformのプラグインを利用して、ドキュメント作成プロセスを自動化しました。このプラグインは、Terraformファイルを読み込んで、どのような引数が必要なのか、その引数ごとの説明、リソースの使用方法やインポート方法の例を説明するドキュメントを作成します。これにより、私たちのプロバイダーを使ってTerraformでリソースを作成するために必要なことを、ユーザーが明確に理解することができます。

また、ユーザーといえば、このプロバイダのインストール数が30万件を超えていますが、これはかなりすごいことです。これは、多くの外部協力者がいなければ実現できなかったことです。この1年、TerraformのすべてのSnowflakeリソースをカバーするために、多くのアップストリーム・コントリビューションを得られたことは、非常に喜ばしいことでした。多くのチームが自分たちのSnowflakeリソースやコードを管理しているのを見るのは素晴らしいことです。

デモ

それでは、Terraformでプロバイダを使ってリソースを作成する簡単な例を紹介します。

Terraformに慣れていない方のために、まずはTerraformの基本を説明します。resourceは、Terraformの中で最も重要な要素で、1つ以上のインフラ・オブジェクトを記述します。これらのインフラ・オブジェクトは、Snowflakeのロールから、Snowflake、DB、GRANTなどの自己に似た外部機能まで、何でもあります。

resourceを定義する際には、まずresourceを宣言します。ここでは青色で表示されていますが、続いてタイプ（ここにあります）とローカル名（ここではSNOWFLAKE_SUMMITです）を指定します。一般的にプロバイダは、Terraformが管理できるリソース・タイプとデータ・ソースのセットを追加します。Terraformで管理したいresourceを管理するためには、Terraformの設定で使用しているプロバイダを指定する必要があります。プロバイダがなければ、何も管理できません。他のクラウドサービスのための一般的なプロバイダとしては、AWS、Kubernetes、GCPなどがあり、Terraformのウェブサイトで見つけることができます。

さて、コードを振り返ってみると、このresourceブロック内のすべては、resource自体の設定引数です。必要な引数とオプションの引数は、先ほど言ったようにプロバイダのドキュメントで確認できます。ここでは、snowflake_roleを作成しました。この例のためにSNOWFLAKE_SUMMITと名付けました。このロールをユーザーとメールに付与するGRANTと、DEMO_DBという既存のデータベース内にSNOWFLAKE_SUMMITというスキーマを作成し、先ほど作成したロールにオーナーシップを付与するsnowfalke_schema_grantを作成しました。

このように、必要なリソースを書き出した後、何を作成するかの計画を立てることができます。Terraformのプルリクエストをすべて適用してくれるTerraform Enterpriseを導入する前は、プランをプルリクエストに添付し、レビュー担当者が自分の書いたコードから何を作るのかを確認する必要がありました。今ではTerraform Enterpriseがすべてをやってくれるので、感謝しています。しかし、ローカルにリソースを作成するためには、ある種のユーザーパスワード、ユーザー名、パスワードの認証情報が必要になります。スーパーユーザーではなく、個人の認証情報を使用することで、これらの行動や計画を実際の人物に帰属させることができます。

ここでは、Terraformを使って作成できるもののほんの一部を紹介しました。しかし、他にも多くの人々がプロバイダに貢献しています。どうぞご自由にリポジトリをご覧ください。

chanzuckerberg/terraform-provider-snowflake: Terraform provider for managing Snowflake accounts

そして、Terraformについては十分に語ったと思いますし、このワークフローを採用してプロバイダに貢献することを納得していただけたのではないかと思っています。それでは、次のステップについてDanielに話してもらいましょう。

まとめ

ありがとう、Allison。私も賛成です。このTerraformプロバイダーがこれまでも、そして現在も、オープンソースに積極的に関わっているのを見るのは本当にエキサイティングです。ぜひGitHubでTerraformプロバイダーをチェックして、追加したいものがあればプルリクエストをしてみてください。これは楽しみですね。

では、Snowflakeデベロッパーとして次のステップに進むにはどうすればいいのでしょうか？まず最初に、Snowflake for Developersの「Build with a Snowflake」にアクセスしてください。また、Snowflake GuidesにあるTerraformガイドを完成させることもできます。最後に、Snowflake LabsでTerraformガイドのソースコードをダウンロードすることができます。最後になりましたが、ありがとうございました。

おわりに

かなりディープで濃密なテクニカルセッションでした。TerraformはAWS等のパブリッククラウドでは非常にポピュラーなツールですが、Snowflakeにも使用できるのは知りませんでした。SnowflakeはGUIが非常に優れているので、手動操作で何でもしちゃいがちですが、実際の本番運用となれば、大量のリソースをさばいていかないといけないので、手動でやるのはデメリットが強すぎるのでしょうね。

他にも、多種多様なツールが紹介されていたので、どこかで試してみたいです。印象的だったのは、「dbtはもう有名ですよね」みたいな紹介の仕方だったこと。もうdbtはUSでは普通に誰でも知ってるツールなんでしょうね。

参考