Azure Managed Redis は Redis Enterprise スタック上で実行されます。Redis のコミュニティ エディションよりも大きな利点があります。 次の情報では、Azure Managed Redis がどのように構築されているかについて詳しく説明します。これには、パワー ユーザーにとって役立つ情報が含まれます。
Azure Cache for Redis との比較
Azure Cache for Redis の Basic、Standard、Premium の各レベルは、Redis のコミュニティ エディションで実行されます。 Redis のこのコミュニティ エディションには、シングル スレッド化など、いくつかの重要な制限があります。 この制限により、サービスがより多くの vCPU を完全に利用しないため、パフォーマンスが大幅に低下し、スケーリングの効率が低下します。 一般的な Azure Cache for Redis インスタンスは、次のようなアーキテクチャを使用します。
プライマリとレプリカの 2 つの VM が使用されていることに注意してください。 これらの VM はノードとも呼ばれます。 プライマリ ノードはメイン Redis プロセスを保持し、すべての書き込みを受け入れます。 メンテナンス、スケーリング、または予期しない障害時にバックアップ コピーを提供するために、レプリカ ノードに対してレプリケーションが非同期的に実行されます。 コミュニティ Redis のシングル スレッド設計により、各ノードで実行できる Redis サーバー プロセスは 1 つだけです。
Azure Managed Redis のアーキテクチャの機能強化
Azure Managed Redis は、次のようなより高度なアーキテクチャを使用します。
いくつかの違いがあります。
- 各仮想マシン (またはノード) は、複数の Redis サーバー プロセス (シャードと呼ばれます) を並列で実行します。 複数のシャードを使用すると、各仮想マシンで vCPU をより効率的に使用し、パフォーマンスを向上させることができます。
- すべてのプライマリ Redis シャードが同じ VM/ノード上にあるわけではありません。 そうではなく、プライマリ シャードとレプリカ シャードは両方のノードに分散されます。 プライマリ シャードはレプリカ シャードよりも多くの CPU リソースを使用するため、この方法では、より多くのプライマリ シャードを並列で実行できます。
- 各ノードには、シャードの管理、接続管理の処理、自己復旧のトリガーを行う高パフォーマンス プロキシ プロセスがあります。
このアーキテクチャにより、 アクティブ geo レプリケーションなどの高いパフォーマンスと高度な機能の両方が可能になります。
クラスタリング
各 Azure Managed Redis インスタンスは、すべての層と SKU でクラスタリングを使用するように内部的に構成されます。 Azure Managed Redis は、ノードごとに複数のシャードを使用できる Redis Enterprise に基づいています。 この機能には、1 つのシャードのみを使用するように設定された小さなインスタンスが含まれます。 クラスタリングは、Redis インスタンス内のデータを複数の Redis プロセス (シャーディングとも呼ばれます) に分割する方法です。 Azure Managed Redis には、キャッシュ インスタンスに接続するために Redis クライアントで使用できるプロトコルを決定する 3 つの クラスター ポリシー が用意されています。
クラスター ポリシー
Azure Managed Redis には、OSS、Enterprise、非クラスター化の 3 つのクラスタリング ポリシーが用意されています。 OSS クラスター ポリシーは、高い最大スループットをサポートするため、ほとんどのアプリケーションに適していますが、各バージョンには独自の長所と短所があります。
- Basic、Standard、Premium の非クラスター化トポロジから移行する場合は、OSS クラスタリングを使用してパフォーマンスを向上することを検討してください。 非クラスター化構成は、アプリケーションが OSS トポロジまたはエンタープライズ トポロジをサポートできない場合にのみ使用します。 OSS クラスタリング ポリシーは、Redis オープンソース ソフトウェアと同じ API を実装します。 Redis クラスター API を使用すると、Redis クライアントは各 Redis ノード上のシャードに直接接続でき、待機時間を最小限に抑え、ネットワーク スループットを最適化できます。 シャードと vCPU の数が増えると、スループットはほぼ直線的にスケーリングされます。 OSS クラスタリング ポリシーは、一般に、最も短い待機時間と最高のスループット パフォーマンスを提供します。 ただし、OSS クラスター ポリシーでは、Redis クラスター API をサポートするためにクライアント ライブラリが必要です。 現在、ほぼすべての Redis クライアントが Redis クラスター API をサポートしていますが、古いクライアント バージョンや特殊なライブラリについては、互換性が問題になる可能性があります。
RediSearch モジュールで OSS クラスタリング ポリシーを使用することはできません。
OSS クラスタリング プロトコルでは、クライアントが適切なシャード接続を行う必要があります。 初期接続はポート 10000 経由です。 個々のノードに接続すると、85XX 範囲のポートが使用されます。 85xx ポートは時間の経過とともに変化する可能性があり、アプリケーションにハードコーディングしないでください。 クラスタリングをサポートする Redis クライアントは 、CLUSTER NODES コマンドを使用して、プライマリ シャードとレプリカ シャードに使用される正確なポートを特定し、シャード接続を行います。
エンタープライズ クラスタリング ポリシーは、すべてのクライアント接続に 1 つのエンドポイントを使用する、よりシンプルな構成です。 エンタープライズ クラスタリング ポリシーを使用すると、プロキシとして機能する 1 つの Redis ノードにすべての要求がルーティングされます。 このノードは、クラスター内の正しいノードに要求を内部的にルーティングします。 この方法の利点は、Azure Managed Redis がユーザーに対してクラスター化されていない外観にすることです。 つまり、Redis クライアント ライブラリは、Redis Enterprise のパフォーマンス上の利点の一部を得るために Redis クラスタリングをサポートする必要はありません。 単一のエンドポイントを使用すると、下位互換性が向上し、接続が簡単になります。 欠点は、単一ノード プロキシがコンピューティング使用率またはネットワーク スループットのボトルネックになる可能性があるということです。
RediSearch モジュールで使用できるのは、エンタープライズ クラスタリング ポリシーだけです。 エンタープライズ クラスター ポリシーでは、Azure Managed Redis インスタンスがユーザーに非クラスター化されているように見えますが、 マルチキー コマンドにはいくつかの制限があります。
非クラスター化クラスタリング ポリシーは、シャーディングなしで各ノードにデータを格納します。 これは、サイズが 25 GB 以下のキャッシュにのみ適用されます。 非クラスター化クラスタリング ポリシーを使用するシナリオは次のとおりです。
- ハードされていない Redis 環境から移行する場合。 たとえば、Azure Cache for Redis の Basic、Standard、Premium SKU のシャードされていないトポロジです。
- クロス スロット コマンドを広範囲に実行し、データをシャードに分割すると、エラーが発生します。 たとえば、MULTI コマンドです。
- Redis をメッセージ ブローカーとして使用し、シャーディングを必要としない場合。
非クラスター化ポリシーの使用に関する考慮事項は次のとおりです。
- このポリシーは、25 GB 以下の Azure Managed Redis レベルにのみ適用されます。
- キャッシュがシャード化されている場合、CPU は Redis Enterprise ソフトウェアでのみマルチスレッドを実行できるため、他のクラスタリング ポリシーほどパフォーマンスが高くはありません。
- Azure Managed Redis キャッシュをスケールアップする場合は、まずクラスター ポリシーを変更する必要があります。
- Basic、Standard、Premium の非クラスター化トポロジから移行する場合は、OSS クラスターを使用してパフォーマンスを向上することを検討してください。 非クラスター化構成は、アプリケーションが OSS トポロジまたはエンタープライズ トポロジをサポートできない場合にのみ使用します。
ノードのスケールアウトまたは追加
コア Redis Enterprise ソフトウェアは、大規模な VM を使用してスケールアップするか、ノードまたは VM を追加してスケールアウトします。 どちらのスケーリング オプションでも、より多くのメモリ、より多くの vCPU、およびより多くのシャードが追加されます。 この冗長性のため、Azure Managed Redis では、各構成で使用される特定の数のノードを制御する機能は提供されません。 この実装の詳細は、混乱、複雑さ、および最適でない構成を回避するために抽象化されています。 代わりに、各 SKU は、vCPU とメモリを最大化するノード構成で設計されています。 Azure Managed Redis の一部の SKU では 2 つのノードが使用され、他の SKU ではより多くのノードが使用されます。
マルチキー コマンド
Azure Managed Redis インスタンスはクラスター化された構成を使用するため、複数のキーで動作するコマンドに CROSSSLOT 例外が表示される場合があります。 動作は使用されるクラスタリング ポリシーによって異なります。 OSS クラスタリング ポリシーを使用する場合は、マルチキー コマンドのすべてのキーを 同じハッシュ スロットにマップする必要があります。
Enterprise クラスタリング ポリシーで CROSSSLOT エラーが表示される場合もあります。 エンタープライズ クラスタリングを使用するスロットでは、 DEL、 MSET、 MGET、 EXISTS、 UNLINK、 TOUCHのマルチキー コマンドのみを使用できます。
Active-Active データベースでは、マルチキー書き込みコマンド (DEL、 MSET、 UNLINK) は、同じスロット内のキーでのみ実行できます。 ただし、次のマルチキー コマンドは、Active-Active データベース内のスロット間で許可されます: MGET、 EXISTS、および TOUCH。 詳細については、「データベース クラスタリング」を参照してください。
シャーディング構成
Azure Managed Redis の各 SKU は、シャードと呼ばれる特定の数の Redis サーバー プロセス を並列で実行します。 スループット のパフォーマンス、シャードの数、各インスタンスで使用できる vCPU の数の関係は複雑です。 シャードの数を手動で変更することはできません。
特定のメモリ サイズでは、メモリ最適化バージョンの vCPU とシャードの数が最も少なくなっていますが、コンピューティング最適化バージョンは最も多くなります。
通常、シャードの数を増やすと、Redis 操作を並列で実行できるため、パフォーマンスが向上します。 ただし、コマンドを実行できる vCPU がない場合は、パフォーマンスが低下する可能性があります。
シャードは、Redis サーバー プロセス、管理エージェント、およびパフォーマンスにも影響する OS システム タスクの vCPU サイクルを予約しながら、各 vCPU の使用を最適化するためにマップされます。 作成するクライアント アプリケーションは、単一の論理データベースであるかのように Azure Managed Redis と対話します。 このサービスは、vCPU とシャード間のルーティングを処理します。
SKU 内のシャードの数を増やすには、その SKU でより大きなティアを使用します。 パフォーマンスのニーズに合わせて SKU を変更することもできます。
次の表は、特定のレベル サイズのプライマリ シャードに対する vCPU の比率を示しています。 列内のデータは、これが vCPU またはシャードの数であることを保証するものではありません。 表は説明のみを目的としています。
注
Azure Managed Redis では、各 SKU で使用されるシャードと vCPU の数を変更することで、時間の経過と同時にパフォーマンスが最適化されます。
メモリ最適化バージョン、分散バージョン、コンピューティング最適化バージョン
次の表は、 Size と vCPU/プライマリ シャードの関係の一般的な例を示しています。
| レベル | メモリ最適化 | バランスが取れている | コンピューティング最適化 |
|---|---|---|---|
| サイズ (GB) | vCPU/プライマリ シャード | vCPU/プライマリ シャード | vCPU/プライマリ シャード |
| 24 ¹ | 4/2 | 8月6日 | 12月16日 |
| 60 ¹ | 8月6日 | 12月16日 | 32/24 |
¹ 特定のレベル サイズのプライマリ シャードに対する vCPU の比率は、SKU またはレベルの保証を表すわけではありません。
フラッシュ最適化バージョン
次の表は、 Size と vCPU/プライマリ シャードの関係の一般的な例を示しています。
| レベル | Flash Optimized (プレビュー) |
|---|---|
| サイズ (GB) | vCPU/プライマリ シャード |
| 480 ¹ ² | 12月16日 |
| 720 ¹ ² | 24/24 |
¹ これらのレベルはパブリック プレビュー段階です。
² 特定のレベル サイズのプライマリ シャードに対する vCPU の比率は、SKU または層の保証を表すわけではありません。
Von Bedeutung
235 GB を超えるストレージを使用するすべてのインメモリ層は、メモリ最適化 M350 以降、バランス B350 以上、およびコンピューティング最適化 X350 以降を含み、パブリックプレビュー段階にあります。 これらのレベル以上はすべてパブリック プレビュー段階です。
フラッシュ最適化レベルはすべてパブリック プレビュー段階です。
高可用性モードを有効にせずに実行する
高可用性 (HA) モードを有効にせずに実行できます。 この構成は、Redis インスタンスでレプリケーションが有効になっていないこと、および可用性 SLA にアクセスできないことを意味します。 開発とテストのシナリオ以外では、HA 以外のモードでは実行しないでください。 既に作成したインスタンスで高可用性を無効にすることはできません。 高可用性を持たないインスタンスで高可用性を有効にできます。 高可用性なしで実行されているインスタンスは使用する VM とノードの数が少ないため、vCPU は効率的に使用されないため、パフォーマンスが低下する可能性があります。
予約されるメモリ
各 Azure Managed Redis インスタンスでは、使用可能なメモリの約 20% が、フェールオーバー中のレプリケーションやアクティブ geo レプリケーション バッファーなどのキャッシュ以外の操作のバッファーとして予約されます。 このバッファーは、キャッシュのパフォーマンスを向上させ、メモリ不足を防ぐのに役立ちます。
スケールダウン
現在、スケールダウンは Azure Managed Redis ではサポートされていません。 詳細については、「 Azure Managed Redis のスケーリングの制限事項」を参照してください。
フラッシュ最適化レベル
フラッシュ最適化レベルは、NVMe フラッシュ ストレージと RAM の両方を利用します。 フラッシュ ストレージの方がコストが低いため、フラッシュ最適化レベルを使用すると、価格効率のためにパフォーマンスをトレードオフできます。
フラッシュ最適化インスタンスでは、キャッシュ領域の 20% が RAM 上にあり、残りの 80% はフラッシュ ストレージを使用します。 キーはすべて RAM に格納されますが、値はフラッシュ ストレージまたは RAM に格納できます。 Redis ソフトウェアは、値の場所をインテリジェントに決定します。 頻繁にアクセスされる "ホット" 値は RAM に格納され、使用頻度の低い "コールド" 値はフラッシュに保持されます。 データを読み取るか書き込む前に、RAM に移動し、"ホット" データにする必要があります。
Redis は最適なパフォーマンスのために最適化するので、インスタンスは最初に使用可能な RAM をいっぱいにしてから、フラッシュ ストレージに項目を追加します。 最初に RAM に格納することで、パフォーマンスにいくつかの影響があります。
- メモリ使用量が少ないテストでは、パフォーマンスが向上し、待ち時間が短くなる可能性があります。 フル キャッシュ インスタンスを使用したテストでは、メモリ使用量の少ないテスト フェーズで RAM のみが使用されるため、パフォーマンスが低下する可能性があります。
- キャッシュに書き込むデータが増えるにつれて、RAM 内のデータの割合がフラッシュ ストレージと比較して減少し、通常、待機時間とスループットのパフォーマンスも低下します。
フラッシュ最適化レベルに適したワークロード
フラッシュ最適化レベルで適切に実行されるワークロードには、多くの場合、次の特性があります。
- 読み取り負荷が高く、書き込みコマンドに対する読み取りコマンドコマンドの比率が高い。
- Access は、データセットの残りの部分よりもはるかに頻繁に使用するキーのサブセットに重点を置きます。
- キー名と比較して値が比較的大きい。 (キー名は常に RAM に格納されるため、大きい値がメモリの増加のボトルネックになる可能性があります)。
フラッシュ最適化レベルに適していないワークロード
一部のワークロードには、フラッシュ最適化レベルの設計に対してあまり適していないアクセス特性があります。
- 書き込み負荷の高いワークロード。
- データセットの大部分にわたるランダムまたは均一なデータ アクセスのパターン。
- 値のサイズが比較的小さい長いキー名。