Azure Managed Redis のパフォーマンス テスト (プレビュー)

Redis インスタンスのパフォーマンスのテストは、複雑な作業になることがあります。 Redis インスタンスのパフォーマンスは、クライアントの数、データ値のサイズ、パイプラインが使用されているかどうかなどのパラメーターに応じて変わることがあります。 スループットと待機時間の最適化の間にはトレードオフが存在する場合もあります。

幸いなことに、Redis のベンチマークを容易にするツールがいくつかあります。 最も一般的な 2 つのツールは、redis-benchmark と memtier-benchmark です。 この記事では、しばしば memtier と呼ばれる、memtier_benchmark について説明します。

memtier_benchmark ユーティリティの使用方法

1. テストに使用できるクライアント仮想マシン (VM) に memtier をインストールします。 オープンソース イメージをインストールする方法については、Memtier のドキュメントを参照してください。

2. テストに使用するクライアント仮想マシン (VM) は、Azure Managed Redis (AMR) インスタンスと "同じリージョン" にある必要があります。

3. 使用するクライアント VM が、テストするキャッシュ インスタンスと "少なくとも同等のコンピューティングおよび帯域幅" を持っていることを確認します。

4. クライアント VM が Azure Managed Redis インスタンスにアクセスできるように、ネットワークの分離とファイアウォールの設定を構成します。

5. キャッシュ インスタンスで TLS/SSL を使用している場合は、--tls パラメーターと --tls-skip-verify パラメーターを memtier_benchmark コマンドに追加する必要があります。

6. memtier_benchmark では、既定でポート 6379 を使用します。 AMR では代わりにポート 10000 が使用されるため、-p 10000 パラメーターを使用してこの設定をオーバーライドします。

7. OSS クラスター ポリシーを使用するすべての Azure Managed Redis インスタンスについては、memtier コマンドに --cluster-mode パラメーターを追加する必要があります。 Enterprise クラスター ポリシーを使用する AMR インスタンスは、非クラスター化キャッシュとして扱うことができ、この設定は必要ありません。

8. VM の CLI またはシェルから memtier_benchmark を起動します。 ツールを構成して実行する方法については、Memtier のドキュメントを参照してください。

ベンチマークに関する推奨事項

• 必要なパフォーマンスが得られない場合は、より高度なレベルにスケールアップしてみてください。 通常、Balanced レベルにはメモリ最適化レベルの 2 倍の数の vCPU があり、コンピューティング最適化レベルには通常、Balanced レベルの 2 倍の数の vCPU があります。 Azure Managed Redis はコミュニティ Redis ではなく Redis Enterprise 上に構築されているため、コア Redis プロセスでは複数の vCPU を利用できます。 その結果、より多くの vCPU を持つインスタンスのスループット パフォーマンスが大幅に向上します。

• より大きなメモリ サイズにスケールアップすると、vCPU も増え、パフォーマンスが向上します。 ただし、通常、より大きなメモリ サイズにスケールアップすることは、パフォーマンスの高いレベルを使用することに比べて効果は低くなります。 各サイズとレベルで使用可能な vCPU の詳細な内訳については、「レベルと SKU の概要」を参照してください。

• フラッシュ最適化レベルのベンチマークは困難な場合があります。これは、キーの中には DRAM に格納されているものと、NVMe フラッシュ ディスクに格納されているものがあるためです。 DRAM ベンチマークのキーは、他の Azure Managed Redis インスタンスとほぼ同じ速度ですが、NVMe フラッシュ ディスク上のキーは低速です。 フラッシュ最適化レベルでは、最も使用されているキーがインテリジェントに DRAM に配置されるため、ベンチマーク構成が予想される実際の使用状況と一致していることを確認してください。

• TLS/SSL を使用するとスループットのパフォーマンスが低下しますが、運用環境のベスト プラクティスとして強くお勧めします。

• ベンチマークの前に、まず Redis インスタンスにデータをいっぱいに入力することが不可欠です。 空のキャッシュでベンチマークを実行すると、実際に見られるよりもはるかに優れた結果が得られます。

