 本記事は 夏休みクラウド自由研究 8/30付の記事です。 |
こんにちは、SCSKの松岡です。
今回は、Snowflakeをこれから利用する方向けに、環境構築で最低限抑えておきたいポイントをぎゅっと絞ってご紹介します。Snowflakeのアカウントは作ったけど何から始めよう…とお悩みの方はぜひご参考ください!
Snowflakeとは
Snowflake (Snowflake Cloud Data Platform)は、Snowflake社が提供するSaaS型のクラウドデータプラットフォームです。
データ管理、セキュリティ、ガバナンス、可用性、データレジリエンスをサポートしたフルマネージド型のサービスであり、ウェアハウスのスケーリング/ポリシー制御/データ共有の柔軟性などから、デジタルデータの一元管理に優れたプラットフォームとして注目を集めています。
利用する前に……
エディション
Snowflakeでは、4つのエディションが用意されており、利用するアカウントがどのエディションかによって、一部できることが異なります。
Snowflakeは従量課金制ですが、上位のエディションほど利用あたりの単価が高い点にも注意が必要です。
言語設定
Snowsight(Snowflakeを操作するウェブ画面)のデフォルト表示は英語ですが、アイコンから「My profile」を選択し、Languageで「日本語」を選択することで日本語表示に切り替わります。
システムロール
Snowflakeでは、「ロール」と呼ばれる単位でアクセス制御や権限管理を行います。
ユーザーには複数のロールを割り当てることができ、操作を行う際は、その操作ごとにロールを切り替えて(適切なアクティブロールを選択して)から実行を行います。
あらかじめ定義されたロールとして、以下のようなシステムロールが存在しています。
| ACCOUNTADMIN | アカウント内で最上位のロール。 アカウント管理者に限定して付与し、アカウント全体に関わる設定等をする際に使用します。 |
| SECURITYADMIN | セキュリティ管理用のロール。 ユーザーとロールの作成や、ロールの割り当て等が可能です。 |
| USERADMIN | ユーザーとロールの管理専用のロール。 SECURITYADMINと同じくユーザーとロールの作成が可能ですが、限定的です。 |
| SYSADMIN | ウェアハウスやデータベース、スキーマのようなオブジェクトを作成する権限を持つロール。 |
| PUBLIC | アカウント内のすべてのユーザー、ロールにデフォルトで付与されるロール |
セキュリティや誤操作防止の観点から、付与するロール、指定するロールはなるべく最小権限のものが望ましいです。
最初の時点では、アカウント全体の設定はACCOUNTADMIN、ユーザーの作成はUSERADMIN、ロールの作成・割り当てはUSERADMINかSECURITYADMIN、オブジェクト(データベース・スキーマ・ウェアハウス)の作成はSYSADMINと覚えておくと良いでしょう。
Snowsightでは、以下の箇所でロールの切替を行えます。
(GUIで操作する場合) アイコンから「ロールを切り替え」を選択
(クエリを実行する場合) ワークシートの画面右上からロールを選択
環境構築最初にやること集
最低限のパラメータ設定で作成する手順を紹介します。
ユーザー作成
利用者ごとにユーザーを作成しましょう。
GUIで作成
[管理者]>[ユーザーとロール]>[ユーザー]画面から、[+ ユーザー]を選択し、必要情報を入力して作成します。
クエリで作成 (サンプル)
--user_001という名前でユーザー作成 CREATE USER user_001 PASSWORD = '[パスワード]' EMAIL = "[メールアドレス]" MUST_CHANGE_PASSWORD = TRUE DISPLAY_NAME = "[表示名]" ;
[MUST_CHANGE_PASSWORD]をTRUEにすることで、初回ログイン時にパスワード変更を強制させることができます。
ユーザーを作成したら、アイコンの[自分のプロファイル]から多要素認証(MFA)を登録してもらいましょう。
特に管理者(ACCOUNTADMIN)ロールを持つユーザーについては設定が強く推奨されています。
ウェアハウス作成
ウェアハウスは、クエリの処理時に使用されるコンピューティングリソースです。
データベース・スキーマのようなストレージ領域がコンピューティングリソースと分離しているのがSnowflakeの大きな特徴の一つです。
GUIで作成
[管理者]>[ウェアハウス] 画面から、[+ ウェアハウス]を選択し、ウェアハウス名を入力して作成します。
Snowflakeではウェアハウスの稼働時間が長いほど多くの費用が発生するので、ウェアハウスの自動一時停止を有効にしておくことでコスト削減につながります。
クエリで作成 (サンプル)
--wh_001という名前でウェアハウス作成
CREATE WAREHOUSE wh_001
WAREHOUSE_SIZE = XSMALL
AUTO_SUSPEND = 60
;
作成時に[WAREHOUSE_SIZE]でウェアハウスのサイズを指定します。お試し用途であれば、一番小さいXSMALLサイズで問題ないでしょう。
[AUTO_SUSPEND]の値が自動一時停止されるまでの秒数を表しますが、デフォルトの600より短い60に変更することで、利用していない場合はより素早く一時停止されます。(※60未満の値は非推奨)
データベース・スキーマ作成
Snowflakeでは、データを格納するためにテーブルが必要ですが、そのテーブルの格納先としてデータベース、スキーマが必要です。
GUIで作成
[データ]>[データベース] 画面から、[+ データベース]を選択し、データベース名を入力して作成します。
スキーマは作成したデータベースの画面から、[+ スキーマ]を選択して作成します。
クエリで作成 (サンプル)
--db_001という名前でデータベース作成 CREATE DATABASE db_001; --schema_001という名前で、db_001にスキーマ作成 CREATE SCHEMA db_001.schema_001;
データベース、スキーマともに、通常利用であれば特別なパラメータの指定は必要なく簡単に作成ができます。
ロール作成・付与
序盤にシステムロールを紹介しましたが、独自のロールを作成してユーザーに権限付与することも可能です。
例として、特定のDB、特定のウェアハウスのみに対して一般的な操作限定で行えるロールを作成してみます。
クエリで作成 (サンプル)
--sample_role_001という名前でロールの作成 CREATE ROLE sample_role_001; --sample_role_001ロールにUSAGE権限付与 GRANT USAGE ON DATABASE db_001 TO ROLE sample_role_001; GRANT USAGE ON SCHEMA db_001.schema_001 TO ROLE sample_role_001; GRANT USAGE ON WAREHOUSE wh_001 TO ROLE sample_role_001; --sample_role_001ロールにテーブル、ビューのCREATE権限付与 GRANT CREATE TABLE, CREATE VIEW ON SCHEMA db_001.schema_001 TO ROLE sample_role_001; --sample_role_001ロールにテーブル、ビューの操作権限付与 GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA db_001.schema_001 TO ROLE sample_role_001; GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON FUTURE TABLES IN SCHEMA db_001.schema_001 TO ROLE sample_role_001; GRANT SELECT ON ALL VIEWS IN SCHEMA db_001.schema_001 TO ROLE sample_role_001; GRANT SELECT ON FUTURE VIEWS IN SCHEMA db_001.schema_001 TO ROLE sample_role_001; --user_001ユーザーにample_role_001ロールを付与 GRANT ROLE sample_role_001 TO USER user_001;
sample_role_001という名前のロールを作成し、ロールに対して権限を付与し、そのロールを特定のユーザーuser_001に付与してみました。
ロールに付与している権限の中で、「USAGE」は使用権になります。使用できるようにしたいデータベース、スキーマ、ウェアハウスに対して、このUSAGE権限をそれぞれ付与する必要があります。
続けて、ロールに対し、スキーマschema_001に限定してテーブル・ビューのcreate権限や操作権限を付与しています。
テーブルやビューを指定する際に、「ALL TABLES」や「ALL VIEWS」のような指定は、既存のテーブルやビューすべてを対象に権限を付与することを意味します。一方で「FUTURE TABLES」や「FUTURE VIEWS」のような指定は、これから作成されるテーブルやビューに対して権限を付与することを意味します。
「ALL TABLES」で指定しただけでは、新規で作成したテーブルに対して権限が付与されないことに注意が必要です。
最後に、GRANT ROLE でユーザーに対して作成したロールを付与することで、付与した特定のユーザーに対してカスタマイズした権限のみを付与することが可能です。
ネットワークポリシー設定
Snowflakeでは、ネットワークポリシーを設定し、Snowflakeに接続できるIPアドレスを制限することが推奨されています。例として、IPアドレス範囲を指定して、許可したIPアドレスのみ接続できるようにする設定を示します。
クエリで設定 (サンプル)
USE ROLE SYSADMIN; --Network Rules設定用のデータベース・スキーマを作成 CREATE DATABASE securitydb; CREATE SCHEMA securitydb.networkrules; USE ROLE ACCOUNTADMIN; --network_rule_sampleという名前でネットワークルールを作成 CREATE NETWORK RULE network_rule_sample MODE = INGRESS TYPE = IPV4 VALUE_LIST = ('47.88.25.32/27') ; --network_policy_sampleという名前でネットワークポリシーを作成し、network_rule_sampleを許可 CREATE NETWORK POLICY network_policy_sample ALLOWED_NETWORK_RULE_LIST = ('network_rule_sample') ; --作成したネットワークポリシーをアカウント全体に適用 ALTER ACCOUNT SET NETWORK_POLICY = network_policy_sample;
ネットワークルールはスキーマオブジェクトなので、作成時にデータベース、スキーマを指定する必要があります。
上記を実行することにより、Snowflakeアカウント全体が、47.88.25.32/27 のIPアドレス範囲からの接続しか許可されなくなります。
ネットワークルールを複数作成することで、許可する条件をOR条件で複数設定することや、ネットワークポリシーをアカウント全体でなくユーザーごとに別々に適用することも可能です。
タイムゾーンの変更
Snowflakeでは、デフォルトのタイムゾーンがAmerica/Los_Angelesに設定されています。
アカウント全体でデフォルトのタイムゾーンを日本標準時に変更する場合は、以下のようにアカウントパラメータの値を変更します。
--タイムゾーンを日本標準時に変更 ALTER ACCOUNT SET TIMEZONE = 'Asia/Tokyo';
リソースモニター
リソースモニターを利用することで、Snowflakeアカウント内でのクレジット(リソース使用量)の状況を監視することができます。
リソースモニターによる設定は、新規の場合は[管理者]>[コスト管理]>リソースモニター 画面から、[+ リソースモニター]を選択します。
リソースモニターによる監視は、[モニタータイプ]から、アカウント全体の監視か、ウェアハウス個別の監視かを指定できます。
[クレジットクォータ]で、指定した期間で許可するクレジットの上限を設定します。そして、指定したクレジットクォータに対して実際の使用が何%に達したかに応じて、[アクション]で、通知や即時一時停止といった内容を設定することが可能です。
作成したリソースモニターの通知を受け取りたい場合は、ACCOUNTADMIN権限を持つユーザーのアイコンの[自分のプロファイル]を選択し、「リソースモニターからのメール通知」にチェックが入っていることを確認しましょう。
最後に
Snowflakeでは公式のガイドやブログ記事が充実しており、構築に関するヒントやベストプラクティスの記載をたくさん見つけられるので要チェックです。
環境が用意できたら、どんどんデータを投入して活用してみましょう!
