Azure Cache for Redis 管理に関してよくあるご質問

TLS は、Redis サーバーではネイティブにサポートされませんが、Azure Cache for Redis ではサポートされます。 Azure Cache for Redis に接続しようとしていて、クライアントが StackExchange.Redis のように TLS をサポートしている場合は、TLS を使用します。

redis-cli などの Redis ツールは TLS ポートを使用できません。ただし、stunnel などのユーティリティを使用すると、ツールを TLS ポートに安全に接続することができます。詳細については、Redis のプレビュー リリース用の ASP.NET セッション状態プロバイダーの発表に関するブログ記事を参照してください。

Redis ツールのダウンロードの詳細については、「 Redis コマンドの実行方法 」セクションを参照してください。

• StackExchange.Redis のベスト プラクティス
• 構成と概念
• パフォーマンス テスト

StackExchange.Redis のベスト プラクティス

• AbortConnect を "false" に設定してから、ConnectionMultiplexer による自動再接続を待ってください。
• 要求ごとに新しい接続を作成するのではなく、有効期間が長い 1 つの ConnectionMultiplexer インスタンスを使用します。 接続を管理する方法の例については、「Redisconnection を使用してキャッシュに接続する」の RedisConnection クラスを参照してください。
• 値が小さいほど Redis のパフォーマンスは向上するため、大きなデータは複数のキーに分割することを検討してください。 この Redis に関する議論では、100 KB は大きいと見なされています。 詳しくは、開発のベスト プラクティスに関するセクションをご覧ください。
• タイムアウトが起こらないように ThreadPool の設定 を構成してください。
• connectTimeout については既定の 5 秒以上を使用してください。 この間隔により、ネットワーク ブリップが発生した場合に接続を再確立するための十分な時間が StackExchange.Redis に与えられます。
• 実行中のさまざまな操作に関連するパフォーマンス コストを把握してください。 たとえば、 KEYS コマンドは O(n) 操作であるため、使用しないでください。 redis.io のサイト に、Redis でサポートされる各操作の時間計算量の詳細が記載されています。 各コマンドを選択して、操作ごとの時間計算量を確認してください。

構成と概念

• 実稼働システムでは Standard レベルまたは Premium レベルを使用する。 Basic レベルは単一ノード システムであり、データ レプリケーション機能や SLA がありません。 また、C1 以上のキャッシュを使用してください。 通常、C0 キャッシュは単純な開発/テスト シナリオで使用されます。
• Redis は インメモリ データ ストアであることに注意してください。 詳細については、「Azure Cache for Redis でのデータ損失のトラブルシューティング」を参照して、データ損失が発生する可能性があるシナリオを確認してください。
• 修正プログラムの適用やフェールオーバーが原因の接続の中断に対応できるようなシステムを開発する。

パフォーマンス テスト

• 独自のパフォーマンス テストを作成する前に、 redis-benchmark.exe を使用して実現可能なスループットを確認してください。 redis-benchmark では TLS はサポートされていないため、テストを実行する前に、Azure portal で非 TLS ポートを有効にする必要があります。 例については、「 キャッシュのベンチマークを実行およびテストする方法
• テストに使用するクライアント VM は、Azure Cache for Redis インスタンスと同じリージョンにある必要があります。
• Dv2 VM シリーズはハードウェアが強力であり、最良の結果が得られるため、クライアントにはこれらのシリーズを使用することをお勧めします。
• 選択するクライアント VM に、テスト対象のキャッシュと同等以上のコンピューティング能力と帯域幅がであることを確認します。
• Windows を使用している場合は、クライアント コンピューターで VRSS を有効にしてください。 詳細についてはこちらをご覧ください。
• Premium レベルでは、CPU とネットワークの両方が優れたハードウェアで Redis インスタンスが実行されるため、ネットワーク待機時間とスループットが向上します。

