見出し画像

新データ基盤におけるSnowflakeのロール設計に、データベースロールをトライしてみた話

Akira Tsunesumi

こんにちは！GA technologies / RENOSYのデータエンジニアの
常住(つねすみ)です。

前回、DataEngineeringStudy #24への登壇の記事をアップしました。

今回は、上記のnoteでも述べた「テック企業としてのデータ基盤」の
構築内容の１つ、Snowflakeのロール設計の取り組みを共有します。


１：新データ基盤の構成

新データ基盤は以下の構成となります。
データマートは、dbt Cloudを用いてSnowflakeに作成します。

２：ロール設計の要件

dbt Cloudから参照するDWHがSnowflakeになるにあたり、以下の要件がロール設計に求められました。

  • SnowflakeのベストプラクティスであるFunctional Roleと
    Access Roleの組み合わせを採用したい

  • dbt Cloudからの参照権限もロールベースのアクセス制御(RBAC)に
    組み込む必要がある

  • なるべくSnowflake上でユーザーにCREATEさせたくない
    （理由：野良データマートが増えることを避けたい）

  • カラム単位で見せる見せないをコントロールしたいケースもある

３：Snowflakeでデータベースロールを使用

早速ではありますが、結果的にどういうRBACを実装したのか、
簡単にシェアさせていただきます。

今回、RBACのAccess Role部分にはデータベースロールを採用しました。
大まかではありますが、データベースロールの従来のアカウントロールとの違いは以下となります。

データベースロールはユーザーが選択できるロール一覧の中には出てこないため、Access Roleが増えても、画面にロール一覧がズラッと並ばず、視認性を確保しやすくなります。

最終的なRBACの形としてはこうなりました。（設定は一部のみ抜粋。実際はSTG層やMART層からも設定があります。）

４：実行したSQLコマンド

以下は今回実行したロール作成のコマンドの概要です。

[前提]
ーDatabase/Schema/TableはSYSADMINでCREATEされている
ーDatabaseは以下の３層構造
	RAW		ローデータ
	STG		１次集計
	MART	データマート
ーSnowflakeのFunctional RoleのOwnerはSECURITYADMIN

[手順]
SYSADMINにチェンジ
	USE ROLE SYSADMIN;

Databaseを指定し、2種類のデータベースロールを作る
	a：Databaseに紐づくデータベースロール
		CRAETE DATABASE ROLE _DATABASE_RAW_RW_AR;　― Read/Write可能
		CRAETE DATABASE ROLE _DATABASE_RAW_RO_AR;　― Readのみ可能
		※これをSTG、MARTもつくる
	b：Database：RAW配下のSchema単位でのデータベースロール
		CRAETE DATABASE ROLE _SCHMEA_RAW_A(Schema名)_RW_AR;　― Read/Write可能
		CRAETE DATABASE ROLE _SCHMEA_RAW_A(Schema名)_RO_AR;　― Readのみ可能
		※これを必要なSchmea分作成する

2-aのデータベースロールに、紐づくDatabaseの必要な権限をGRANTする
	― Read/Write
		grant usage on DATABASE RAW to database role _DATABASE_RAW_RW_AR 
		grant create schema on database xxx to database role _DATABASE_RAW_RW_AR;
	― Readのみ
		grant usage on DATABASE RAW to database role _DATABASE_RAW_RO_AR 
	 ※同じことをSTG、MART分実施する

2-bのデータベースロールに、紐づくSchemaのRead/WriteをGRANTする
	― Read/Write
		grant usage on schema A(Schema名) to database role _SCHMEA_RAW_A_RW_A;
		grant create table on schema A(Schema名) to database role _SCHMEA_RAW_A_RW_A;
		grant create view on schema A(Schema名) to database role _SCHMEA_RAW_A_RW_A;
	― Readのみ
		grant usage on schema A(Schema名) to database role _SCHMEA_RAW_A_RO_A;
	※これを必要なSchmea分実施する

SECURITYADMINにチェンジ
	USE ROLE SECURITYADMIN;

2-bのDbRに紐づくSchema配下のfuture tableをSelectできるようにする
	grant select on future tables in schema raw.A to database role _SCHMEA_RAW_A_RW_A;
	※これを必要なSchmea分実施する

Functional Roleとなるカスタムロールに、作成したデータベースロールをGRANTする
	例：DB単位：grant database role _DATABASE_RAW_RW_AR to role DBT_STANDARD;
	例：SCHEMA単位：grant database role raw._SCHMEA_RAW_A_RW_A to role DBT_STANDARD;
	※これを必要なカスタムロール・Database・Schema分実施する

Functional Roleに適切なデータベースロールがGRANTされているか確認
	SHOW grants to role DBT_STANDARD;

５：クラスメソッドさんのPoC支援

環境構築に先んじて、SnowflakeはFundamentals研修を受けることができ、基本的な概念を学びました。
一方で、dbt CloudはWEB上のドキュメントを見ていても、新たに覚える概念が多く、キャッチアップが難しそうだなと感じていました。また、これまでGit管理などもそこまで行えていなかったため、学ぶ内容がdbt Cloudだけではないことも、独力でやり切るには不安に思う要素でした。

そこで今回、クラスメソッドさんにdbt CloudのPoC支援をお願いしました。
クラスメソッド様が運営されているDevelopersIOで、dbt Cloud導入支援のキャンペーンのバナーを見たのがきっかけで、問い合わせをさせていただきました。DevelopersIOのdbt CloudやSnowflakeなどのモダンデータスタック関連の記事は、このプロジェクトを始める前からもずっと拝読しており、とても参考にしています。

講師はさがらさんにご担当していただき、私含め、dbt CloudのDeveloperになる予定のデータチームのメンバーにハンズオンとトレーニングを行っていただきました。その後約１ヶ月ほど、私とさがらさんで1on1を繰り返しながら、今回の要件に応じたSnowflakeとdbt Cloudの環境の実装を進めました。

データベースロールもこのPoC支援の中でご案内いただき、Access Roleに採用することができました。

正直、この支援をお願いしてなかったら、dbt Cloudの良さをまったく引き出せないデータ基盤になってしまっていたなと思います。非常にたすかりました。。。

６：今後

ロールの設計も終わり、現在は既存の設定の移管と、Snowflakeのユーザーへの開放の準備を進めている最中となります。また進捗や学びなどがあれば、こちらのnoteで共有させていただきます。

GA technologiesではデータエンジニアを引き続き積極採用中ですので、
ご興味を持った方はぜひ以下よりご応募お待ちしております！
カジュアル面談からでも！

この記事が気に入ったらサポートをしてみませんか？