Azure Cache for Redis のサーバー負荷を管理する
値のサイズ
クライアント アプリケーションの設計によって、多数の小さな値を格納したほうがよいか、少数のより大きな値を格納したほうがよいかが決まります。 Redis サーバーの観点からは、値が小さいほど、パフォーマンスは向上します。 値のサイズは 100 kB 未満にしておくことをお勧めします。
設計上、Azure Cache for Redis に大きな値を格納する必要がある場合は、サーバーの負荷が高くなります。 このケースでは、CPU の使用によってスループットが制限されないように、より高いキャッシュ層を使用する必要がある場合があります。
キャッシュに十分な CPU 容量がある場合でも、より大きな値を指定すると待ち時間が長くなってしまうため、「適切なタイムアウトを設定する」のガイダンスに従ってください。
また、値を大きくすると、メモリが断片化される可能性も高くなるため、「[maxmemory-reserved] の設定を構成する」のガイダンスに従ってください。
クライアント接続のスパイクを回避する
接続を作成することと閉じることは、Redis サーバーにとってコストのかかる操作です。 クライアント アプリケーションで短時間のうちに作成または閉じられる接続の数が多すぎると、Redis サーバーの負担になる可能性があります。
多数のクライアント インスタンスをインスタンス化して、一度に Redis に接続する場合は、接続されたクライアントの数が急増するのを防ぐために、新しい接続の作成をずらすことを検討してください。
メモリ不足
サーバーのメモリ使用率が高いと、システムでデータをディスクにページングする必要が生じ、ページ フォールトによってシステムの処理速度が大幅に低下するおそれがあります。
実行時間の長いコマンドを回避する
Redis サーバーはシングル スレッド システムです。 実行時間の長いコマンドは、クライアント側で待ち時間やタイムアウトが発生する原因となります。これは、サーバーで実行時間の長いコマンドを処理している間に他の要求に応答できないためです。 詳細については、「Azure Cache for Redis のサーバー側の問題に関するトラブルシューティング」を参照してください。
サーバーの負荷を監視する
サーバーの負荷を監視する機能を追加して、サーバーの負荷が高いときに通知を受け取ることができるようにします。 監視することは、アプリケーションの制約を理解するのに役立ちます。 その後、問題を軽減するために事前に対処することができます。 パフォーマンスに悪影響が生じるのを防ぐために、サーバーの負荷を 80% 未満にしておくことをお勧めします。 サーバーの負荷が 80% を超える場合、計画されていないフェールオーバーが発生する可能性があります。 現時点では、Azure cache For Redis は、ポータルの左側にある [リソース] メニューの [監視] の下にあるインサイトの 2 つのメトリック (CPU とサーバーの負荷) を公開しています。 サーバーの負荷を監視する際には、各メトリックで測定される内容を理解することが重要です。
CPUメトリックは、キャッシュをホストしているノードの CPU 使用率を示します。 CPU メトリックには、厳密には Redis サーバープロセスではないプロセスも含まれます。 CPU には、マルウェア対策などのバックグラウンド プロセスが含まれます。 その結果、CPU メトリックが急増することがあり、Redis サーバーの CPU 使用率を正確に示すものではない可能性があります。
サーバー負荷メトリックは、Redis サーバーだけの負荷を表します。 CPU ではなく、サーバー負荷メトリックを監視することをお勧めします。
サーバーの負荷を監視する場合は、短いスパイクでもフェールオーバーとコマンドのタイムアウトがトリガーされる可能性があるため、平均ではなく、サーバー負荷の最大スパイクを調べることをお勧めします。
サーバー メンテナンスを計画する
キャッシュ サーバーのメンテナンス中は、ピーク時の負荷を処理するのに十分なサーバー容量があることを確認します。 ピーク時の負荷の下でノードを再起動して、システムをテストします。 パッチのデプロイをシミュレートする方法の詳細については、「再起動」を参照してください。
フェールオーバー後のサーバー負荷の増加をテストする
Standard と Premium の SKU では、各キャッシュは 2 つのノードでホストされます。 ロード バランサーによってクライアント接続はそれらの 2 つのノードに分散されます。 計画内または計画外のメンテナンスがプライマリ ノードで行われると、そのノードですべてのクライアント接続が終了します。 このような状況では、すべてのクライアント接続が 1 つのノードに対して行われ、残っている 1 つのノードでサーバー負荷が増加する場合があります。 このシナリオをテストするため、プライマリ ノードを再起動し、1 つのノードでもサーバー負荷が高くなりすぎることなく、すべてのクライアント接続を処理できることを確認するようお勧めします。