Azure Cache for Redis のベスト プラクティスBest practices for Azure Cache for Redis

次のベスト プラクティスに従うことにより、Azure Cache for Redis インスタンスを使用するときのパフォーマンスとコスト効率を最大限にできます。By following these best practices, you can help maximize the performance and cost-effective use of your Azure Cache for Redis instance.

構成と概念Configuration and concepts

  • 実稼働システムでは Standard レベルまたは Premium レベルを使用します。Use Standard or Premium tier for production systems. Basic レベルは単一ノード システムであり、データ レプリケーション機能や SLA がありません。The Basic tier is a single node system with no data replication and no SLA. また、C1 以上のキャッシュを使用してください。Also, use at least a C1 cache. C0 キャッシュは、共有 CPU コアを使用し、メモリ量が少なく、"迷惑な隣人" の問題が発生する可能性が高いため、単純な開発/テストのシナリオに向いています。C0 caches are meant for simple dev/test scenarios since they have a shared CPU core, little memory, and are prone to "noisy neighbor" issues.

  • Redis がインメモリ データ ストアであることに注意します。Remember that Redis is an in-memory data store. この記事で、データ損失が発生する可能性のあるいくつかのシナリオについて説明しています。This article outlines some scenarios where data loss can occur.

  • 修正プログラムの適用やフェールオーバーによる接続の中断に対応できるようにシステムを開発しますDevelop your system such that it can handle connection blips because of patching and failover.

  • メモリの負荷が高い状況下での システムの応答性を向上させるように maxmemory-reserved の設定を構成しますConfigure your maxmemory-reserved setting to improve system responsiveness under memory pressure conditions. 書き込み負荷の高いワークロードにとって、または Redis に大きい値 (100 KB 以上) を格納している場合は特に、十分な予約設定にすることが重要です。A sufficient reservation setting is especially important for write-heavy workloads or if you're storing larger values (100 KB or more) in Redis. キャッシュのサイズの 10% から始めて、書き込みが多い場合はその割合を増やすようにします。You should start with 10% of the size of your cache and increase this percentage if you have write-heavy loads.

  • 値が小さいほど Redis のパフォーマンスは向上する ため、大きいデータを複数のキーに分割することを検討します。Redis works best with smaller values, so consider chopping up bigger data into multiple keys. Redis に関するこちらのディスカッションでは、慎重に検討する必要があるいくつかの考慮事項を示しています。In this Redis discussion, some considerations are listed that you should consider carefully. 値が大きい場合に生じる可能性のある問題の例については、 こちらの記事 を参照してください。Read this article for an example problem that can be caused by large values.

  • キャッシュ インスタンスとアプリケーションを同じリージョンに配置します。Locate your cache instance and your application in the same region. 別のリージョンにあるキャッシュに接続すると、待ち時間が大幅に増加して、信頼性が低下します。Connecting to a cache in a different region can significantly increase latency and reduce reliability. Azure の外部から接続することはできますが、これは、特に Redis をキャッシュとして使用しているときには お勧めできません。While you can connect from outside of Azure, it not recommended especially when using Redis as a cache. Redis を単なるキー/値ストアとして使用している場合は、待ち時間は一番の問題ではない可能性があります。If you're using Redis as just a key/value store, latency may not be the primary concern.

  • 接続を再利用します。Reuse connections. 新しい接続を作成すると費用がかかり、待ち時間が増加するため、接続はできる限り再利用します。Creating new connections is expensive and increases latency, so reuse connections as much as possible. 新しい接続を作成することを選択する場合は、(.NET や Java のようなマネージド メモリ言語でも) 必ず古い接続を閉じてから解放するようにしてください。If you choose to create new connections, make sure to close the old connections before you release them (even in managed memory languages like .NET or Java).

  • パイプライン処理を使用します。Use pipelining. ネットワークを最も効率的に使用して最高のスループットを実現するために、Redis パイプライン処理をサポートする Redis クライアントを選択してみてください。Try to choose a Redis client that supports Redis pipelining in order to make most efficient use of the network to get the best throughput you can.

  • 少なくとも 15 秒間の 接続タイムアウト を使用するようにクライアント ライブラリを構成します。 これにより、CPU 使用率が高い状況下でも、システムに接続するための時間を提供します。Configure your client library to use a connect timeout of at least 15 seconds, giving the system time to connect even under higher CPU conditions. タイムアウト値が小さいと、その時間内での接続の確立が保証されません。A small connection timeout value doesn't guarantee that the connection is established in that time frame. 何らかの問題 (高いクライアント CPU 使用率、高いサーバー CPU 使用率など) がある場合、接続タイムアウト値が短いと、接続試行が失敗することになります。If something goes wrong (high client CPU, high server CPU, and so on), then a short connection timeout value will cause the connection attempt to fail. この動作は、多くの場合、悪い状況をさらに悪化させます。This behavior often makes a bad situation worse. タイムアウトを短くすると、役に立つ代わりに、システムに強制的に再接続試行プロセスを再開させることにより "接続 -> 失敗 -> 再試行" のループに陥る可能性があり、問題が悪化します。Instead of helping, shorter timeouts aggravate the problem by forcing the system to restart the process of trying to reconnect, which can lead to a connect -> fail -> retry loop. 一般的に、接続タイムアウトは 15 秒以上にしておくことをお勧めしています。We generally recommend that you leave your connection Timeout at 15 seconds or higher. 短時間で失敗させて結局再試行させるよりも、15 秒または 20 秒後に接続試行を成功させることをお勧めします。It's better to let your connection attempt succeed after 15 or 20 seconds than to have it fail quickly only to retry. そのような再試行ループでは、最初からシステムに時間をかけさせた場合よりも、停止時間が長く続く可能性があります。Such a retry loop can cause your outage to last longer than if you let the system just take longer initially.

    注意

    このガイダンスは、接続試行 に固有のものであり、GET や SET などの 操作 が終了するのを待つ時間とは関係ありません。This guidance is specific to the connection attempt and not related to the time you're willing to wait for an operation like GET or SET to complete.

  • コストの高い操作を避けます - 一部の Redis 操作 (KEYS コマンドなど) は、"非常に" コストが高く、避ける必要があります。Avoid expensive operations - Some Redis operations, like the KEYS command, are very expensive and should be avoided. 詳細については、実行時間の長いコマンドに関連したいくつかの考慮事項を参照してください。For more information, see some considerations around long-running commands

  • TLS 暗号化を使用します - Azure Cache for Redis の既定では、TLS で暗号化された通信が必要です。Use TLS encryption - Azure Cache for Redis requires TLS encrypted communications by default. 現在、TLS バージョン 1.0、1.1、および 1.2 がサポートされています。TLS versions 1.0, 1.1 and 1.2 are currently supported. ただし、TLS 1.0 と 1.1 は業界全体で非推奨になる予定であるため、可能であれば TLS 1.2 を使用してください。However, TLS 1.0 and 1.1 are on a path to deprecation industry-wide, so use TLS 1.2 if at all possible. お使いのクライアント ライブラリまたはツールで TLS がサポートされていない場合は、Azure portal または管理 API を使用して、暗号化されていない接続を有効にすることができます。If your client library or tool doesn't support TLS, then enabling unencrypted connections can be done through the Azure portal or management APIs. 暗号化された接続ができない場合は、キャッシュとクライアント アプリケーションを仮想ネットワークに配置することをお勧めします。In such cases where encrypted connections aren't possible, placing your cache and client application into a virtual network would be recommended. 仮想ネットワーク キャッシュ シナリオで使用されるポートの詳細については、こちらのを参照してください。For more information about which ports are used in the virtual network cache scenario, see this table.

  • アイドル タイムアウト - 現時点では、Azure Redis の接続のアイドル タイムアウトは 10 分間であるため、これは 10 分未満に設定する必要があります。Idle Timeout - Azure Redis currently has 10 minute idle timeout for connections, so this should be set to less than 10 minutes.

