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