• 使用される接続の数は、ベンチマークに大きな影響を与えます。 接続が多すぎると、キャッシュのパフォーマンスが低下し始めます。 使用する接続数が少なすぎると、キャッシュの完全なパフォーマンスは示されません。 実際のアプリケーションのニーズに基づいて接続数を構成することをお勧めします。 接続の総数は、クライアントの数とスレッドの数を乗算して決定します。

• パイプライン構成は、パフォーマンス テストに大きな影響を与えます。 パイプラインの設定をより大きく設定すると、スループットは増えますが、待ち時間はより長くなります。 詳細については、「パイプライン」を参照してください。

memtier_benchmark の例

テスト前のセットアップ: テストに必要なデータを使用してキャッシュ インスタンスを準備します。 データをインスタンスに読み込むと、結果に実際の条件がより正確に反映されます。 {number-of-keys} パラメーターは、AMR インスタンスのサイズと各キーのサイズによって決定する必要があります。 十分な経験則としては、インスタンスを、バッファー分を残して約 75% までいっぱいにすることです。 次の数式を使用できます: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300)。 たとえば、前に示したように、1,024 バイトのキー サイズを使用してコンピューティング最適化 X3 インスタンスでベンチマークを実行する場合、これは {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300)を意味します。 結果は約 1,699,396 個のキーに相当します。

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 --key-maximum=1699396 -n allkeys --key-pattern=P:P --ratio=1:0 -data-size=1024 --tls --cluster-mode

スループットをテストするには: このコマンドは、1k ペイロードでパイプライン化された GET 要求をテストします。 このコマンドを使用して、キャッシュ インスタンスから予想される読み取りスループットをテストします。 この例では、TLS と OSS クラスター ポリシーを使用していることを前提としています。 --key-pattern=R:R パラメーターを使用すると、キーがランダムにアクセスされ、ベンチマークが実際に向上します。 このテストは 5 分間実行されます。

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 -d 1024 --key-maximum=1699396 --key-pattern=R:R --ratio=0:1 --distinct-client-seed --test-time=300 --json-out-file=test_results.json --tls --tls-skip-verify --cluster-mode

パフォーマンス ベンチマーク データの例

次の表は、Azure Managed Redis インスタンスのさまざまなサイズをテストするときに観察された最大スループット値を示しています。 「memtier_benchmarkの例」セクションに示されている memtier コマンドを使用して、IaaS Azure VM の memtier_benchmark を Azure Managed Redis エンドポイントに対して使用しました。 スループットの数値は、GET コマンドについてのみ示しています。 通常、SET コマンドのスループットは低くなります。 実際のパフォーマンスは、Redis の構成とコマンドによって異なります。 これらの数値は、保証ではなく、評価基準として提供されます。

Azure Managed Redis には、クラスター ポリシー (Enterprise と OSS) の選択肢が提供されます。 Enterprise クラスター ポリシーはよりシンプルな構成であり、クラスタリングをサポートするためのクライアントを必要としません。 一方、OSS クラスター ポリシーは Redis クラスター プロトコルを使用して、より高いスループットをサポートします。 ほとんどの場合、OSS クラスター ポリシーを使用することをお勧めします。 詳細については、「クラスタリング」に関する記事を参照してください。

以下の表には、両方のクラスター ポリシーのベンチマークが示されています。 OSS クラスター ポリシー テーブルには、次の 2 つのベンチマーク構成が用意されています。

• 300 接続 (50 クライアントおよび 6 スレッド)
• 2,500 接続 (50 クライアントおよび 50 スレッド)

2 つ目のベンチマークが提供されているのは、300 個の接続では、より大きなキャッシュ インスタンスのパフォーマンスを十分に実証できないためです。

ベンチマークに使用されるクライアント接続の数による、AMR インスタンスの 1 kB ペイロードに対する 1 秒あたりの GET 操作のスループットを次に示します。 すべての数値は、SSL 接続を使用する AMR インスタンスに対して計算され、ネットワーク帯域幅は Mbps で記録されます。