ElastiCache for Redis クラスターの CPU 使用率が増加して高くなるのはなぜですか?

簡単な説明

ElastiCache for Redis には、以下の 2 つの Amazon CloudWatch CPU メトリクスがあります。

• EngineCPUUtilization: このメトリクスは、Redis エンジンスレッドの CPU 使用率を報告するものです。Redis はシングルスレッドのため、vCPU が 4 つ以上のノードの EngineCPUUtilization メトリクスをモニタリングするのがベストプラクティスです。
• CPUUtilization: このメトリクスは、ホスト全体の CPU 使用率の割合 (%) を示します。vCPU が 2 つ以下の小規模なノードの場合は、CPUUtilization メトリクスを使用してクラスターのワークロードをモニタリングします。

解決方法

高い EngineCPUUtlilization

EngineCPUUtilization が高くなる一般的な理由は次のとおりです。

• CPU 時間を多く消費する長時間実行コマンド: keys、hkeys、hgetall など、時間的複雑性の高いコマンドは、CPU 時間をより多く消費します。各コマンドの時間的複雑性とパフォーマンスに関する推奨事項については、redis.io ウェブサイトの「Commands」(コマンド) を参照してください。Lua スクリプト (Redis コマンド EVAL または EVALSHA で実行) は Redis でのアトミック操作です。Lua スクリプトの実行時間全体にわたって、すべてのサーバーアクティビティがブロックされ、EngineCPUUtilization が高くなります。 Redis Slow ログ を使用して、長時間にわたって実行されるコマンドまたは Lua スクリプトがあるかどうかを確認します。
• リクエスト数が多い: コマンドの統計情報を確認して、コマンドバーストの発生または遅延の増加がないかどうかを判断します。GetTypeCmds または HashBasedCmds などの CloudWatch メトリクスを使用して、コマンドの統計情報を確認できます。または、Redis コマンド info commandstats を使用します。アプリケーションの予想されるワークロードが原因でリクエスト数が多い場合は、クラスターのスケーリングを検討してください。
• バックアップとレプリケーション: SaveInProgress メトリクスを調べて、バックアップまたはレプリケーションの実行中かどうかを確認します。このバイナリメトリクスは、バックグラウンド保存 (分岐あり、または分岐なし) が進行中の場合に「1」を返します。バックグラウンド保存が進行中でない場合、メトリクスは「0」を返します。Redis スナップショットを作成するのに十分なメモリがあることを確認してください。
• NewConnections の数が多い: TCP 接続の確立は、特に TLS 対応のクラスターでは計算負荷の高いオペレーションです。短時間に数多くの新しいクライアント接続リクエストが発生すると、EngineCPUUtilization が増加する可能性があります。 Redis 6.2 以降では、vCPU が 8 つ以上の x86 ノードタイプまたは vCPU が 4 つ以上の Graviton2 ノードタイプを使用した TLS 対応クラスターのパフォーマンス向上が実装されています。多数の接続を処理するための推奨事項については、「Best practices: Redis clients and Amazon ElastiCache for Redis」(ベストプラクティス: Redis クライアントと Amazon ElastiCache for Redis) を参照してください。
• エビクション数が多い: Redis は maxmemory-policy パラメータに従ってキーを削除します。新しいデータを保持するのに十分なメモリがキャッシュにないと、エビクションが発生します。エビクションの数が多いと、Redis がキーエビクションでビジー状態になるため EngineCPUUtilization が増加します。エビクションの数は、CloudWatch メトリクス Evictions でモニタリングできます。エビクションが多い場合は、より大きなノードタイプを使用してクラスターをスケールアップするか、ノードを追加してスケールアウトしてください。
• 解放数が多い: メモリを解放するために、Redis はタイムアウト期限に達したキーを抽出して削除します。このプロセスを「解放」と呼びます。 有効期限に達したキーの数が多いと、Redis がキーの解放でビジー状態になるため EngineCPUUtilization が増加します。CloudWatch メトリクス Reclaimed を使用して、キーの有効期限イベントの数をモニタリングできます。 ベストプラクティスとしては、Redis コマンド EXPIREAT を実行するなどして、同時にあまり多くのキーを期限切れにしないようにすることです。

EngineCPUUtilization が高い場合のトラブルシューティングの詳細については、接続のトラブルシューティング - CPU 使用率に関するページを参照してください。

高い CPUUtilization

CPUUtilization が高くなる一般的な理由は次のとおりです。

• ネットワークトラフィックまたは接続が多い: NewConnections、NetworkBytesIN、NetworkBytesOut、NetworkPacketsIn、NetworkPacketsOut の CloudWatch メトリクスを確認します。
• EngineCPUUtilization が高く、非同期 I/O が他のスレッドによって処理される: 強化された I/O 処理の詳細について、「Amazon ElastiCache performance boost with Amazon EC2 M5 and R5 instances」(Amazon EC2 M5 および R5 インスタンスによる Amazon ElastiCache パフォーマンスの向上) を参照してください。
• 継続的な管理メンテナンスとサービスの更新: メンテナンスとサービスの更新にはコンピューティング能力が必要です。その結果、これらのイベント中に CPUUtilization の急増が見られることがあります。メンテナンス期間を調べて、スパイクがその期間と一致するかどうかを確認します。影響を最小限に抑えるためのベストプラクティスは、使用量が最も少ない時間にメンテナンス期間を設定することです。詳細については、「Amazon ElastiCache 管理メンテナンスとサービス更新のヘルプページ」を参照してください。
• ページングやバックアップなどのオペレーションが多い: ノードのメモリが不足すると、カーネルによりページアウトされメモリがスワップされる可能性があります。ページングが過剰になると、CPUUtilization が増加する可能性があります。同様に、バックアップやスケーリングなどのオペレーションでノードの負荷が高くなると、CPUUtilization が増加する可能性があります。スパイクの原因を特定するためのメトリクスに関する推奨事項については、「Monitoring best practices with Amazon ElastiCache for Redis using Amazon CloudWatch」(Amazon CloudWatch を使用した Amazon ElastiCache for Redis のモニタリングのベストプラクティス) を参照してください。

---