メモリ管理Memory management

Redis サーバー インスタンス内でのメモリ使用量に関連したいくつかの考慮すべき事項があります。There are several things related to memory usage within your Redis server instance that you may want to consider. いくつかの例を次に示します。Here are a few:

  • お使いのアプリケーションで機能する 削除ポリシーを選択します。Choose an eviction policy that works for your application. Azure Redis の既定のポリシーは volatile-lru です。これは、TTL 値が設定されているキーのみが削除対象となることを意味します。The default policy for Azure Redis is volatile-lru, which means that only keys that have a TTL value set will be eligible for eviction. TTL 値を持つキーがない場合は、システムはどのキーも削除しません。If no keys have a TTL value, then the system won't evict any keys. メモリー不足のときに任意のキーをシステムに削除させるようにする場合は、allkeys-lru ポリシーを検討することができます。If you want the system to allow any key to be evicted if under memory pressure, then you may want to consider the allkeys-lru policy.

  • キーに有効期限値を設定します。Set an expiration value on your keys. 有効期限が切れると、メモリ負荷が発生するまで待たずに、事前にキーが削除されます。An expiration will remove keys proactively instead of waiting until there's memory pressure. メモリー不足のために削除が開始される場合、サーバーに追加の負荷が生じる可能性があります。When eviction does kick in because of memory pressure, it can cause additional load on your server. 詳細については、EXPIRE コマンドと EXPIREAT コマンドに関するドキュメントを参照してください。For more information, see the documentation for the EXPIRE and EXPIREAT commands.

