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

所要時間2分

Amazon ElastiCache for Redis の高レイテンシー問題をトラブルシューティングしたいと考えています。

簡単な説明

ElastiCache for Redis における高レイテンシー問題の一般的な原因は次のとおりです。

スローコマンド
メモリ使用量の増加によるスワップアクティビティの増加
ネットワークに関する問題
クライアント側のレイテンシーの問題
Redis 同期
ElastiCache クラスターイベント

解決策

以下の原因に基づいて、高レイテンシーの問題をトラブルシューティングしてください。

スローコマンド

Redis はシングルスレッドです。そのため、リクエストの処理が遅い場合、他のクライアントは処理を待たなければなりません。この速度低下により、リクエストが処理される合計時間が長くなります。さまざまなクラスのコマンドの平均レイテンシーをモニタリングするには、Redis 用の Amazon CloudWatch メトリクスを使用します。また、一般的な Redis 操作はマイクロ秒単位のレイテンシーで計算されます。CloudWatch メトリクスは 1 分ごとにサンプリングされ、レイテンシーメトリクスは複数のコマンドの集合として表示されます。1 つのコマンドを実行しただけで、メトリクスグラフに大きな変化が見られなくても、タイムアウトなどの予期しない結果が生じる可能性があります。完了までに時間がかかるコマンドのリストを取得するには、SLOWLOG GET を使用します。また、redis-cli で slowlog get 128 コマンドを実行します。詳細については、Redis ウェブサイトの「SLOWLOG GET」を参照してください。また、「ElastiCache for Redis キャッシュクラスターで Redis Slow ログを有効にするにはどうすればよいですか?」を参照してください。

EngineCPUUtilization メトリクスが増加した場合は、「自己設計 ElastiCache for Redis クラスターの CPU 使用率の増加をトラブルシューティングする方法を教えてください」を参照してください。

以下は複雑なコマンドの例です。

大規模なデータセットを対象とする実稼働環境にある KEYS。KEYS はキースペース全体をスイープし、指定されたパターンを検索します。詳細については、Redis ウェブサイトの「KEYS」を参照してください。
実行に時間がかかる Lua スクリプト。詳細については、Redis ウェブサイトの「Lua を使ったスクリプティング」を参照してください。

メモリ使用量の増加によるスワップアクティビティの増加

Redis は、クラスターのメモリ負荷が高まると、メモリページをスワップします。これにより、スワップ領域との間で転送されるメモリページが原因で、レイテンシーが増加し、タイムアウトが発生する可能性があります。以下は、CloudWatch メトリクスのスワップアクティビティの増加を示しています。

スワップ使用量の増加
非常に少ない空きメモリ
高いBytesUsedForCache および DatabaseMemoryUsagePercentage メトリクス

スワップアクティビティの増加をトラブルシューティングするには、以下のリソースを参照してください。

ネットワークに関する問題

ネットワークの問題によって発生する高レイテンシーの問題をトラブルシューティングするには、次のシナリオを参照してください。

クライアントと ElastiCache クラスター間のネットワークレイテンシー
クライアントとクラスターノードの間のレイテンシーを分離するには、「VPC 内の EC2 Linux または Windows インスタンスとオンプレミスホスト間のインターネットゲートウェイ経由のネットワークパフォーマンスに関する問題のトラブルシューティング方法を教えてください」を参照してください。

クラスターがネットワークの制限に達しました
ElastiCache ノードは、関連する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと同じネットワーク制限を共有します。たとえば、cache.m6g.large というノードタイプには、Amazon EC2 インスタンスの m6g.large と同じネットワーク制限があります。ElastiCache ノードのネットワーク制限のトラブルシューティングについては、「ネットワーク関連の制限」を参照してください。また、Amazon EC2 インスタンスのネットワークパフォーマンスをモニタリングし、帯域幅能力、1 秒あたりのパケット数 (PPS) のパフォーマンス、追跡される接続を確認することもベストプラクティスです。

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

