パフォーマンス テスト

  • [アーティクル]

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

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

redis-benchmark ユーティリティの使用方法

  1. テストに使用できるクライアント VM に、オープンソース Redis サーバーをインストールします。 redis-benchmark ユーティリティは、オープンソース Redis ディストリビューションに組み込まれています。 オープンソース イメージをインストールする方法については、Redis のドキュメントを参照してください。

  2. テストに使用するクライアント VM は、Azure Cache for Redis インスタンスと "同じリージョン内に" ある必要があります。

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

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

  5. キャッシュ インスタンスで TLS/SSL を使用する場合は、redis-benchmark コマンドに --tls パラメーターを追加するか、stunnel などのプロキシを使用する必要があります。

  6. Redis-benchmark では、既定でポート 6379 を使用します。 -p パラメーターを使用して、この設定をオーバーライドします。 SSL/TLS (ポート 6380) を使用する場合、または Enterprise レベル (ポート 10000) を使用する場合は、-p を使用する必要があります。

  7. クラスタリングを使用する Azure Cache for Redis インスタンスを使用する場合は、redis-benchmark コマンドに --cluster パラメーターを追加する必要があります。 Enterprise クラスタリング ポリシーを使用する Enterprise レベル キャッシュは、非クラスター化キャッシュとして扱うことができ、この設定は必要ありません。

  8. 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 レベルで特に有用です。 詳細については、Enterprise レベルのベスト プラクティスに関する記事を参照してください。

  • Premium レベルでは、通常、スケールアップの前にスケールアウト (クラスタリング) をお勧めします。 クラスタリングを使用すると、Redis サーバーはデータのシャーディングによって、より多くの vCPU を使用できるようになります。 この場合、シャードを追加するとスループットがほぼ直線的に増加するはずです。

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 を使用しました。 スループットの数値は、GET コマンドについてのみ示しています。 通常、SET コマンドのスループットは低くなります。 これらの数値はスループット用に最適化されています。 許容できる待機時間の条件下での実際のスループットは低くなる可能性があります。

次の構成は、Basic、Standard、Premium レベルのスループットをベンチマークするために使用されました。

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

注意事項

これらの値は保証されるものではなく、これらの数値に対する SLA もありません。 ご使用のアプリケーションに適したキャッシュ サイズを判別するために、お客様自身でパフォーマンス テストを実行することを強くお勧めします。 定期的に新しい結果を公表しているため、これらの数字は変わる可能性があります。

重要

Microsoft は、キャッシュ インスタンスで使われる基になる VM を定期的に更新します。 このため、キャッシュごと、およびリージョンごとに、パフォーマンス特性が異なる可能性があります。 このページのベンチマークの例の値は、単一リージョン内の古い世代のキャッシュ ハードウェアを反映しています。 実際には、さらに良い結果や異なる結果になる場合があります。

Standard レベル

インスタンス サイズ 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 レベル

インスタンス サイズ 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 および 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 Tiers - Scaled Out

より大きなキャッシュ サイズへの移行によるスケールアップだけでなく、スケールアウトによってパフォーマンスを向上させることもできます。Enterprise レベルでは、スケールアウトはキャッシュ インスタンスの "容量" の増加と呼ばれます。 既定では、キャッシュ インスタンスの容量は 2 です。これは、プライマリとレプリカのノードを意味します。 容量が 4 の Enterprise キャッシュ インスタンスは、インスタンスが 2 倍にスケールアウトされたことを示します。 スケールアウトすると、より多くのメモリと vCPU にアクセスできるようになります。 各キャッシュ サイズと容量で Redis のコア プロセスによって使用される vCPU 数の詳細については、Enterprise レベルのベスト プラクティスに関するページを参照してください。 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

次の手順