Snowflakeのマルチテナント設計ポイント調べてみた
はじめに
Snowpro Advanced Architectの試験でワークロードの分離関連の問題が出題されたのでマルチテナント関連を調べてみたブログです。
あとワークロードの分離とかマルチテナントとかって結構どの会社でも考えないといけないポイントだと思うし、以前やってた案件だとこのあと出てくるアカウント単位テナントとオブジェクト単位テナントのハイブリッドを採用していて、うまく運用できてたか怪しいなって思ってたりします。
そもそもマルチテナントってどんなユースケースで発生するか雑に考えてみた。
- 顧客単位（SaaS顧客ごと / 系列会社ごと）
- 組織単位（部署 / 部門 / プロジェクトごと）
- 機能単位（サービスライン / 製品機能ごと）
- 規制単位（国 / 地域 / セキュリティレベルごと）
がよくあるパターンだと思う。
Snowflake公式曰く、マルチテナントを設計する一般的なパターンは３種類しかないそう。
-
マルチテナントテーブル（MTT）：
- MTTは共有テーブルまたはウェアハウス内でテナントを統合します。
- テナントを単一の共有オブジェクトに集中させることで、テナント間でウェアハウス（コンピュート）やその他のリソースを効率的に共有することができます。
-
オブジェクト単位テナント（OPT）：
- OPTはテナントを個別のテーブル、スキーマ、データベース、およびウェアハウスに分離します。
- このアプローチではテナントに個別のオブジェクトを割り当てますが、アプリケーションは単一のSnowflakeアカウント内で動作します。
-
アカウント単位テナント（APT）：
- APTはテナントを個別のSnowflakeアカウントに分離します。
- OPTとは異なり、アプリケーション内の各テナントは専用のSnowflakeアカウントを持ちます。
ユースケースはいくつかあるものの、それら3つのパターンのどれかもしくはハイブリッドで実装するのが良いそうです。
この後、それぞれのパターンの設計ポイントについて掘り下げてみます。
3つのパターンのまとめ（簡易版）
それぞれの設計ポイントをまとめると文章量が多いので、とりあえず設計のポイントだけ押さえておきたい！！って人は次の2つの表を見ていただければと思います！
3つのデザインパターンの類似点と相違点のまとめ
| 区分 | MTT | OPT | APT |
|---|---|---|---|
| データモデルの特徴 | ・すべてのテナントで同じテーブル構造となる ・ 各行に tenant_id が付与されるため、どのテナントのデータか判別しやすい |
・テナントごとにデータ形状をユニークにでき、複数テナントで似せることも可能 | ・テナントごとにデータ形状をユニークにでき、複数テナントで似せることも可能 |
| スケーラビリティ | ・数十から数百万テナントまでスケール（上限は未判明） | ・典型的な導入で数十〜数百テナントまでスケール | ・典型的な導入で数十〜100数テナントまでスケール |
| セキュリティ上の懸念 | ・権限テーブル、セキュアビュー、行レベルセキュリティなどを開発者が管理する必要がある ・アプリ所有者に RBAC と行レベルセキュリティの熟達が求められる |
・RBAC に慣れた顧客が、権限テーブルを運用せずとも強固なプロセスでテナント分離を実現しやすい | ・テナントをアカウントで分離し、ミスによるセキュリティリスクを低減 ・アカウント単位の分離により、暗号鍵や IP 許可リスト、RBAC を超えるコントロールなど厳格なセキュリティ対策を適用可能 ・BYOT、Snowflake UI ログイン、テナント専用の接続文字列など厳格なネットワーク対策を適用可能 |
デザインパターンを評価する際に考慮すべき注意点
| MTT | OPT | APT | |
|---|---|---|---|
| ポジティブ | ・共有かつスケーラブルなウェアハウス（コンピュート）をプールすることでコストを抑え、運用も簡素化できる | ・目的に応じてテナント単位にウェアハウス（コンピュート）をプールまたは分離できるプールは節約になる一方、テナント間のリソース競合の可能性が高まる | ・レガシーなデータベース基盤からリプラットフォームする顧客にとって馴染みやすい設計 |
| ネガティブ | ・複数リージョン間のデータ共有は課題になり得る（ただし、マルチリージョン共有を容易にするために OPT を組み合わせる方法がある） ・クラスタリングキー設計やロード順序の工夫、テーブルの論理分割（必要時） ・非常に大きなテーブルでは MERGE、UPDATE、オートクラスタリングの運用が難しい場合がある ・マルチテナントテーブルではテナント単位のストレージコストを見積もるのが難しい |
・Snowflake 内でオブジェクトを作るのは容易だが、多数の類似オブジェクトで一貫した状態を保つのは難しく、数が増えると同期が困難になる ・テナントごとのウェアハウス（コンピュート）は、ウェアハウス（コンピュート）のプールができないためコスト増になり得る ・オブジェクトを保守しバージョン管理するために自動化の高度化が必要 |
・Snowflake でアカウントを作ること自体は容易だが、アカウント間で一貫した状態を保つのは難しい ・テナントごとのウェアハウス（コンピュート）は、ウェアハウス（コンピュート）のプールができないためコスト増になり得る ・アカウントやオブジェクトを作成・管理するために自動化の高度化が必要 |
それぞれのデザインパターン（詳細版）
マルチテナントテーブル（MTT）
マルチテナントテーブルは1つのデータベース内で複数のテナントテーブルを持ちセキュアビューによりアクセス制御を行うパターンです。要点は次のとおりです。
- アプリケーションユーザは提供データベース内のセキュアビューを介してテナントデータにアクセスします（図中の赤枠）
- 権限テーブルは、どのSnowflakeユーザまたはロールがどのテナントにアクセスできるかを制御します
- セキュアビューにより、アプリケーションユーザは自分のテナント行のみを閲覧できます
- すべてのテーブルはtenant_id列でクラスタリングされています
マルチテナントテーブルの設計と実装上のポイント
セキュアビューを利用したアクセス制御
ユーザが自分のテナント行だけを閲覧できるように強制するため、セキュアビューを通じてクエリを実行します。このビューは基本テーブルと権限テーブルをtenant_idで結合します。すべての行が全員に表示される共通テーブルは、基本テーブルを指す通常のビューを使用します。
Tips
Snowflakeは、権限と機能アクセスに基づくロールの階層を作成し、テナントごとにロールとユーザを定義することを推奨しています。専用のテナントロールの権限は、ロールベースの階層のベストプラクティスに従って設定してください。
スキーマ設計
セキュアビューを定義する専用のスキーマを用意します（図中の赤枠）。そして各テナントごとのスキーマに実データとアクセス制御用のテーブルを用意します。
この設計には次の利点があります。
- セキュアビューと共通テーブルは、開発者ユーザとアプリケーションユーザの分離に役立ちます
- 個々の顧客がより高度な作業を行うためのサンドボックス領域を作成したい場合、顧客ごとにスキーマを使用して分離することもできます
また、初期化手順で USE DATABASE/SCHEMA を徹底、デフォルトROLE/WAREHOUSEの設定を併用することで、アクセスをさらに誘導することができます。
権限テーブルの維持管理
アプリケーションデータのセキュリティは権限テーブルの正常な動作に依存するため、権限テーブルの管理はデータアプリケーション構築者にとって最優先事項です。
セキュリティに関する事項：
- 権限テーブルは制限的な権限でロックする
- 権限テーブルは体系的なプロセスで管理する
- 権限テーブルに対して単一のINSERT/UPDATE文を実行して新規顧客を追加するといった不適切な手法は避ける
- 処理を自動化され制御が施されたプロシージャでラップすることで人的ミスを排除する
- プロシージャはSnowflake内外で実行可能とする
- 問題発見のため、権限テーブル更新後は定期的な回帰テストを実行し、セキュアビューの結果を期待される結果と照合すること
最適化に関する事項：
- テナントには一意の数値識別子（tenant_id）を設定してください
- トランザクションテーブルは、最低限tenant_idと意味のある日付フィールドでクラスタリングしてください（日付→tenant_idの順序でも問題ありません）
- テナントを表すロード次元テーブルは初期段階でソートし、テナントには連番識別子を使用すること
- 規模は小さいものの、テナントごとにユーザやロールが多数存在する場合は権限テーブルをクラスタリングすること。そうでない場合はロード順にソートすること
各テナントは通常、自身のデータスライスにしかアクセスできないためテーブルのクラスタリングを設定します。テーブルロード時に単純なソート順序付けを行うことで、データへのアクセスを容易にしパーティションプルーニングを支援できる場合もあります。ただし自動クラスタリングはバックグラウンドサービスとして実行され、即時的ではない点に留意が必要です。
アプリケーション内でのデータ更新・ロード頻度によっては、自動クラスタリングだけでは不十分であり、データパイプラインの構造変更など追加の回避策が必要となる可能性があることに注意してください。
ワークロードの分離またはコスト削減
データベース分離が一般的なベストプラクティスであるのと同様に、ワークロードの種類に基づくワークロードの分離も有効です。具体的な推奨事項は以下の通りです：
- ワークロード別の専用のウェアハウス（コンピュート）を提供
- アプリケーションユーザを共通のマルチクラスターウェアハウス（コンピュート）を提供、もしくはアプリケーション要件に基づいて専用ウェアハウス（コンピュート）に分離
- アプリケーションの用途ごとに異なるウェアハウス（コンピュート）を使用する
- その他のワークロードを専用ウェアハウス（コンピュート）に分離する
基本的にワークロード別にウェアハウス（コンピュート）を分離提供します。またアプリケーションユーザ（ダッシュボードクエリ）は予測可能であるため、アドホッククエリよりも容易にプール化ができます。アドホック利用は予期せぬ計画外の費用を招く可能性があるためコスト観点から注意が必要です。
最後にMTTに限った話ではないですが、ワークロードの分離やユーザを適切なウェアハウス（コンピュート）にルーティングされるようにしましょう。
オブジェクト単位テナント（OPT）：
オブジェクト単位テナントでは、データベース、スキーマ、テーブル単位でテナントデータを分離し、RBACを用いてオブジェクトの閲覧やクエリを実行できるユーザやロールを制御できます。顧客を個別のデータベースに分離するのが最も一般的な手法です。これは最も容易で明確な分離レベルだからです。
自動化による新規テナントの作成
オブジェクト単位テナントまたはマルチテナントテーブルパターンを実装する場合、自動化を利用して新規テナントを作成します。自動化はSnowflake内部または外部で記述可能であり、テンプレートに基づいて新規テナントを生成します。テンプレートにはデータベース、スキーマ、テーブル、ウェアハウス（コンピュート）（コンピュート）、セキュリティ設定、その他新規テナントに必要な要素を網羅する必要があります。自動化が不可欠なのは、オブジェクト数が数百から数千規模になると、テナントの作成や継続的な拡張を他の方法で管理するのが困難になるためです。
認証と認可
OPTの認証と認可はMTT認証と類似していますが、OPT認証ではユーザを適切なデータベースにルーティングすることがさらに重要になります。
MTT認証と比較してコンテキストが変化するため、ユーザは異なるオブジェクトにルーティングされます。適切に設定されている場合、シークレットマネージャーおよびアプリケーション層内でのユーザ検索により、ユーザは自動的に適切なデータベースと適切なウェアハウス（コンピュート）にルーティングされます。
OPTモデルにおける取り込み/変換データベースの分離
サービス用データベースと作業用（取り込み/変換）データベースの分離方法を計画する際には、共通処理のためにテナントデータベースからデータがどのように拡散し、また集約されるかを考慮してください。多くの場合、テナントごとに別々のワークロードを実行するコストは、ワークロードを単一インスタンスに統合するコストよりも高くなります。
例えば、テナントごとに複数のテーブルを用意し、それぞれに独自のパイプラインを設ける場合、アプリケーションユーザがアクセスできない共通データストアで単一の変換プロセスを管理する場合よりもコストが高くなる可能性があります。必要に応じて、変換後にデータを複数のテナント固有オブジェクトに分散するか、単一の共有サービス用データベースに保存できます。
効率性とコストを最適化するには、前述のハイブリッドOPT/MTTモデルなどのハイブリッドモデルを検討してください。
マルチリージョンデータ共有を容易にするOPTの組み込み
マルチリージョンデータ共有はMTTモデルにとって課題となり得ます。プライマリ以外のクラウド/リージョンペア間でデータを共有する必要があり、かつ全テナントデータを全クラウド/リージョンペアに複製したくない場合は、MTT設計にOPTを組み込むことを検討してください。
Snowflakeはデータベース全体レベルのレプリケーションをサポートしているため、マルチテナントデータベースから特定のスライスだけを別の場所に送信することはできません。マルチテナントテーブル全体を必要なすべてのクラウドとリージョンにレプリケートすることは可能ですが、データサイズとテナント数が増加するにつれ、この設計は管理不能になります。
例えば下図は、マルチテナントかつマルチCSPのアプリケーション設計を示しています。顧客DはGCP上でデータを共有していますが、Azure上で顧客Dのデータにアクセスするユーザがいない場合、Azureに複製することは合理的ではありません。
注：データ共有のユースケースがある場合は、Snowflake Data Marketplaceを利用して最新機能を活用することを検討してください。
アカウント単位テナント（APT）
APTモデルでは、通常、テナントごとに1つのSnowflakeアカウント、1つのウェアハウス（コンピュート）、1つのデータベースが存在します。
例外として、例えば以下のケースが考えられます：
- 複数のテナントが1つのアカウントを共有し、APTモデルとMTTモデルのハイブリッド形態を形成する場合
- データ共有を通じてアカウントにデータが送信されるか、あるいは何らかの ETL または ELT を使用してテナントアカウント内で追加処理が行われるかによって、データロードや管理活動用の追加管理用ウェアハウス（コンピュート）が存在する場合があります。例えば、一部のアプリケーションはデータをロードするだけで、他の場所で処理が完了しているため、テナントアカウント内で追加処理を行う必要がありません。
- 多くのAPT設計は単一クラスター・ウェアハウス（コンピュート）で対応可能です。高負荷アプリケーションでは複数クラスターが必要となり、マルチクラスター・ウェアハウス（コンピュート）を含む構成が想定されます。
認証
APTモデルでは、アプリケーション層を介した認証は、MTTモデルやOPTモデルとほぼ同様に機能します。
主な違いは、アカウントURLがテナントごとに異なる点です。また、ユーザはUIまたはBYOT（Bring Your Own Tool）ソリューションを通じて、Snowflakeアカウントに直接ログインすることも可能です。
データの取り込みと変換
前述の通り、アプリケーションは通常、外部ソースからの取り込みや変換に使用される作業データベースを管理するための中央アカウントを利用します。
Snowflake Secure Data Sharing を使用してテナントデータをテナントアカウント間で共有できます。これは MTT または OPT アプローチでも実現可能です。
ELT または Snowflake Database Replication を使用して、テナントアカウント内にデータを生成することもできます。
まとめ
本記事がワークロードの分離やマルチテナントを考える際にお役に立てば幸いです。
この資料を作成することでマルチテナントを設計するポイントを抑えることができたので、Snowpro Advancedの試験対策にもなりました！
ただ、これだけ深い内容の問題は出てこないと思うので安心してほしい（多分）
自信の組織でワークロード分離やマルチテナントをすでに導入されている方はSnowflakeのベスプラに準拠しているか見直してはいかがでしょうか。もしかするとコスト改善の余地があるかもしれません！
もしくはこれから導入しようと検討中の方は参考にしていただければと思います！
Discussion