• 完了するのに時間がかかる特定の Redis コマンドについては、その結果を完全に理解しないまま使用するのは避けてください。 たとえば、運用環境では KEYS コマンドを実行しないでください。 キーの数によっては、復帰に時間がかかる可能性があります。 Redis はシングル スレッド サーバーであり、一度に 1 つずつコマンドを処理します。 KEYS の後で他のコマンドを発行した場合、それらのコマンドは Redis によって KEYS コマンドが処理されるまで処理されません。 redis.io のサイト に、Redis でサポートされる各操作の時間計算量の詳細が記載されています。 各コマンドを選択して、操作ごとの時間計算量を確認してください。
• キー サイズ - 小さなキー/値と大きなキー/値のどちらを使用するか。 これはシナリオによって異なります。 ご利用のシナリオで、より大きなキーが必要な場合は、ConnectionTimeout を調整してから、値を再度試して再試行ロジックを調整することができます。 Redis サーバーの観点からは、値が小さいほど、パフォーマンスは向上します。
• これらの考慮事項は、サイズの大きな値を Redis に格納できないという意味ではありません。次の点を考慮する必要があります。 待機時間は長くなります。 サイズの大きなデータ セットとサイズの小さなデータ セットがある場合は、複数の ConnectionMultiplexer インスタンスを使用できます。 前の「StackExchange.Redis 構成オプションについて」で説明したように、それぞれにタイムアウト値と再試行回数の異なるセットを構成します。

• キャッシュ診断の有効化によってキャッシュの正常性を監視できるようにします。 Azure Portal でメトリックを表示できますが、任意のツールを使用して、メトリックを ダウンロードして確認 することも可能です。
• redis-benchmark.exe を使用して Redis サーバーのロード テストを実行できます。
• ロード テスト用のクライアントと Azure Cache for Redis が同じリージョン内にあることを確認します。
• redis-cli.exe を使用し、INFO コマンドを使用してキャッシュを監視します。
• 負荷が高いことが原因でメモリの断片化が発生している場合は、キャッシュのサイズをスケール アップする必要があります。
• Redis ツールのダウンロードの詳細については、「 Redis コマンドの実行方法 」セクションを参照してください。

ここでは、redis-benchmark.exe の使用例をいくつか紹介します。 正確な結果を得るため、これらのコマンドはキャッシュと同じリージョンにある VM で実行してください。cache-development-faq.yml

• 1 k ペイロードを使用してパイプライン SET 要求をテストする

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

• 1 k ペイロードを使用してパイプライン GET 要求をテストする。

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

CLR ThreadPool には、"Worker" スレッドと "I/O Completion Port" (IOCP) スレッドの 2 種類があります。

• Task.Run(…) メソッドや ThreadPool.QueueUserWorkItem(…) メソッドの処理などには、Worker スレッドが使用されます。 これらのスレッドは、バック グラウンド スレッドで作業が発生する必要がある場合に、CLR でさまざまなコンポーネントによっても使用されます。
• IOCP スレッドは、ネットワークからの読み取りの場合など、非同期 IO が発生する場合に使用されます。

スレッド プールは、各種のスレッドについて「最小」設定に達するまで、新しい worker スレッドまたは I/O 完了スレッドをオンデマンドで (スロットルなしで) 提供します。 既定では、スレッドの最小数はシステム上のプロセッサの数に設定されます。

既存の (ビジー) スレッドの数がスレッドの "最小" 数に達すると、ThreadPool は新しいスレッドを挿入する速度を、500 ミリ秒ごとに 1 スレッドへとスロットルします。 通常、ご利用のシステムで、IOCP スレッドを必要とする作業のバーストが取得された場合、その作業は高速に処理されます。 ただし、バーストが構成済みの "最小" 設定を超えた場合は、次の 2 つの可能性のどちらかで ThreadPool が待機するので、多少の遅延が生じます。

• 既存のスレッドの 1 つが空き状態になり、作業を処理する。
• 既存のスレッドが 500 ミリ秒間空き状態にならずに、新しいスレッドが作成される。

基本的に、ビジー スレッド数が最小スレッド数より大きい場合、ネットワーク トラフィックがアプリケーションによって処理される前に 500 ミリ秒の遅延が生じる可能性があります。 また、既存のスレッドが 15 秒より長くアイドル状態になると、そのスレッドはクリーンアップされ、拡大と縮小のこのサイクルが繰り返されることがあります。

