ElastiCache for Redis を使用する場合の高レイテンシー問題のトラブルシューティング方法を教えてください。

所要時間2分

Amazon ElastiCache for Redis を使用する場合の高レイテンシー問題のトラブルシューティング方法を教えてください。

簡単な説明

ElastiCache for Redis においてレイテンシーの増大またはタイムアウトの問題が発生する一般的な理由は次のとおりです。

遅いコマンドによるレイテンシー
メモリ使用量が多いことによるスワッピングの増加
ネットワークの問題によるレイテンシー
クライアント側のレイテンシーの問題
ElastiCache クラスターのイベント

解決方法

遅いコマンドによるレイテンシー

Redis はほとんどがシングルスレッドです。そのため、リクエストの処理が遅い場合、他のすべてのクライアントは処理されるまで待機しなければなりません。この待機により、コマンドの待ち時間が長くなります。Redis コマンドには、Big O 記法を使用して定義された時間計算量もあります。

ElastiCache が提供する Amazon CloudWatch メトリクスを使用して、様々なコマンドクラスの平均レイテンシーをモニタリングします。一般的な Redis 操作はマイクロ秒のレイテンシーで計算されることに注意することが重要です。CloudWatch メトリクスは 1 分ごとにサンプリングされ、レイテンシーメトリックスには複数のコマンドの集計が表示されます。そのため、メトリックグラフに大きな変化が示されなくても、1 つのコマンドでタイムアウトなどの予期しない結果が生じる可能性があります。このような場合は、SLOWLOG コマンドを使用して、完了までに時間がかかっているコマンドを特定します。クラスターに接続し、redis-cli で slowlog get 128 コマンドを実行してリストを取得します。詳細については、「ElastiCache for Redis キャッシュクラスターで Redis Slow ログをオンにするにはどうすればよいですか」を参照してください。

また、遅いコマンドが Redis エンジンをブロックしてしまうために、CloudWatch の EngineCPUUtilization メトリクスが増大する場合もあります。詳細については、「ElastiCache for Redis クラスターの CPU 使用率が増加して高くなるのはなぜですか?」を参照してください。

複雑なコマンドの例には次のようなものがあります。

本番環境のKEYSは、指定されたパターンを検索してキースペース全体をスイープするため、大規模なデータセットにまたがります。
LUA スクリプトの長時間の実行

メモリ使用量が多いことによるスワッピングの増加

Redis が利用可能なメモリよりも多くのメモリを使用する場合、クラスターのメモリ負荷が高まるとページのスワップを開始します。メモリページがスワップ領域との間で転送されると、レイテンシーとタイムアウトの問題が増大します。CloudWatch メトリクスでスワッピングが増大する場合を以下に示します。

SwapUsage の増加
FreeableMemory が非常に低い場合
BytesUsedForCache および DatabaseMemoryUsagePercentage メトリクスが高い場合

SwapUsage は、スワップされるメモリの量を示すホストレベルのメトリックです。このメトリックは、基盤となるオペレーティングシステムによって制御され、多くの動的要因の影響を受ける可能性があるため、ゼロ以外の値が示されるのが普通です。動的要因には、OS のバージョン、アクティビティパターンなどが含まれます。Linux は、より頻繁に使用されるキーのためにメモリスペースを解放する最適化手法として、アイドルキー（クライアントがほとんどアクセスしないキー）を率先してディスクにスワップします。

利用可能なメモリが不足すると、スワップが問題になります。このような状況が発生すると、システムはディスクとメモリの間でページを移動し始めます。具体的には、SwapUsage が数百メガバイト未満であれば、Redis のパフォーマンスに悪影響が生じることはありません。SwapUsage が高く活発になり、クラスターに十分なメモリがない場合、パフォーマンスに影響が生じます。詳細については、以下を参照してください。

ネットワークの問題によるレイテンシー

クライアントと ElastiCache クラスター間のネットワークレイテンシー

クライアントとクラスターのノード間のネットワークレイテンシーを分離するには、アプリケーション環境から TCP traceroute または mtr テストを使用します。または、AWSSupport-SetupIPMonitoringFromVPC AWS Systems Manager ドキュメント (SSM ドキュメント) などのデバッグツールを使用して、クライアントサブネットからの接続をテストします。

クラスターがネットワークの制限に到達

ElastiCache ノードは、対応するタイプの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと同じネットワーク制限を共有します。たとえば、cache.m6g.large というノードタイプには、m6g.large EC2 インスタンスと同じネットワーク制限があります。帯域幅機能、パケット毎秒（PPS）パフォーマンス、および追跡される接続の 3 つの主要なネットワークパフォーマンスコンポーネントを確認する方法については、「EC2 インスタンスのネットワークパフォーマンスを監視する」を参照してください。

ElastiCache ノードのネットワーク制限の問題をトラブルシューティングするには、「トラブルシューティング - ネットワーク関連の制限」を参照してください。

TCP/SSL ハンドシェイクのレイテンシー

