Redis インスタンスのパフォーマンスのテストは、複雑な作業になることがあります。 Redis インスタンスのパフォーマンスは、クライアントの数、データ値のサイズ、パイプラインが使用されているかどうかなどのパラメーターに応じて変わることがあります。 スループットと待機時間の最適化の間にはトレードオフが存在する場合もあります。
幸いなことに、Redis のベンチマークを容易にするツールがいくつかあります。 最も一般的な 2 つのツールは、redis-benchmark と memtier-benchmark です。 この記事では、redis-benchmark について説明します。
redis-benchmark ユーティリティの使用方法
テストに使用できるクライアント仮想マシン (VM) に、オープンソース Redis サーバーをインストールします。 redis-benchmark ユーティリティは、オープンソース Redis ディストリビューションに組み込まれています。 オープンソース イメージをインストールする方法については、Redis のドキュメントを参照してください。
テストに使用するクライアント VM は、Azure Cache for Redis インスタンスと "同じリージョン内に" ある必要があります。
使用するクライアント VM が、テストするキャッシュ インスタンスと "少なくとも同等のコンピューティングおよび帯域幅" を持っていることを確認します。
クライアント VM が Azure Cache for Redis インスタンスにアクセスできるように、ネットワークの分離とファイアウォールの設定を構成します。
キャッシュ インスタンスで TLS/SSL を使用する場合は、redis-benchmark コマンドに
--tlsパラメーターを追加するか、stunnel などのプロキシを使用する必要があります。Redis-benchmarkでは、既定でポート 6379 を使用します。-pパラメーターを使用して、この設定をオーバーライドします。 SSL/TLS (ポート 6380) を使用する場合、または Enterprise レベル (ポート 10000) を使用する場合は、-pを使用する必要があります。クラスタリングを使用する Azure Cache for Redis インスタンスを使用する場合は、
redis-benchmarkコマンドに--clusterパラメーターを追加する必要があります。 Enterprise クラスタリングを使用する Enterprise レベル キャッシュは、非クラスター化キャッシュとして扱うことができ、この設定は必要ありません。VM の CLI またはシェルから
redis-benchmarkを起動します。 ツールを構成して実行する方法については、redis-benchmark のドキュメントと「redis-benchmark の例」のセクションを参照してください。
ベンチマークに関する推奨事項
キャッシュのパフォーマンス テストは、安定状態の条件下のみで行わないようにすることが重要です。 フェールオーバーの状態でもテストし、その間のキャッシュの CPU またはサーバーの負荷を測定します。 フェールオーバーを開始するには、プライマリ ノードを再起動します。 フェールオーバー状態でテストを行うと、フェールオーバー状態の間のアプリケーションのスループットと待機時間を確認できます。 フェールオーバーは、更新時や、計画外のイベント時に発生する可能性があります。 パフォーマンスに影響する可能性があるため、理想的には、フェールオーバー中であっても CPU/サーバー負荷のピークが 80% を超えないようにすることをお勧めします。
Enterprise および Premium レベルの Azure Cache for Redis インスタンスの使用を検討してください。 これらのキャッシュ サイズでは、優れたハードウェアで実行されるため、ネットワーク待機時間とスループットが向上します。
Redis Enterprise では Redis のコア プロセスが複数の vCPU を利用できるため、一般的に、Enterprise レベルが最高のパフォーマンスを発揮します。 Standard や Premium など、オープンソース Redis をベースにしたレベルでは、Redis プロセスに対してシャードごとに 1 つの vCPU しか使用できません。
Enterprise Flash レベルのベンチマークは困難な場合があります。これは、キーの中に DRAM に格納されているものと、NVMe フラッシュ ディスクに格納されているものがあるためです。 DRAM 上のキーのベンチマークは Enterprise レベルのインスタンスとほぼ同じ速度ですが、NVMe フラッシュ ディスク上のキーは低速です。 Enterprise Flash レベルでは、最も使用されているキーがインテリジェントに DRAM に配置されるため、ベンチマーク構成が予想される実際の使用状況と一致していることを確認してください。
-rパラメーターを使用して、アクセスされるキーをランダム化することを検討してください。TLS/SSL を使用するとスループットのパフォーマンスが低下します。これは、以下の表のベンチマーク データの例で明確に確認できます。
Redis サーバーはシングルスレッドですが、スケールアップによってスループット パフォーマンスが向上する傾向があります。 システム プロセスでは、Redis プロセスで使用されている vCPU を共有する代わりに、追加の vCPU を使用できます。 Redis Enterprise は単一スレッドに制限されていないため、スケールアップは Enterprise および Enterprise Flash レベルで特に有用です。
Premium レベルでは、通常、スケールアップの前にスケールアウト (クラスタリング) をお勧めします。 クラスタリングを使用すると、Redis サーバーはデータのシャーディングによって、より多くの vCPU を使用できるようになります。 この場合、シャードを追加するとスループットがほぼ直線的に増加するはずです。
C0 および C1 Standard のキャッシュでは、内部 Defender スキャンが VM 上で実行されている間に、キャッシュ要求の増加以外の要因で、サーバーの負荷の短期的な急増が発生する場合があります。 内部 Defender スキャンがこれらのレベルで実行される場合、日ごとに 2 回前後、要求の待ち時間が長くなります。 C0 および C1 レベルのキャッシュには、マルチタスクを実行するコアが 1 つだけあり、ウイルス スキャンと Redis 要求の処理が分割されます。 C2などの複数の CPU コアを持つオファリングにスケーリングすると、その影響を軽減できます。
上位レベルではキャッシュ サイズが増加するため、待機時間の問題に対処できます。 また、C2 レベルでは、2,000 のクライアント接続をサポートしています。
Redis ベンチマークの例
テスト前のセットアップ: 待機時間とスループットのテストに必要なデータを使用してキャッシュ インスタンスを準備します。
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024
待機時間をテストするには: 1 K のペイロードを使用して GET 要求をテストします。
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4
スループットをテストするには: 1 K のペイロードを使用した、パイプラインされた GET 要求。
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
TLS を使用して Basic、Standard、Premium レベルのキャッシュのスループットをテストする場合: 1k のペイロードを使用して、パイプライン化された GET 要求を実行します。
redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --tls
OSS クラスター モードを使用して、TLS を使用せずに Enterprise または Enterprise Flash キャッシュのスループットをテストする場合: 1k のペイロードを使用して、パイプライン化された GET 要求を実行します。
redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --cluster
パフォーマンス ベンチマーク データの例
以下の表は、Standard、Premium、Enterprise、Enterprise Flash の各キャッシュのさまざまなサイズをテストした際に観測された最大スループット値を示しています。 Azure Cache for Redis エンドポイントに対して、IaaS Azure VM から redis-benchmark と memtier-benchmark を使用しました。 スループットの数値は、GET コマンドについてのみ示しています。 通常、SET コマンドのスループットは低くなります。 これらの数値はスループット用に最適化されています。 許容できる待機時間の条件下での実際のスループットは低くなる可能性があります。
注意事項
これらの値は保証されるものではなく、これらの数値に対する SLA もありません。 ご使用のアプリケーションに適したキャッシュ サイズを判別するために、お客様自身でパフォーマンス テストを実行することを強くお勧めします。 定期的に新しい結果を公表しているため、これらの数字は変わる可能性があります。
重要
Microsoft は、キャッシュ インスタンスで使われる基になる VM を定期的に更新します。 このため、キャッシュごと、およびリージョンごとに、パフォーマンス特性が異なる可能性があります。 このページのベンチマークの例の値は、単一リージョン内の古い世代のキャッシュ ハードウェアを反映しています。 実際には、さらに良い結果や異なる結果になる場合があります。
次の構成は、Basic、Standard、Premium レベルのスループットをベンチマークするために使用されました。
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
Standard レベルの Redis ベンチマーク
| インスタンス | サイズ | vCPU 数 | 必要なネットワーク帯域幅 (Mbps) | SSL を使用しない 1 秒あたりの GET 要求数 (1 kB の値サイズ) | SSL を使用する 1 秒あたりの GET 要求数 (1 kB の値サイズ) |
|---|---|---|---|---|---|
| C0 | 250 MB | 共有 | 100 | 15,000 | 7,500 |
| C1 | 1 GB | 1 | 500 | 38,000 | 20,720 |
| C2 | 2.5 GB | 2 | 500 | 41,000 | 37,000 |
| C3 | 6 GB | 4 | 1000 | 100,000 | 90,000 |
| C4 | 13 GB | 2 | 500 | 60,000 | 55,000 |
| C5 | 26 GB | 4 | 1,000 | 102,000 | 93,000 |
| C6 | 53 GB | 8 | 2,000 | 126,000 | 120,000 |
Premium レベルの Redis ベンチマーク
| インスタンス | サイズ | vCPU 数 | 必要なネットワーク帯域幅 (Mbps) | SSL を使用しない 1 秒あたりの GET 要求数 (1 kB の値サイズ) | SSL を使用する 1 秒あたりの GET 要求数 (1 kB の値サイズ) |
|---|---|---|---|---|---|
| P1 | 6 GB | 2 | 1,500 | 180,000 | 172,000 |
| P2 | 13 GB | 4 | 3,000 | 350,000 | 341,000 |
| P3 | 26 GB | 4 | 3,000 | 350,000 | 341,000 |
| P4 | 53 GB | 8 | 6,000 | 400,000 | 373,000 |
| P5 | 120 GB | 32 | 6,000 | 400,000 | 373,000 |
重要
中国東部リージョンと中国北部リージョンの P5 インスタンスでは、32 コアではなく 20 コアが使用されます。
Enterprise および Enterprise Flash レベル
Enterprise および Enterprise Flash レベルでは、クラスター ポリシーを Enterprise と OSS から選択できます。 Enterprise クラスター ポリシーはよりシンプルな構成であり、クラスタリングをサポートするためのクライアントを必要としません。 一方、OSS クラスター ポリシーは Redis クラスター プロトコルを使用して、より高いスループットをサポートします。 ほとんどの場合、OSS クラスター ポリシーを使用することをお勧めします。 詳細については、「クラスタリング」に関する記事を参照してください。 以下の表には、両方のクラスター ポリシーのベンチマークが示されています。
次の構成は、Enterprise および Enterprise フラッシュ レベルのスループットをベンチマークするために使用されました。
redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 10000000 -d 1024 -P 50 -c 50 --threads 32
注意
この構成は、Basic、Standard、Premium レベルのベンチマークに使用される構成とほぼ同じです。 ただし、以前の構成では、Enterprise レベルのコンピューティング パフォーマンスが十分に活用されていませんでした。 完全なパフォーマンスを示すために、この構成に要求とスレッドが追加されました。
Enterprise クラスター ポリシー
| インスタンス | サイズ | vCPU 数 | 必要なネットワーク帯域幅 (Mbps) | SSL を使用しない 1 秒あたりの GET 要求数 (1 kB の値サイズ) |
SSL を使用する 1 秒あたりの GET 要求数 (1 kB の値サイズ) |
|---|---|---|---|---|---|
| E10 | 12 GB | 4 | 4,000 | 300,000 | 207,000 |
| E20 | 25 GB | 4 | 4,000 | 680,000 | 480,000 |
| E50 | 50 GB | 8 | 8,000 | 1,200,000 | 900,000 |
| E100 | 100 GB | 16 | 10,000 | 1,700,000 | 1,650,000 |
| F300 | 384 GB | 8 | 3,200 | 500,000 | 390,000 |
| F700 | 715 GB | 16 | 6,400 | 500,000 | 370,000 |
| F1500 | 1455 GB | 32 | 12,800 | 530,000 | 390,000 |
OSS クラスター ポリシー
| インスタンス | サイズ | vCPU 数 | 必要なネットワーク帯域幅 (Mbps) | SSL を使用しない 1 秒あたりの GET 要求数 (1 kB の値サイズ) |
SSL を使用する 1 秒あたりの GET 要求数 (1 kB の値サイズ) |
|---|---|---|---|---|---|
| E10 | 12 GB | 4 | 4,000 | 1,400,000 | 1,000,000 |
| E20 | 25 GB | 4 | 4,000 | 1,200,000 | 900,000 |
| E50 | 50 GB | 8 | 8,000 | 2,300,000 | 1,700,000 |
| E100 | 100 GB | 16 | 10,000 | 3,000,000 | 2,500,000 |
| F300 | 384 GB | 8 | 3,200 | 1,500,000 | 1,200,000 |
| F700 | 715 GB | 16 | 6,400 | 1,600,000 | 1,200,000 |
| F1500 | 1455 GB | 32 | 12,800 | 1,600,000 | 1,110,000 |
Enterprise および Enterprise Flash レベル - スケールアウト
より大きなキャッシュ サイズへの移行によるスケールアップだけでなく、スケールアウトによってパフォーマンスを向上させることもできます。Enterprise レベルでは、スケールアウトはキャッシュ インスタンスの "容量" の増加と呼ばれます。 既定では、キャッシュ インスタンスの容量は 2 です。これは、プライマリとレプリカのノードを意味します。 容量が 4 の Enterprise キャッシュ インスタンスは、インスタンスが 2 倍にスケールアウトされたことを示します。 スケールアウトすると、より多くのメモリと vCPU にアクセスできるようになります。 各キャッシュ サイズと容量で Redis のコア プロセスによって使用される vCPU 数の詳細については、シャーディングの構成に関する記事を参照してください。 OSS クラスター ポリシーを使用する場合、スケールアウトは最も効果的です。
以下の表は、SSL と 1 kB の値サイズを使用した場合の、さまざまな容量での 1 秒あたりの GET 要求数を示しています。
スケールアウト - Enterprise クラスター ポリシー
| インスタンス | 容量 2 | 容量 4 | 容量 6 |
|---|---|---|---|
| E10 | 200,000 | 830,000 | 930,000 |
| E20 | 480,000 | 710,000 | 950,000 |
| E50 | 900,000 | 1,110,000 | 1,200,000 |
| E100 | 1,600,000 | 1,120,000 | 1,200,000 |
| インスタンス | 容量 3 | 容量 9 |
|---|---|---|
| F300 | 390,000 | 640,000 |
| F700 | 370,000 | 610,000 |
| F1500 | 390,000 | 670,000 |
スケールアウト - OSS クラスター ポリシー
| インスタンス | 容量 2 | 容量 4 | 容量 6 |
|---|---|---|---|
| E10 | 1,000,000 | 1,900,000 | 2,500,000 |
| E20 | 900,000 | 1,700,000 | 2,300,000 |
| E50 | 1,700,000 | 3,000,000 | 3,900,000 |
| E100 | 2,500,000 | 4,400,000 | 4,900,000 |
| インスタンス | 容量 3 | 容量 9 |
|---|---|---|
| F300 | 1,200,000 | 2,600,000 |
| F700 | 1,200,000 | 2,600,000 |
| F1500 | 1,100,000 | 2,800,000 |