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 レプリケーションなどの高度な機能の両方を可能にしています

クラスタリング

Redis Enterprise はノードごとに複数のシャードを使用できるため、各 Azure Managed Redis インスタンスは、すべての層と SKU にわたってクラスタリングを使用するように内部的に構成されます。 これには、1 つのシャードを使用するように設定されただけの小さなインスタンスが含まれます。 クラスタリングとは、Redis インスタンス内のデータを複数の Redis プロセスに分割 ("シャーディング" とも呼ばれます) する方法です。Azure Managed Redis には、キャッシュ インスタンスに接続するために Redis クライアントで使用できるプロトコルを決定する 2 つのクラスター ポリシーが用意されています。

クラスター ポリシー

Azure Managed Redis は、クラスタリング ポリシーに OSS と Enterprise の 2 つの選択肢を提供しています。 OSS クラスター ポリシーは最大スループットが高くなるためほとんどのアプリケーションにお勧めしますが、各バージョンには長所と短所があります。

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

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

ノードのスケールアウトまたは追加

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 インスタンスのスケーリング