クライアントは TCP 接続を使用して Redis クラスターに接続します。TCP 接続の作成には数ミリ秒を要します。要するミリ秒が長くなると、アプリケーションが実行する Redis オペレーションのオーバーヘッドが増え、Redis CPU に余分な負荷がかかります。クラスターが ElastiCache の転送時の暗号化機能を使用している場合は、TLS ハンドシェイクに余分な時間と CPU 使用量が必要となるため、新しい接続の量を制御することが重要です。大量の接続 (NewConnections) が急速に開かれて閉じられると、ノードのパフォーマンスに影響を与える可能性があります。接続プールを使用して、確立された TCP 接続をプールにキャッシュできます。この接続は、新しいクライアントがクラスターに接続しようとするたびに再利用されます。接続プールは、アプリケーション環境で使用可能なフレームワークを用いて Redis クライアントライブラリ (サポートされている場合) を使用して実装することもできますし、最初から構築することもできます。最適化手法として、MSET/MGET などの集約コマンドを使用することもできます。

ElastiCache ノードに多数の接続がある場合

CurrConnections および NewConnections CloudWatch メトリクスを追跡するのがベストプラクティスです。これらのメトリクスは、Redis が受け入れた TCP 接続の数を監視します。TCP 接続の数が多すぎると、65,000 の maxclients (最大クライアント数) 制限を使い果たす可能性があります。この制限は、ノードごとに保持できる最大同時接続数です。65,000 の制限に達すると、「ERR 最大クライアント数に達しました」というエラーが表示されます。Linux サーバーの制限、または追跡される接続の最大数を超える接続が追加されると、追加のクライアント接続は接続タイムアウトエラーとなります。多数の接続を防止するための詳細については、「Best practices: Redis clients and Amazon ElastiCache for Redis (ベストプラクティス: Redis クライアントと Amazon ElastiCache for Redis)」を参照してください。

クライアント側のレイテンシーの問題

レイテンシーとタイムアウトが、クライアント自体から発生する可能性があります。クライアント側のメモリ、CPU、およびネットワークの使用率を確認して、これらのリソースのいずれかが制限に達していないかどうかを確認します。アプリケーションが EC2 インスタンスで実行されている場合は、前に述べたものと同じ CloudWatch メトリクスを利用してボトルネックを確認します。デフォルトの CloudWatch メトリックスでは完全にモニタリングできないオペレーティングシステムでレイテンシーが発生する可能性があります。atop や CloudWatch エージェントなどのモニタリングツールをEC2 インスタンス内にインストールすることを検討してください。

アプリケーション側で設定されたタイムアウト設定値が小さすぎると、不要なタイムアウトエラーが発生する可能性があります。サーバーがリクエストを処理してレスポンスを生成するための十分な時間を確保できるように、クライアント側のタイムアウトを適切に設定してください。詳細については、「ベストプラクティス: Redis クライアントおよび Amazon ElastiCache for Redis」を参照してください。

アプリケーションから受け取ったタイムアウトエラーから、追加の詳細が明らかになります。これらの詳細には、特定のノードが関与しているかどうか、タイムアウトの原因となった Redis データタイプの名前、タイムアウトが発生した正確なタイムスタンプなどが含まれます。この情報は、問題のパターンを見つけるのに役立ちます。この情報を使用して、次のような質問に回答します。

タイムアウトは 1 日の特定の時間に頻繁に発生しますか?
タイムアウトは 1 つのクライアントで発生しましたか、それとも複数のクライアントで発生しましたか?
タイムアウトは 1 つの Redis ノードで発生しましたか、それとも複数のノードで発生しましたか?
タイムアウトは 1 つのクラスターで発生しましたか、それとも複数のクラスターで発生しましたか?

これらのパターンを使用して、最も可能性の高いクライアントまたは ElastiCache ノードを調査します。さらに、アプリケーションログと VPC フローログを使用して、クライアント側、ElastiCache ノード、またはネットワークでレイテンシーが発生したかどうかを判断することもできます。

Redis の同期

Redis の同期は、バックアップ、置換、およびスケーリングイベント中に開始されます。これは、レイテンシーを引き起こす可能性があるコンピューティング集約型のワークロードです。SaveInProgress CloudWatch メトリクスを使用して、同期が進行中かどうかを判断します。詳細については、「同期とバックアップの実装方法」を参照してください。

ElastiCache クラスターのイベント

ElastiCache コンソールの [Events] セクションで、レイテンシーが観測された期間を確認します。ElastiCache Managed Maintenance やサービスの更新で起こり得るノードの交換やフェイルオーバーイベントなどのバックグラウンドアクティビティが生じていないか、または予期しないハードウェア障害が発生していないかを確認します。予定されているイベントの通知は、PHD ダッシュボードと電子メールで受け取れます。

イベントログの例を次に示します。

Finished recovery for cache nodes 0001
Recovering cache nodes 0001
Failover from master node <cluster_node> to replica node <cluster_node> completed