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 データ構造またはキー プレフィックスを使用して各テナントのデータを識別する | 高。 キー プレフィックスに基づいてデータが分離される | 低。 データは分離されますが、セキュリティの分離は提供されません | 高 |
| パフォーマンスの分離 | 低。 すべてのテナントが同じコンピューティング リソースを共有する | 低。 すべてのテナントが同じコンピューティング リソースを共有する | 低。 すべてのテナントが同じコンピューティング リソースを共有する | 高 |
| 配置の複雑性 | 低 | 低から中 | ミディアム | 中/高 |
| 操作の複雑さ | 低 | 低から中 | 低 | 中/高 |
| リソース コスト | 低 | 低 | 低 | 高 |
| サンプル シナリオ | 共有アプリケーション層を備えた大規模なマルチテナント ソリューション | キャッシュにアクセスする個別のアプリケーション ID を持つ大規模なマルチテナント ソリューション | マルチテナント対応にシングルテナント アプリケーションを移行する | テナントごとの個々のアプリケーション インスタンス |
共有キャッシュ インスタンスと共有データベース
1 つの Redis データベースを使用して 1 つのキャッシュをデプロイし、それを使用してすべてのテナントのキャッシュされたデータを格納することを検討できます。 この方法は、すべてのテナントが共有する単一のアプリケーション インスタンスがある場合に一般的に使用されます。
このアプローチに従う場合、アプリケーションはテナント データを分離する責任を単独で負います。 キー プレフィックスを使用して異なるテナントからデータを区別できますが、アプリケーションでは、操作しているテナントのデータにのみアクセスする作業を行う必要があります。 また、各テナントのデータに対して、 セット や ハッシュなどの Redis データ構造の使用を検討することもできます。 これらのアプローチはそれぞれ多数のキーをサポートしているため、多くのテナントにスケーリングできます。 ただし、キャッシュ内ではなく、アプリケーション内で承認を管理する必要があります。
テナント間でキャッシュ インスタンスとデータベースを共有する場合は、すべてのテナントがキャッシュの基になる同じコンピューティング リソースを共有することを検討してください。 そのため、このアプローチは 、ノイズの多い近隣の問題に対して脆弱になる可能性があります。 Azure Cache for Redis のベスト プラクティスに従って、キャッシュのリソースを最も効率的に使用し、ノイズの多い近隣の影響を軽減してください。 ベスト プラクティスには次のようなものがあります。
さらに、CPU やメモリなど、キャッシュのリソースを監視することを検討してください。 リソースの負荷が高い場合は、次の軽減策を検討してください。
- より高レベルのリソースを使用して、キャッシュの SKU や階層をスケールアップします。
- キャッシュされたデータをシャーディングして、複数のキャッシュにスケールアウトします。 1 つのオプションは、テナントごとにシャード化することです。一部のテナントはキャッシュ A を使用し、一部はキャッシュ B を使用します。または、ソリューションの 1 つの部分が A をキャッシュするためにすべてのテナントのデータをキャッシュし、ソリューションの別の部分がキャッシュ B にキャッシュするサブシステムでシャード化することもできます。
アクセス制御リストを使用した共有キャッシュとデータベース
アプリケーション層で個別の ID を使用して各テナントのキャッシュにアクセスする場合は、Redis アクセス制御リストを使用します。 アクセス制御リストを使用すると、テナントの情報へのアクセスを特定の ID に制限できます。 キー名またはプレフィックスに基づいて、ID がアクセスできるデータを特定します。 この方法は、テナントごとに異なるアプリケーション インスタンスがある場合や、複数の ID を使用してテナント コンテキストに基づいてダウンストリーム サービスにアクセスする共有アプリケーションがある場合に適しています。
前の分離モデルと同様に、キャッシュとデータベースを共有するということは、ノイズの多い近隣の問題を回避するために予防措置を講じる必要があることを意味します。
テナントごとのデータベースを含む共有キャッシュ インスタンス
1 つのキャッシュ インスタンスをデプロイし、そのインスタンス内にテナント固有の Redis データベースをデプロイする方法も考えられます。 この方法では、各テナントのデータをある程度論理的に分離できますが、ノイズの多い近隣ノードに対するパフォーマンスの分離や保護は提供されません。
この方法は、移行シナリオに役立つ場合があります。 たとえば、複数のテナントで動作するように設計されていないシングルテナント アプリケーションを最新化し、すべての要求にテナント コンテキストを含めることで、それをマルチテナント対応に徐々に変換するとします。 1 つの共有キャッシュを使用することでコスト効率を高めることができます。また、テナント キー プレフィックスやテナント固有のデータ構造を使用するようにアプリケーションのロジックを更新する必要はありません。
Azure Cache for Redis では、 1 つのキャッシュに作成できるデータベースの数に制限があります。 このアプローチを実装する前に、拡大する予定のテナントの数を検討してください。
さらに、この方法では、データのセキュリティ分離に関する利点はありません。 Azure Cache for Redis では、認証と承認はキャッシュ インスタンス レベルで実行されます。
注
Azure Cache for Redis では、特定のレベルで複数のデータベースがサポートされており、クラスター化されたインスタンスを使用する場合、複数のデータベースはサポートされません。
テナントごとのキャッシュ インスタンス
テナントごとに Azure Cache for Redis の個別のインスタンスをデプロイすることを検討してください。 1 つの 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にはアクセスできません。
アクティブ geo レプリケーション
多くのマルチテナント ソリューションは、地理的に分散する必要があります。 グローバルに分散されたアプリケーション層を共有し、アプリケーション インスタンスが近隣のキャッシュとの間で読み取りや書き込みを行うことにより、許容できるパフォーマンスを維持することもできます。 Azure Cache for Redis の Enterprise レベルでは 、アクティブ/アクティブ構成で複数のキャッシュをリージョン間でリンクできます。
貢献者
この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。
主要な著者:
- John Downs | プリンシパル ソフトウェア エンジニア
- Will Velida | カスタマー エンジニア 2、FastTrack for Azure
その他の共同作成者:
- カール・ダコスタ |プリンシパル ソフトウェア エンジニアリング マネージャー、Azure Cache for Redis
- カイル・ティーガルデン |Azure Cache for Redis のシニア プログラム マネージャー
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。