StackExchange.Redis (ビルド 1.0.450 以降) からのエラー メッセージの例を見れば、ThreadPool の統計情報が出力されていることがわかります。 IOCP と WORKER に関する下記の詳細を参照してください。

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

例で示されているように、IOCP スレッドについて、6 つのビジー スレッドが存在し、システムは 4 つの最小スレッドを許容するように構成されていることがわかります。 この場合、6 > 4 であることから、クライアントでは 500 ミリ秒の遅延を 2 回検出している可能性があります。

推奨

この情報に基づき、顧客が IOCP スレッドと WORKER スレッドの最小構成値を既定値よりも大きく設定することを強くお勧めします。 あるアプリケーションでは適切な値であっても別のアプリケーションで高すぎたり低すぎたりする可能性があるため、これをどのような値にする必要があるかについて画一的なガイダンスを提供することはできません。 この設定は複雑なアプリケーションの他の部分のパフォーマンスにも影響を与える可能性があるので、各顧客は特定のニーズに合わせてこの設定を調整する必要があります。 適切な値として、まず 200 または 300 に設定し、テストして必要に応じて調整します。

この設定を構成する方法

• この設定は、global.asax.cs 内の ThreadPool.SetMinThreads (...) メソッドを使用してプログラムによって変更することをお勧めします。 次に例を示します。

  private readonly int minThreads = 200;
  void Application_Start(object sender, EventArgs e)
  {
      // Code that runs on application startup
      AreaRegistration.RegisterAllAreas();
      RouteConfig.RegisterRoutes(RouteTable.Routes);
      BundleConfig.RegisterBundles(BundleTable.Bundles);
      ThreadPool.SetMinThreads(minThreads, minThreads);
  }
  

  注意

  このメソッドによって指定された値はグローバル設定であり、AppDomain 全体に影響を与えます。 たとえば、4 コア マシンがあり、実行時の minWorkerThreads および minIoThreads を CPU あたり 50 に設定したい場合は、ThreadPool.SetMinThreads(200, 200) を使用します。

• 最小スレッド数の設定は、Machine.config 内の <processModel> 構成要素の下にある minIoThreads または minWorkerThreads 構成設定を使用して指定することもできます。 通常、Machine.config は %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\ にあります。 この方法で最小スレッド数を設定することはお勧めできません。これはシステム全体の設定だからです。

  Note

  この構成要素で指定される値は、 "コアごと" の設定となります。 たとえば、4 コア マシンをお持ちの場合で、実行時の minIoThreads 設定を 200 にしたい場合は、<processModel minIoThreads="50"/> を使用します。

StackExchange.Redis を使用するときにサーバー GC を有効にすると、クライアントが最適化され、パフォーマンスとスループットを向上させることができます。 サーバー GC とそれを有効にする方法の詳細については、次の記事を参照してください。

• サーバー GC を有効にするには
• ガベージ コレクションの基礎
• ガベージ コレクションとパフォーマンス

各価格レベルには、クライアント接続、メモリ、および帯域幅についてさまざまな制限があります。 各キャッシュのサイズがあるの接続数 "まで" 許容される一方で、Redis への各接続はそれにオーバーヘッドが関連付けられています。 このようなオーバーヘッドの例には、TLS/SSL 暗号化による CPU とメモリの使用量があります。 指定したキャッシュ サイズの最大接続数の上限は、負荷が低いキャッシュを想定しています。 接続オーバーヘッドからの読み込みに "加えて"、クライアントの操作からの読み込みがシステムの容量を超える場合、現在のキャッシュ サイズが接続数の上限を超えていない場合でも、キャッシュ容量の問題が発生する可能性があります。

各レベルの異なる接続制限について詳しくは、Azure Cache for Redis の価格についてのページを参照してください。 接続と他の既定の構成について詳しくは、「既定の Redis サーバー構成」をご覧ください。

次のステップ

その他の Azure Cache for Redis のよくあるご質問について。