キャッシュ管理に関する FAQ

• redis-benchmark.exe を使用して、Redis サーバーの負荷テストを行います。 redis-benchmark.exeを使用して、独自のパフォーマンス テストを作成する前に、可能なスループットの感触をつかみます。
• redis-cli を使用して、INFO コマンドを使用してキャッシュを監視します。 Redis ツールのダウンロード手順については、「Redis コマンドを実行する方法」を参照してください。
• キャッシュインスタンスで Transport Layer Security/Secure Socket Layer (TLS/SSL) を使用する場合は、Redis ツールコマンドに --tls パラメータを追加するか、 stunnel などのプロキシを使用して TLS/SSL を有効にします。
• Redis-benchmark デフォルトではポート 6379 を使用します。 キャッシュが SSL/TLS ポート-pまたは Enterprise 層のポート6380を使用している場合、この設定を上書きするには、10000 パラメータを使用します。
• 必要に応じて、ロード テストを実行する前に 、Azure portal を使用して非 TLS ポートを有効にする ことができます。
• テストに使用するクライアント仮想マシン (VM) が、Azure Cache for Redis インスタンスと同じリージョンにあることを確認します。
• クライアント VM に、テストするキャッシュと少なくとも同じ量のコンピューティング機能と帯域幅機能があることを確認します。 最適な結果を得るには、クライアントに D シリーズと E シリーズの VM を使用します。
• Windows を使用している場合は、クライアント コンピューターで Virtual Receive-side Scaling (VRSS) を有効にします。 詳細については、「 Windows Server 2012 R2 の仮想受信側スケーリング」を参照してください。
• キャッシュの正常性を 監視 できるように、キャッシュ診断を有効にします。 Azure portal でメトリックを表示したり、選択したツールを使用して メトリックをダウンロードして確認 したりすることもできます。
• 負荷によってメモリの断片化が進んでいる場合は、より大きなキャッシュ サイズにスケールアップします。

次の例は、 redis-benchmark.exe の使用方法を示しています。 これらのコマンドは、キャッシュと同じリージョンの VM から実行して、正確な結果を得てください。

まず、1k ペイロードを使用してパイプライン化された SET 要求をテストします。

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

SETテストを実行した後、1k ペイロードを使用してパイプライン化された GET リクエストを実行します。

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

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

• <gcServer> 要素
• ガベージコレクションの基礎
• ガベージ コレクションとパフォーマンス

Redis サーバーはトランスポート層セキュリティ (TLS) をネイティブにサポートしていませんが、Azure Cache for Redis は TLS をサポートしています。 TLS をサポートする StackExchange.Redis などのクライアントを使用して Azure Cache for Redis に接続する場合は、TLS を使用します。

キャッシュで TLS を使用する場合は、--tls などの Redis ツールの redis-cli オプションを使用して TLS を有効にする必要があります。 また、 stunnel などのユーティリティを使用して、 Redis プレビュー リリースの ASP.NET セッション状態プロバイダーの発表 に関するブログ記事の指示に従って、ツールを TLS ポートに安全に接続することもできます。

Redis ツールのダウンロード手順については、「Redis コマンドを実行する方法」を参照してください。

• 完了するのに時間がかかる特定の Redis コマンドについては、その結果を完全に理解しないまま使用するのは避けてください。 たとえば、運用環境では KEYS コマンドを実行しないでください。 キーの数によっては、復帰に時間がかかる可能性があります。 Redisは、コマンドを一度に1つずつ処理するシングルスレッドサーバーです。 KEYS コマンドを発行すると、Redis は KEYS コマンドの処理が完了するまで後続のコマンドを処理しません。

  redis.io サイトには、サポートする各操作の時間計算量の詳細があります。 各コマンドを選択して、操作ごとの時間計算量を確認してください。

• 使用するキーのサイズは、シナリオによって異なります。 シナリオでより大きなキーが必要な場合は、 ConnectionTimeoutを調整してから再試行値を調整し、再試行ロジックを調整できます。 Redis サーバーの観点からは、キー値が小さいほどパフォーマンスが向上します。

• これらの考慮事項は、Redis に大きな値を格納できないという意味ではありませんが、待機時間が長くなります。 1 つのデータセットが他のデータセットよりも大きい場合は、複数の ConnectionMultiplexer インスタンスを使用して、それぞれに異なるタイムアウト値と再試行値のセットを設定できます。 詳細については、「 StackExchange.Redis 構成オプションの機能」を参照してください。

各 Azure Cache for Redis の価格レベルには、クライアント接続、メモリ、帯域幅に関する異なる制限があります。 キャッシュの各サイズでは、 最大 である程度の接続が許可されますが、Redis への各接続には関連するオーバーヘッドが伴います。 このようなオーバーヘッドの例としては、TLS/SSL 暗号化による CPU とメモリの使用量があります。

指定したキャッシュ サイズの最大接続数の上限は、負荷が低いキャッシュを想定しています。 接続オーバーヘッドによる負荷 と クライアント操作による負荷がシステムの容量を超えると、現在のキャッシュ サイズの接続制限を超えていない場合でも、キャッシュで容量の問題が発生する可能性があります。

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