クライアント ライブラリ固有のガイダンスClient library specific guidance

再試行を実行するのに安全なタイミングとはWhen is it safe to retry?

残念ながら、答えは簡単ではありません。Unfortunately, there's no easy answer. 各アプリケーションが、どの操作を再試行でき、どれをできないかを決定する必要があります。Each application needs to decide what operations can be retried and which can't. 各操作には、さまざまな要件とキー間の依存関係があります。Each operation has different requirements and inter-key dependencies. いつくかの考慮事項を次に示します。Here are some things you might consider:

  • ユーザーが実行するよう要求したコマンドを Redis が正常に実行したとしても、クライアント側のエラーを受け取る場合があります。You can get client-side errors even though Redis successfully ran the command you asked it to run. 次に例を示します。For example:
    • タイムアウトは、クライアント側の概念です。Timeouts are a client-side concept. 操作がサーバーに到達すると、クライアントが待機するのをあきらめても、サーバーはコマンドを実行します。If the operation reached the server, the server will run the command even if the client gives up waiting.
    • ソケット接続でエラーが発生した場合、操作が実際にサーバーで実行されたかどうかを知ることは不可能です。When an error occurs on the socket connection, it's not possible to know if the operation actually ran on the server. たとえば、サーバーが要求を処理した後、クライアントが応答を受信する前に、接続エラーが発生する可能性があります。For example, the connection error can happen after the server processed the request but before the client receives the response.
  • 同じ操作を誤って 2 回実行した場合、アプリケーションはどのように反応するでしょうか。How does my application react if I accidentally run the same operation twice? たとえば、整数を 1 回でなく 2 回増分した場合、どうなるでしょうか。For instance, what if I increment an integer twice instead of once? アプリケーションは、複数の場所から同じキーに書き込みますか。Is my application writing to the same key from multiple places? 再試行ロジックが、アプリの他の部分によって設定された値を上書きしたらどうなるでしょうか。What if my retry logic overwrites a value set by some other part of my app?

エラー条件の下でコードがどのように動作するかをテストしたい場合は、再起動機能を使用することを検討してください。If you would like to test how your code works under error conditions, consider using the Reboot feature. 再起動により、接続の中断がアプリケーションにどのような影響を及ぼすかを確認できます。Rebooting allows you to see how connection blips affect your application.

