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 以上) を格納している場合、特に重要です。This setting is especially important for write-heavy workloads or if you're storing larger values (100 KB or more) in Redis. 最初はキャッシュのサイズの 10% を使用し、書き込み負荷が高い場合は割合を増やすことをお勧めします。It's recommended that you start with 10% of the size of your cache and then increase the 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).

  • 少なくとも 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 it is 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 details on which ports are used for

メモリ管理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. これにより、メモリー不足が起こるまで待つのではなく、予防的にキーが削除されます。This will remove keys proactively instead of waiting until there is 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 request is processed by the server but before the response is received by the client.
  • 同じ操作を誤って 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 just 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. これにより、接続の中断がアプリケーションにどのような影響を及ぼすかを確認できます。This 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 のベンチマークでは SSL はサポートされないため、テストを行う前に、ポータルで非 SSL ポートを有効にする必要があります。Note that redis-benchmark doesn't support SSL, so you'll have to enable the Non-SSL 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.

  • 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: This will prepare the cache instance with data required for the latency and throughput testing commands listed below.

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

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

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

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

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