• 運用システムには Standard または Premium レベルを使用します。 Basic レベルは、データ レプリケーションやサービス レベル アグリーメント (SLA) がないシングル ノード システムです。 また、本番環境には少なくとも C1 キャッシュを使用します。 通常、C0 キャッシュは単純な開発/テスト シナリオで使用されます。
• Redis は インメモリ データ ストアであり、一部のシナリオではデータ損失が発生する可能性があることに注意してください。 詳細については、「 Azure Cache for Redis でのデータ損失のトラブルシューティング」を参照してください。
• パッチ適用とフェイルオーバーによって発生する接続のブリップを処理できるように、システムを開発します。
• Premium レベルの Azure Redis インスタンスを使用すると、CPU とネットワークの両方に優れたハードウェアを備えているため、ネットワークの待機時間とスループットが向上します。

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

• AbortConnect を false に設定し、ConnectionMultiplexer自動的に再接続します。
• 要求ごとに新しい接続を作成するのではなく、有効期間が長い 1 つの ConnectionMultiplexer インスタンスを使用します。
• 値が小さいほど Redis のパフォーマンスは向上するため、大きなデータは複数のキーに分割することを検討してください。 たとえば、「 Redis の理想的な値のサイズ範囲は何か」では、100 kb は大きいと見なされます。 詳細については、「 より多くのキーとより小さい値を検討する」を参照してください。
• タイムアウトが起こらないように ThreadPool の設定 を構成してください。
• 少なくとも デフォルトの connectTimeout 5 秒を使用します。 この間隔により、StackExchange.Redis は、ネットワークが異常に発生した場合に接続を再確立するのに十分な時間を確保できます。
• 実行するさまざまな操作に関連するパフォーマンス コストに注意してください。 たとえば、 KEYS コマンドは O(n) 操作であるため、使用しないでください。 redis.io サイトには、サポートする各操作の時間の複雑さに関する詳細があります。 各コマンドを選択して、操作ごとの時間計算量を確認してください。

共通言語ランタイム (CLR) ThreadPool には、ワーカーと I/O 完了ポート (IOCP) の 2 種類のスレッドがあります。

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

スレッド プールは、新しいワーカー スレッドまたは I/O 完了スレッドをオンデマンドで提供し、各スレッドの種類の minimum 設定に達するまで調整は行われません。 既定では、スレッドの最小数はシステム上のプロセッサの数に設定されます。

既存のビジー スレッドの数が minimum スレッド数に達すると、ThreadPool は新しいスレッドを挿入する速度を 500 ミリ秒ごとに 1 つのスレッドに調整します。

通常、システムが IOCP スレッドを必要とする作業のバーストを取得した場合、その作業は迅速に処理されます。 ただし、バーストが構成された minimum 設定よりも大きい場合は、ThreadPool が次の 2 つの可能性のいずれかを待機するため、一部の作業の処理に遅延が発生します。

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

基本的に、 Busy スレッドの数が Min スレッドより大きい場合、アプリケーションがネットワーク トラフィックを処理するまでに 500 ミリ秒の遅延が発生します。 また、15 秒以上アイドル状態が続く既存のスレッドはクリーンアップされ、この成長と縮小のサイクルが繰り返される可能性があります。

StackExchange.Redis ビルド 1.0.450 以降のエラー メッセージでは、次の例に示すように ThreadPool 統計が出力されます。

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 つの最小スレッドを許可するように構成されていることを示しています。 この場合、クライアントでは 500 ミリ秒の遅延が 2 回発生する可能性があります (6 ミリ秒 > 4 ミリ秒)。

IOCP スレッドと WORKER スレッドの最小構成値を、既定値より大きい値に設定することをお勧めします。 この値に関する万能のガイダンスはありません。なぜなら、あるアプリケーションの適切な値は、別のアプリケーションにとっては高すぎたり低すぎたりする可能性が高いからです。 この設定は、複雑なアプリケーションの他の部分のパフォーマンスにも影響を与える可能性があります。 この設定は、特定のニーズに合わせて微調整する必要があります。 良い出発点は 200 または 300です。 次に、必要に応じてテストと微調整を行います。

最小スレッド設定を構成する

この設定は、 ThreadPool.SetMinThreads (...) メソッドを使用してプログラムで変更できます。

たとえば、NET Framework では、 メソッドでこの値を Application_Start で設定します。

    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);
    }

.NET Core を使用する場合は、 への呼び出しの直前に WebApplication.CreateBuilder() の値を設定します。

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

また、minIoThreadsの minWorkerThreads 要素の下にある または <processModel>configuration 設定を使用して、最小スレッド設定を指定することもできます。Machine.config は通常、%SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\ にあります。

この方法で最小スレッド数を設定することは、システム全体の設定であるため、お勧めしません。 この方法で最小スレッドを設定する場合は、アプリケーション・プールを再始動する必要があります。

関連コンテンツ

• Azure Cache for Redis に関するその他の FAQ を参照してください。