B2B SaaS
各顧客のキャッシュとセッションのデータは、共有クラスター上の独自のプレフィックスの下にあり、ACLで分離されます。
コアデータプラットフォームScaleプラン（テナントレジストリ）
マルチテナントSaaSバックエンド
多数の顧客を1つのクラスターで扱い、ACLで各顧客を自分のキーに閉じ込め、誰がどこに属するかをテナントレジストリに記録します。
- サーバーあたりのテナント
- 256
- 分離のためのキーパターン
- ACL
- ユーザーとクォータの記録
- テナントごと
ステップ 1 / 5
テナントを登録
ID、表示名、クォータ値をテナントとともに記録します。
サンプルセッションplaying
# テナントを登録
hotkv> TENANT.CREATE acme "Acme Corp" MAX_MEMORY 1073741824 MAX_KEYS 1000000
OK
実際のHotKVコマンドと応答例を使ったアニメーションのウォークスルーです。任意のステップをクリックすると、そこに移動します。 コマンドと応答は、HotKVで実際に入力し表示されるとおり英語のままです。
課題
顧客ごとにキャッシュやデータストアを1つずつ動かすのは高価で、運用も大変です。かといって共有すれば、顧客間の強固な分離と、どのユーザーがどの顧客に属するかの記録が必要になります。
HotKVでの解決方法
キーパターンを持つACLユーザーが、各テナントのアプリケーションを自分のキープレフィックスに閉じ込めます。テナントレジストリは、どのユーザーがどのテナントに属するかをクォータ値とともに記録します。レジストリはクラスターのすべてのノードで同じです。
ステップごとに
コマンドごとに何が起きるか
- 01
テナントを登録
ID、表示名、クォータ値をテナントとともに記録します。
TENANT.CREATE acme "Acme Corp" MAX_MEMORY 1073741824 MAX_KEYS 1000000 - 02
ユーザーを閉じ込める
ACLユーザーはacme:の下のキーにしか触れられず、危険なコマンドも実行できません。
ACL SETUSER acme-app on >s3cret ~acme:* +@all -@dangerous - 03
ユーザーをテナントに紐付け
レジストリが、どのユーザーがどのテナントに属するかを記録します。
TENANT.BIND acme acme-app - 04
分離の実際
acmeのアプリは自分のキーを読み取ります。globexのキーを読もうとすると、ACLによって拒否されます。
GET globex:billing:plan - 05
テナントの記録を読み取る
テナントに記録されたクォータ値です。このリリースでは使用量カウンターはクライアントのトラフィックで更新されないため、0と表示されます。
TENANT.STATS acme
活用シーン
実際のシナリオ
代理店とリセラー
クライアントのプロジェクトはそれぞれ独自のユーザーを持つテナントなので、アクセス権をクライアントごとに付与・取り消しできます。
標準搭載
得られるもの
キーパターンによる分離
キープレフィックスとコマンドセットに制限されたACLユーザー。
ACL SETUSERテナントレジストリ
名前、状態、クォータ値、紐付いたユーザーを持つテナント。すべてのノードで同じです。
TENANT.CREATETENANT.BINDテナントの記録
各テナントの名前、状態、クォータ値、紐付いたユーザー。
TENANT.INFOTENANT.STATSテナントを締め出す
テナントのACLユーザーを無効にします。
ACL SETUSER offよくある質問
クォータ値は強制されますか？
いいえ。記録されてTENANT.STATSに表示されますが、HotKVはコマンドに対してそれを強制せず、このリリースでは使用量カウンターもクライアントのトラフィックで更新されません。分離はACLのルールによって実現されます。
テナントを一時停止するとブロックされますか？
TENANT.SUSPENDは、お客様のツールのために状態を記録します。テナントのユーザーを締め出すには、ACL SETUSERで無効にしてください。
どのプランに含まれますか？
ACLはすべてのプランで動作します。テナントレジストリは、Scaleプランに含まれます。
関連するユースケース
ご自身のワークロードで試してみましょう
HotKVはRedisプロトコルに対応しているため、既存のクライアントを向けるだけで、これらと同じコマンドを実行できます。