クライアントは TCP 接続を使用して Redis クラスターに接続します。TCP 接続の作成には数ミリ秒かかることがあります。この遅延により、アプリケーションの Redis 操作に追加のオーバーヘッドが発生する可能性があります。また、ElastiCache ノードは CPU にさらなる負荷をかけます。特にクラスターが ElastiCache 転送中暗号化 (TLS) 機能を使用している場合は、新しい接続の量を制御するようにしてください。開かれた接続 (NewConnections) と閉じられる接続が大量にあると、ノードのパフォーマンスに影響する可能性があります。接続数が多い場合は、接続プーリングを使用して確立された TCP 接続をプールにキャッシュします。接続プールを実装するには、Redis クライアントライブラリ (サポートされている場合) を使用するか、接続プールを手動で構築します。MSET/MGET や Redis パイプラインなどの集約コマンドを最適化手法として使用することもできます。詳細については、Redis ウェブサイトの「Redis パイプライン」を参照してください。

ElastiCache ノードには多数の接続があります。

CurrConnections と NewConnections CloudWatch メトリクスを追跡するのがベストプラクティスです。これらのメトリクスは、Redis が受け入れる TCP 接続の数を監視します。TCP 接続の数が多いと、maxclients 65,000 の制限を使い果たす可能性があります。この制限は、ノードごとに確立できる最大同時接続数です。詳細については、Redis Web サイトの「同時接続クライアントの最大数」を参照してください。制限が65,000に達すると、「ERR の最大クライアント数に達しました」というエラーが表示されます。Linux サーバーの制限または追跡される最大接続数を超えて接続が追加されると、接続タイムアウトが発生します。大量の接続を防ぐ方法の詳細については、「Redis クライアントのベストプラクティス」を参照してください。

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

クライアント側のリソースがレイテンシーの問題を引き起こしているかどうかを判断するには、クライアント側のメモリ、CPU、およびネットワーク使用率を確認します。これらのリソースが限界に近づいていないことを確認してください。アプリケーションが Amazon EC2 インスタンスで実行されている場合は、CloudWatch メトリクスを使用して問題を特定します。また、Amazon EC2 インスタンス内のモニタリングツール (atop や CloudWatch エージェントなど) を使用します。

アプリケーションに設定されているタイムアウト設定値が小さすぎると、不要なタイムアウトエラーが発生する可能性があります。これらのエラーを解決するには、サーバーが要求を処理して応答を生成するのに十分な時間を確保できるように、クライアント側のタイムアウトを設定します。詳細については、「Redis クライアントのベストプラクティス」を参照します。また、タイムアウトエラーには追加情報が表示されます。タイムアウトエラーの詳細を確認して、レイテンシの原因を特定します。以下のパターンを確認して、レイテンシーの原因がクライアント側、ElastiCache ノード、またはネットワークのどれにあるかを判断してください。

タイムアウトが頻繁に発生するのか、特定の時間に発生するのかを確認します。
タイムアウトが特定のクライアントで発生するのか、複数のクライアントで発生するのかを確認します。
タイムアウトが特定の Redis ノードで発生するのか、複数のノードで発生するのかを確認します。
タイムアウトが特定のクラスターで発生するのか、複数のクラスターで発生するのかを確認します。

Redis 同期

Redis 同期は、バックアップ、ノード交換、およびスケーリングイベントで開始されます。これは計算量の多いワークロードであり、レイテンシーが発生する可能性があります。同期が進行中かどうかを確認するには、SaveInProgress CloudWatch メトリクスを使用します。詳細については、「同期とバックアップの実装方法」を参照してください。

ElastiCache クラスターイベント

レイテンシーが発生した期間を確認するには、ElastiCache コンソールのイベントセクションを参照してください。ElastiCache のマネージドメンテナンスやサービスの更新によって発生する可能性のあるバックグラウンドアクティビティ (ノード交換やフェイルオーバーイベントなど) がないか確認します。また、予期しないハードウェア障害がないか確認します。スケジュールされたイベント通知は、AWS Health Dashboard と E メールで受信されます。

イベントログの例:

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