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

• redis-benchmark.exe を使用して、Redis サーバーの負荷テストを行います。 独自のパフォーマンステストを作成する前に、redis-benchmark.exe を使用してスループットの目安を確認してください。
• redis-cli を使用して、INFO コマンドを使用してキャッシュを監視します。 Redis ツールのダウンロード手順については、「Redis コマンドを実行する方法」を参照してください。
• キャッシュ インスタンスでトランスポート層セキュリティ/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 の virtual Receive-side Scaling」を参照してください。
• キャッシュ診断の有効化によってキャッシュの正常性を監視できるようにします。 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 つの最小スレッドを許可するように構成されていることを示しています。 この場合、6 > 4 であるため、クライアントでは 500 ミリ秒の遅延が 2 回発生する可能性があります。

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 setting を使用して指定することも可能です。Machine.config は通常、%SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\ にあります。

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

関連コンテンツ

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