Snowflake における権限管理とコスト管理
こんにちは、Finatextグループのナウキャストでデータエンジニアをしているけびん（X: @Kevinrobot34 ) です。
先日「みんなの考えた最強のデータ基盤アーキテクチャ2024前半おまとめ拡大版SP！」というイベントに登壇し、 Snowflake でデータ基盤を作る際に大事になる権限管理とコスト管理の方法について、ナウキャストの事例を紹介させていただきました。
要は「ロールの階層・ロールの分け方」「ウェアハウスの分け方」をどうするかという話で、ナウキャストの場合は以下のような構成にしています。
これらについてポイントを改めて紹介します。
このロール・ウェアハウス構成を見る前に、Snowflakeにおける権限管理とコスト管理のポイントを整理しておきましょう。
Snowflake の権限管理
Snowflake における権限管理は DAC と RBAC を組み合わせたようなものとなっています。
- オブジェクトの権限はロールに付与される
- オブジェクトはロールに所有される
- ロールはユーザーに付与される
また Snowflake ではロールの階層構造を作ることが可能です。これにより、親のロールは子孫のロールの権限も継承することになります。
またロールにも主要なもので Account Role と Database Role の２種類あり、どれを使うか？もポイントになります。Database Role については以下の記事が分かりやすいです。
よって Snowflake の権限管理における具体的なポイントとしては
- ロールをどう切り分けるか
- ロールの階層をどう作るか
- ロールとして Account Role と Database Role のどちらを作るか
などがあります。
Snowflake のコスト管理
Snowflake ではウェアハウスが計算資源であり、これを何秒使ったかで課金されます。ウェアハウスは簡単にいくつでも作ることができまたウェアハウス別でコストを確認するのは容易です。
よって Snowflake のコスト管理ではウェアハウスをどう切り分けるかがポイントになります。
ちなみにコスト管理の観点以外にも、ワークロードごとにウェアハウスを切り分けておくことは大事です。例えばウェアハウスを共有してしまうと、あるワークロードの重い処理が別のワークロードに影響を与えてしまうといったこともあり得ます。
ロール・ウェアハウスの全体像
改めてナウキャストのロール・ウェアハウスの全体像を見てみましょう。
ポイントとしては以下のあたりになります。
- ロールについては Service / Functional / Access Role 層の３つのグループを作り管理
- Service / Functional Role 層は Account Role で、 Access Role 層は Database Role で実装する
- Access Role 層で必要に応じて階層を一つ作る
- ウェアハウスについては Service / Functional Role 層でロールとセットで作成する
Service / Functional / Access Role 層などは以下のブログなど、最近よく見かけますが、ウェアハウスの組み合わせ方などでナウキャスト独自の工夫をしています。
層ごと詳しく見ていきましょう。
Access Role 層について
Access Role 層は各オブジェクトの細かい権限を隠蔽し程よくまとめておくことで、ロールの付与の有無で権限を管理できるようにするための層です。
例えば、「ある Schema の任意の table の read 権限」を用意するためには
- Database の USAGE
- Schema の USAGE
- All Tables の SELECT
- Future Tables の SELECT
の４つの権限が必要です。これらを一つのロールに table-select にまとめておくことで、このロールを Functional / Service Role に付与するかどうかで簡単に table の read 権限を付与することができ、管理が楽になります。
Access Role 層のロールはあくまで権限をまとめて利用しやすくしたもののため、 Database Role で実装するのが便利です。これにより
- ウェアハウスの権限は付与できないため、ウェアハウスの乱立を防げる
- Access Role 層のロールを直接ユーザーに付与することを防ぐ
- Snowsight のロール選択画面に Access Role 層のロールは表示させない
といったことが可能になります。
Functional Role 層について
Functional Role 層は人間の利用するユーザーのためのロールを管理する層です。 Type property が PERSON のユーザーに付与するためのロールを管理しているとも言えます。
この層ではロールだけでなく、ウェアハウスもセットで管理するようにしています。これにより権限管理とコスト管理を同時に考えやりやすくしています。
Functional Role 層のロールはユーザーに付与しウェアハウスの利用権限も付与する必要があるため Account Role で実装します。
また、Functional Role 層同士で階層は作らず、 Access Role 層の Database Role を適切に付与することで権限管理するようにしています。必要以上に階層が増えると認知負荷が増え権限管理が難しくなるためです。
Service Role 層について
Service Role 層はシステムの利用するユーザーのためのロールを管理する層で、 Type property が SERVICEのユーザーに付与するためのロールを管理しているとも言えます。
ロール付与対象のユーザーがシステムであること以外は全て Functional Role 層と同じです。
システムの利用するユーザーと人間の利用するユーザーが使うロール・ウェアハウスを別々のものにしておくというのがポイントになります。
- システムと人間とで似たような権限を使うことが多いかと思いますが、ロールを共有してしまうと過度に強い権限のロールが使われていく傾向が出てしまい、最小権限の法則に反しよくないです。
- またコスト管理の観点からは、システムと人間が使うウェアハウスは分離しておかないと定期バッチとAdhocな開発・分析のコストの分離が面倒になります。
これらのポイントから Functional Role 層と Service Role 層を分けておくことにしています。
おわりに
ナウキャストでは一緒に働く仲間を募集中です！興味のある方はTwitter で @Kevinrobot34 にご連絡ください！ 会社紹介ページも是非ご覧ください！
また最近 Finatext グループ公式のエンジニア向けXアカウント @FinatextDev も作成しさまざまな発信をしているのでぜひフォローしてください！
