Azure Managed Redis のアーキテクチャ

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 がシングル スレッド化設計であるため、各ノードが実行できるのは、1 つの Redis サーバー プロセスのみです。

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 クラスター ポリシーは最大スループットが高くなるためほとんどのアプリケーションにお勧めしますが、各バージョンには長所と短所があります。

OSS クラスタリング ポリシーは、Azure Cache for Redis レベルと同じ Redis クラスター API を実装します。 Redis クラスター API を使用すると、Redis クライアントが各 Redis ノードのシャードに直接接続できるため、待機時間が最小になり、ネットワークのスループットが最適化され、シャードと vCPU の数が増えるとほぼ直線的にスループットが増加します。 OSS クラスタリング ポリシーは、通常、最適な待機時間とスループット パフォーマンスを提供します。 ただし、OSS クラスター ポリシーは、Redis クラスター API をサポートするためにクライアント ライブラリを必要とします。 現在、ほぼすべての Redis クライアントが Redis クラスター API をサポートしていますが、古いクライアント バージョンや特殊なライブラリについては、互換性が問題になる可能性があります。

OSS クラスタリング ポリシーは 、RediSearch モジュールでは使用できません。

OSS クラスタリング プロトコルでは、クライアントが適切なシャード接続を行う必要があります。 初期接続はポート 10000 経由です。 個々のノードへの接続は、85XX 範囲のポートを使用して行われます。 85xx ポートは時間の経過と同時に変化する可能性があり、アプリケーションにハードコーディングしないでください。 クラスタリングをサポートする Redis クライアントは 、CLUSTER NODES コマンドを使用して、プライマリ シャードとレプリカ シャードに使用される正確なポートを特定し、シャード接続を行います。

"Enterprise クラスタリング ポリシー" は、すべてのクライアント接続に単一のエンドポイントを使用するという、よりシンプルな構成です。 Enterprise クラスタリング ポリシーを使用すると、すべての要求が 1 つの Redis ノードにルーティングされ、その後プロキシとして使用され、クラスター内の正しいノードに要求が内部的にルーティングされます。 この方法の利点は、Azure Managed Redis がユーザーに対してクラスター化されていない外観にすることです。 つまり、Redis クライアント ライブラリは、Redis Enterprise のパフォーマンス上の利点の一部を得るために Redis クラスタリングをサポートする必要はありません。 単一のエンドポイントを使用すると、下位互換性が向上し、接続が簡単になります。 欠点は、単一ノード プロキシが、コンピューティング使用率またはネットワーク スループットのボトルネックになる可能性があるということです。

Enterprise クラスタリング ポリシーは、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 エラーが表示される場合もあります。 Enterprise クラスタリングを使用するスロットでは、DEL、MSET、MGET、EXISTS、UNLINK、TOUCH のマルチキー コマンドのみを使用できます。

アクティブ/アクティブ データベースでは、マルチキー書き込みコマンド (DEL、MSET、UNLINK) は、同じスロット内のキーに対してのみ実行できます。 ただし、次のマルチキー コマンドは、アクティブ/アクティブ データベース内のスロット間で許可されます: MGET、EXISTS、および TOUCH。 詳細については、「データベース クラスタリング」を参照してください。

シャーディング構成

Azure Managed Redis の各 SKU は、特定の数の Redis サーバー プロセス ("シャード") を並列に実行するように構成されています。 スループット パフォーマンス、シャードの数、および各インスタンスで使用できる vCPU の数の関係は複雑です。 通常、シャードを追加すると、Redis 操作を並列で実行できるため、パフォーマンスが向上します。 ただし、コマンドを実行する vCPU がないためにシャードがコマンドを実行できない場合は、パフォーマンスが実際には低下する可能性があります。 次の表に、各 Azure Managed Redis SKU のシャーディング構成を示します。 これらのシャードが、各 vCPU の使用を最適化するためにマップされ、その一方で Redis Enterprise プロキシ、管理エージェント、OS システム タスクに対する vCPU サイクルが予約されます。こちらもパフォーマンスに影響します。

* これらのレベルはパブリック プレビュー段階です。

高可用性モードを有効にせずに実行する

高可用性 (HA) モードを有効にせずに実行することが可能です。 これは、Redis インスタンスでレプリケーションが有効ではないことと、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 内のデータの割合がフラッシュ ストレージと比較して減少し、通常、待機時間とスループットのパフォーマンスも低下します。

フラッシュ最適化レベルに適したワークロード

多くの場合、フラッシュ最適化レベルで適切に動作する可能性が高いワークロードには、次の特性があります。

• 読み取り負荷が高く、書き込みコマンドに対する読み取りコマンドコマンドの比率が高い。
• データセットの残りの部分よりもはるかに頻繁に使用されるキーのサブセットにアクセスの重点が置かれている。
• キー名と比較して値が比較的大きい。 (キー名は常に RAM に格納されるため、大きい値がメモリの増加のボトルネックになる可能性があります)。

フラッシュ最適化レベルに適していないワークロード

一部のワークロードには、フラッシュ最適化レベルの設計に対してあまり適していないアクセス特性があります。

• 書き込み負荷の高いワークロード。
• データセットの大部分にわたるランダムまたは均一なデータ アクセスのパターン。
• 値のサイズが比較的小さい長いキー名。

関連コンテンツ

• Azure Managed Redis インスタンスのスケーリング