パフォーマンス テストPerformance testing

  • 独自のパフォーマンス テストを作成する前に、 redis-benchmark.exe の使用から開始して、考えられるスループット/待機時間の感触をつかんでください。Start by using redis-benchmark.exe to get a feel for possible throughput/latency before writing your own perf tests. Redis ベンチマークのドキュメントは、こちらにありますRedis-benchmark documentation can be found here. Redis のベンチマークでは TLS はサポートされないため、テストを行う前に、ポータルで TLS 以外のポートを有効にする必要があります。Note that redis-benchmark doesn't support TLS, so you'll have to enable the Non-TLS port through the Portal before you run the test. redis-benchmark.exe の Windows 互換バージョンはこちらにありますA windows compatible version of redis-benchmark.exe can be found here

  • テストに使用するクライアント VM は、Redis Cache インスタンスと 同じリージョン内 にある必要があります。The client VM used for testing should be in the same region as your Redis cache instance.

  • Dv2 VM シリーズ はハードウェアが強力であり、最良の結果が得られるため、クライアントにはこれらを使用することをお勧めします。We recommend using Dv2 VM Series for your client as they have better hardware and will give the best results.

  • 使用するクライアント VM が、テストするキャッシュと *少なくとも同等のコンピューティングと帯域幅 を持っていることを確認してください。Make sure the client VM you use has *at least as much compute and bandwidth as the cache being tested.

  • フェールオーバーの状態のキャッシュでテスト します。Test under failover conditions on your cache. 安定した状態でのみキャッシュのパフォーマンス テストを行わないようにすることが重要です。It's important to ensure that you don't performance test your cache only under steady state conditions. また、フェールオーバーの状態でテストし、その間のキャッシュの CPU またはサーバーの負荷を測定します。Also test under failover conditions and measure the CPU / Server Load on your cache during that time. フェールオーバーを開始するには、プライマリ ノードを再起動します。You can initiate a failover by rebooting the primary node. これにより、フェールオーバー状態 (更新中に発生し、計画外のイベント中に発生する可能性があります) でのスループットと待機時間の観点からアプリケーションがどのように動作するかを確認できます。This will allow you to see how your application behaves in terms of throughput and latency during failover conditions (happens during updates and can happen during an unplanned event). パフォーマンスに影響する可能性があるため、フェールオーバー中であっても、CPU またはサーバーの負荷ピークが 80% を超えないようにすることをお勧めします。Ideally you dont't want to see CPU / Server Load peak to more than say 80% even during a failover as that can affect performance.

  • 一部のキャッシュ サイズ は、4 つ以上のコアを持つ VM でホストされます。Some cache sizes are hosted on VMs with 4 or more cores. これは、TLS の暗号化/暗号化解除だけでなく、TLS の接続/切断ワークロードを複数のコアに分散して、キャッシュ VM の全体的な CPU 使用率を下げるのにも役立ちます。This is useful to distribute the TLS encryption / decryption as well as TLS connection / disconnection workloads across multiple cores to bring down overall CPU usage on the cache VMs. VM のサイズとコアの詳細については、こちらを参照してください。See here for details around VM sizes and cores

  • Windows を使用している場合は、クライアント コンピューターで VRSS を有効 にしてください。Enable VRSS on the client machine if you are on Windows. 詳細についてはこちらをご覧くださいSee here for details. Powershell スクリプトの例:Example PowerShell script:

    PowerShell -ExecutionPolicy Unrestricted Enable-NetAdapterRSS -Name ( Get-NetAdapter).NamePowerShell -ExecutionPolicy Unrestricted Enable-NetAdapterRSS -Name ( Get-NetAdapter).Name

  • Premium レベルの Redis インスタンスを使用することを検討してくださいConsider using Premium tier Redis instances. これらのキャッシュ サイズでは、Redis インスタンスは CPU およびネットワークの両方が優れたハードウェアで実行されるため、ネットワーク待ち時間とスループットが改善します。These cache sizes will have better network latency and throughput because they're running on better hardware for both CPU and Network.

    注意

    参照用として、当社で観測したパフォーマンス結果をこちらに公開しています。Our observed performance results are published here for your reference. また、SSL/TLS では幾分かのオーバーヘッドが追加されるため、トランスポートの暗号化を使用している場合は、待ち時間とスループット、またはそのいずれかが異なる可能性があることに注意してください。Also, be aware that SSL/TLS adds some overhead, so you may get different latencies and/or throughput if you're using transport encryption.

Redis ベンチマークの例Redis-Benchmark examples

テスト前のセットアップ:以下に一覧表示されている待ち時間とスループットのテスト コマンドに必要なデータでキャッシュ インスタンスを準備します。Pre-test setup: Prepare the cache instance with data required for the latency and throughput testing commands listed below.

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024

待機時間をテストするには:1K のペイロードを使用して GET 要求をテストします。To test latency: Test GET requests using a 1k payload.

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

スループットをテストするには: 1K のペイロードを使用してパイプラインされた GET 要求。To test throughput: Pipelined GET requests with 1k payload.

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