マルチテナント機能と Azure Cache for Redis
Azure Cache for Redis は、ソリューションのパフォーマンスを向上させ、データベースやその他のデータ層コンポーネントの負荷を軽減し、計算ノードに格納する状態の量を削減するために一般的に使用されます。 この記事では、マルチテナント ソリューションに役立つ Azure Cache for Redis のフィーチャーの一部について説明し、Azure Cache for Redis を使用する方法を計画するときに役立つガイダンスへのリンクを提供します。
分離モデル
Azure Cache for Redis を使用するマルチテナント システムを運用する場合は、使用する分離レベルを決定する必要があります。 Azure Cache for Redis では、いくつかの分離モデルがサポートされます。
次の表に、Azure Cache for Redis の主なテナント分離モデル間の相違点を要約します。
| 考慮事項 | 共有キャッシュ、共有データベース | 共有キャッシュと共有データベース、アクセス制御リスト | 共有キャッシュ、テナントあたりのデータベース | テナントあたりのキャッシュ |
|---|---|---|---|---|
| データの分離 | 低。 Redis データ構造またはキー プレフィックスを使用して、各テナントのデータを識別する | 高 。 データはキー プレフィックスに基づいて分離される | 低。 データは分離されるが、セキュリティ分離は提供されない | 高 |
| パフォーマンスの分離 | 低。 すべてのテナントが同一のコンピューティング リソースを共有する | 低。 すべてのテナントが同一のコンピューティング リソースを共有する | 低。 すべてのテナントが同一のコンピューティング リソースを共有する | 高 |
| デプロイの複雑性 | 低 | 低から中 | Medium | 中/高 |
| 操作の複雑さ | 低 | 低から中 | 低 | 中/高 |
| リソース コスト | 低 | 低 | 低 | 高 |
| シナリオ例 | 共有アプリケーション層を備えた大規模なマルチテナント ソリューション | キャッシュにアクセスする個別のアプリケーション ID を持つ大規模なマルチテナント ソリューション | シングルテナント アプリケーションのマルチテナント対応への移行 | テナントごとの個々のアプリ インスタンス |
共有キャッシュ インスタンスと共有データベース
単一の Redis データベースを使用して単一のキャッシュをデプロイし、これを使用してすべてのテナントに関するキャッシュ データを保存するように考慮することもできます。 このアプローチは、すべてのテナントで 1 つのアプリケーション インスタンスが共有されている場合に一般的に使用されます。
このアプローチに従う場合、テナント データを分離する役割はアプリケーションが単独で担います。 キー プレフィックスを使用すると異なるテナントのデータを区別できますが、アプリケーションでは、処理中のテナントのデータにのみ集中して取り組む必要があります。 または、テナントのデータごとに sets や hashes などの Redis データ構造を使用するように考慮することもできます。 これらのアプローチはそれぞれ多数のキーをサポートしているため、多くのテナントにスケーリングできます。 ただし、承認の管理はキャッシュ内ではなく、アプリケーション内で行う必要があります。
テナント間でキャッシュ インスタンスとデータベースを共有する場合は、すべてのテナントがキャッシュの基になる同じコンピューティング リソースを共有することに注意してください。 したがって、この方法では、 うるさい隣人の問題に対して脆弱になる可能性があります。 キャッシュのリソースを最も効率的に使用し、ノイジー ネイバー (うるさい隣人) の影響を軽減するには、Azure Cache for Redis のベスト プラクティスに従うようにしてください。 ベスト プラクティスには次のようなものがあります。
さらに、CPU やメモリなどのキャッシュのリソースをモニターすることを考慮してください。 リソースの負荷が高い場合は、次の軽減策を考慮してください。
- 使用するリソースのレベルを高くして、キャッシュ SKU または層にスケールアップします。
- キャッシュ データをシャード化して、複数のキャッシュにスケールアウトします。 1 つの方法として、テナント別にシャード化することもできます。この場合、あるテナントではキャッシュ A を使用し、別のテナントではキャッシュ B を使用します。あるいは、サブシステム別にシャード化することもできます。この場合、ソリューションのある部分ではすべてのテナントのデータをキャッシュ A にキャッシュし、ソリューションの別の部分ではキャッシュ B にキャッシュします。
アクセス制御リストを使用した共有キャッシュと共有データベース
アプリケーション層で個別の ID を使用して各テナントのキャッシュにアクセスする場合は、Redis の アクセス制御リストを使用します。 アクセス制御リストを使用すると、テナントの情報へのアクセスを特定の ID に制限できます。 キー名またはキー プレフィックスに基づいて、ID がアクセスできるデータを特定します。 このアプローチは、テナントごとに異なるアプリケーション インスタンスがある場合、またはテナント コンテキストに基づいてダウンストリーム サービスにアクセスするために複数の ID を使用する共有アプリケーションがある場合に適しています。
前の分離モデルと同様に、キャッシュとデータベースを共有するということは、ノイジー ネイバー (うるさい隣人) の問題を回避するために予防措置を講じる必要があることを意味します。
テナントごとに 1 つのデータベースがある共有キャッシュ インスタンス
別の方法として、単一のキャッシュ インスタンスをデプロイし、そのインスタンス内にテナント固有の Redis データベースをデプロイするように考慮することもできます。 この方法では、各テナントのデータをある程度論理的に分離できますが、うるさい隣人に対するパフォーマンスの分離や保護はできません。
移行シナリオの場合は、この方法が役立つことがあります。 たとえば、複数のテナントを運用するように設計されていない単一テナント アプリケーションを最新化し、すべての要求内にテナントのコンテキストを含めて徐々にマルチテナント機能対応に変換するとします。 1 つの共有キャッシュを使用するとコスト効率を上げることができ、さらにはテナントのキー プレフィックスまたはテナント固有のデータ構造を使用するためにアプリケーションのロジックを更新する必要がありません。
Azure Cache for Redis には、 単一のキャッシュに対して作成できるデータベースの数に関する制限があります。 このアプローチを実装する前に、増加が見込まれるテナントの数を考慮してください。
さらに、この方法では、データのセキュリティ分離に関するベネフィットはありません。 Azure Cache for Redis では、認証と認可はキャッシュ インスタンス レベルで実行されます。
Note
Azure Cache for Redis では、特定の層に対しては複数のデータベースがサポートされていますが、クラスター化されたインスタンスを使用する場合には複数のデータベースはサポートされません。
テナントごとのキャッシュ インスタンス
テナントごとに Azure Cache for Redis の個別のインスタンスをデプロイするように考慮することもできます。 単一の Azure サブスクリプション内でデプロイできるキャッシュの数には制限はありません。 この方法では、最も強力なレベルのデータとパフォーマンスの分離が提供されます。
しかし、各キャッシュは個別の Azure リソースとして課金されるので、多数のテナントに拡大すると、発生するコストが高くなる可能性があります。 さらに、一般的に各 Azure Cache for Redis インスタンスでは大量の要求がサポートされるので、この方法では各キャッシュのリソースを効率的に使用できないことがよくあります。 厳密なデータまたはパフォーマンスの分離の要件がある場合のみ、この分離方法を検討することをお勧めします。
マルチテナント機能をサポートする Azure Cache for Redis のフィーチャー
アクセス制御リスト
Azure Cache for Redis には、強力な ロールベースのアクセス制御システムが用意されています。これにより、包括的なデータ アクセス ポリシーを作成して、認証と承認の規則を適用できます。 これらの規則は、特定のパターンに従うキャッシュ キーへのユーザー アクセスを許可するなど、さまざまな粒度レベルで指定できます。 キー パターンを使用すると、1 つのキャッシュ インスタンスとデータベースを複数のテナント間で共有でき、それぞれ独自のユーザー アカウントを使用できます。 Azure Cache for Redis では、パターンに従う独自のキー セットのみにユーザーがアクセスできるよう、テナントが強制的に分離されます。
たとえば、"Fabrikam" という名前のテナントがあるとします。 アプリケーション層は、Fabrikam に関連するキャッシュ データにのみアクセスできるようにし、他のテナントのキャッシュ データにはアクセスできないようにする必要があります。 次のように、 Fabrikamで始まるすべてのキャッシュ キーの読み取りと設定を許可する、カスタム アクセス ポリシーを定義することもできます。
+@read +set ~Fabrikam*
その後、Fabrikam アプリケーション インスタンスが使用する Microsoft Entra ID にポリシーを割り当てることができます。 キャッシュを構成したら、Fabrikam ユーザーは FabrikamData1 および FabrikamUserDetailsという名前のキーにはアクセスできますが、 ContosoData1 にはアクセスできません。
アクティブな地理的レプリケーション
多数のマルチテナント ソリューションは、地域的に分散する必要があります。 グローバルに分散されたアプリケーション層を共有し、アプリケーション インスタンスが近隣のキャッシュとの間で読み取りや書き込みを行うことにより、許容できるパフォーマンスを維持することもできます。 Azure Cache for Redis のエンタープライズ層では、 アクティブ/アクティブ構成内でリージョンをまたいで複数のキャッシュを一緒にリンクすることがサポートされています。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- John Downs | プリンシパル ソフトウェア エンジニア
- Will Velida | カスタマー エンジニア 2、FastTrack for Azure
その他の共同作成者:
- Carl Dacosta | Azure Cache for Redis のプリンシパル ソフトウェア エンジニアリング マネージャー
- Kyle Teegarden | Azure Cache for Redis のシニア プログラム マネージャー
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
マルチテナントのストレージとデータ アプローチを確認します。