Important
Azure Cache for Redis は、すべての SKU の提供終了タイムラインを発表しました。 できるだけ早く既存の Azure Cache for Redis インスタンスを Azure Managed Redis に移行することをお勧めします。
提供終了の詳細については、以下を参照してください。
再試行コマンド
指数バックオフでコマンドを再試行するようにクライアント接続を構成します。 詳細については、 再試行のガイドラインを参照してください。
回復性をテストする
再起動を使用して、パッチをシミュレートして、接続の中断に対するシステムの回復性をテストします。 パフォーマンスのテストの詳細については、「 パフォーマンス テスト」を参照してください。
Linux でホストされるクライアント アプリケーションの TCP 設定
一部の Linux バージョンの既定の TCP 設定では、Redis サーバー接続が 13 分以上失敗する可能性があります。 既定の設定では、接続が正常に閉じられなかった場合に、クライアント アプリケーションが閉じた接続を検出して自動的に復元できないようにすることができます。
ネットワーク接続が中断された場合や、計画外のメンテナンスのために Redis サーバーがオフラインになった場合に、接続の再確立に失敗する可能性があります。
次の TCP 設定をお勧めします。
| Setting | 価値 |
|---|---|
net.ipv4.tcp_retries2 |
5 |
このシナリオの詳細については、「 Linux で実行しているときに接続が 15 分間再確立されない」を参照してください。 この説明は StackExchange.Redis ライブラリに関する説明ですが、Linux で実行されている他のクライアント ライブラリも影響を受けます。 説明は引き続き役立ち、他のライブラリに一般化できます。
StackExchange.Redis での ForceReconnect の使用
まれに、接続が切断された後、 StackExchange.Redis が再接続に失敗します。 このような場合は、クライアントを再起動するか、新しい ConnectionMultiplexer を作成すると、問題が修正されます。 シングルトン ConnectionMultiplexer パターンを使用して、アプリが定期的に再接続を強制できるようにすることをお勧めします。 アプリケーションで使用するフレームワークとプラットフォームに最適なクイック スタート サンプル プロジェクトを見てみましょう。 このコード パターンの例については、 クイック スタートを参照してください。
ConnectionMultiplexerのユーザーは、古いエラーを破棄した結果として発生する可能性があるObjectDisposedExceptionエラーを処理する必要があります。
ForceReconnectAsync() をRedisConnectionExceptionsおよびRedisSocketExceptionsのために呼び出します。 また、ForceReconnectAsync() に対して RedisTimeoutExceptions を呼び出すこともできます。ただし、豊富な ReconnectMinInterval および ReconnectErrorThreshold を使用している場合に限ります。 そうしないと、新しい接続を確立すると、既に過負荷になっているため、タイムアウトしているサーバーで連鎖エラーが発生する可能性があります。
ASP.NET アプリケーションでは、StackExchange.Redis パッケージを直接使用する代わりに、Microsoft.Extensions.Caching.StackExchangeRedis パッケージの統合実装を使用できます。 StackExchange.Redis を直接使用するのではなく、ASP.NET アプリケーションで Microsoft.Extensions.Caching.StackExchangeRedis を使用している場合は、UseForceReconnect プロパティを true に設定できます。
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
適切なタイムアウトを構成する
接続の回復性では、接続タイムアウトとコマンド タイムアウトという 2 つのタイムアウト値を考慮する必要があります。
接続タイムアウト
connect timeoutは、クライアントが Redis サーバーとの接続の確立を待機する時間です。 5 秒の connect timeout を使用するようにクライアント ライブラリを構成し、より高い CPU 条件下でもシステムが接続するのに十分な時間を確保します。
connection timeout値が小さい場合、その時間枠内に接続が確立されるとは限りません。 問題が発生した場合 (クライアントの CPU 使用率が高い、サーバーの CPU が高いなど)、短い connection timeout 値を指定すると、接続の試行が失敗します。 この動作は、多くの場合、悪い状況を悪化させます。 タイムアウトを短くする代わりに、システムが再接続を試みるプロセスを強制的に再起動することで問題を悪化させ、 接続 -> 失敗 -> 再試行 ループにつながる可能性があります。
コマンドのタイムアウト
ほとんどのクライアント ライブラリには、 command timeoutsのタイムアウト構成がもう 1 つ用意されています。これは、クライアントが Redis サーバーからの応答を待機する時間です。 初期設定は 5 秒未満にすることをお勧めしますが、シナリオとキャッシュに格納される値のサイズに応じて、 command timeout を大きくまたは小さく設定することを検討してください。
command timeoutが小さすぎると、接続が不安定に見える可能性があります。 ただし、 command timeout が大きすぎる場合は、コマンドがタイムアウトになるかどうかを調べるのに長い時間待機する必要があります。
クライアント接続の急増を回避する
接続が失われた後に再接続するときは、多数の接続を同時に作成しないようにします。 接続タイムアウトが短いほど停止が長くなる場合と同様に、同時に多数の再接続試行を開始すると、サーバーの負荷が増加し、すべてのクライアントが正常に再接続するのにかかる時間が長くなる可能性があります。
多数のクライアント インスタンスを再接続する場合は、新しい接続をずらして、接続されているクライアントの数が急激に急増しないようにすることを検討してください。
注
StackExchange.Redis クライアント ライブラリを使用する場合は、接続文字列でabortConnectをfalseに設定します。
ConnectionMultiplexerが再接続を処理できるようにすることをお勧めします。 詳細については、「 StackExchange.Redis の ベスト プラクティス」を参照してください。
残った接続を回避する
キャッシュには、キャッシュ層あたりのクライアント接続数に制限があります。 クライアント アプリケーションが接続を再作成するときに、接続が閉じられ、古い接続が削除されることを確認します。
メンテナンスの事前通知
通知を使用して、今後のメンテナンスについて学習します。 詳細については、「 計画メンテナンスの前に通知を受け取ることができますか」を参照してください。
メンテナンス期間をスケジュールする
メンテナンスに合わせてキャッシュ設定を調整します。 キャッシュへの悪影響を軽減するためのメンテナンス期間の作成の詳細については、「 更新チャネル」および「更新プログラムのスケジュール」を参照してください。
回復性のためのその他の設計パターン
回復性のために設計パターンを適用します。 詳細については、「アプリケーションの 回復性を高める方法」を参照してください。
アイドル タイムアウト
Azure Cache for Redis には、アイドル状態の接続に対して 10 分間のタイムアウトがあります。 10 分間のタイムアウトにより、リークのある接続や、クライアント アプリケーションによって孤立した接続をサーバーで自動的にクリーンアップできます。 ほとんどの Redis クライアント ライブラリには、クライアント アプリケーションからの要求がない場合でも接続が閉じないように、 heartbeat または keepalive コマンドを定期的に送信する機能が組み込まれています。
接続が 10 分間アイドル状態になるリスクがある場合は、 keepalive 間隔を 10 分未満の値に構成します。 アプリケーションで、 keepalive 機能のネイティブ サポートがないクライアント ライブラリを使用している場合は、 PING コマンドを定期的に送信することで、アプリケーションに実装できます。