Tair (または Redis オープンソース版) インスタンスの CPU 使用率の高さには、いくつかの原因が考えられます。CPU がボトルネックになっていない限り、高い同時実行性とスループットを持つアプリケーションでは、想定内の動作である可能性があります。しかし、多くの場合、これは問題を示しています。たとえば、ワークロードが Redis オープンソース版インスタンスのキャパシティを超えている可能性があります。この場合、シャードやレプリカを追加するか、Tair (Enterprise Edition) にアップグレードすることで、リソースのボトルネックを解決できます。CPU 負荷の高いコマンドの実行や、ホットキーまたはラージキーへのアクセスなど、不適切な使用方法も CPU 使用率の異常なスパイクを引き起こす可能性があります。アプリケーションの安定性を確保するために、平均 CPU 使用率が 70% を超える場合や、平均 CPU 使用率が 5 分間連続して 90% を超えたままになる場合は、調査を推奨します。
CPU 使用率が高くなる原因
CPU 負荷の高いコマンド:
KEYS、HGETALL、またはMGET、MSET、HMSET、HMGETを使用して一度に多数のキーを操作するなどのコマンドは、N が大きい値の場合に O(N) の時間計算量となります。時間計算量が大きいコマンドほど多くの CPU リソースを消費し、CPU 使用率の上昇につながります。コマンドは単一のスレッドで実行されるため、これらのコマンドを実行するとインスタンスがブロックされ、他のリクエストがキューイングされてアプリケーションのレイテンシーが増加する可能性があります。極端なケースでは、タイムアウトが発生し、トラフィックがキャッシュレイヤーをバイパスしてバックエンドデータベースに直接到達するキャッシュアバランシェを引き起こす可能性があります。
説明各コマンドの時間計算量の詳細については、「Commands」をご参照ください。
ホットキー:少数のキーに不釣り合いに多くのリクエストが集中すると、それらのキーはホットキーとなります。ホットキーは大量の CPU リソースを消費し、他の操作のレイテンシーを増加させる可能性があります。クラスターアーキテクチャでは、ホットキーが少数のデータノードに集中すると、それらのノードの CPU 使用率が他のノードよりもはるかに高くなる「CPU 使用率の偏り」を引き起こす可能性があります。
ラージキー:ラージキーへのアクセスは、より多くのメモリ、CPU リソース、およびネットワーク帯域幅を消費します。ラージキーはホットキーになりやすく、高い CPU 使用率の一因となります。ラージキーが特定のデータノードに集中すると、CPU 使用率の偏りだけでなく、メモリと帯域幅の使用率にも偏りを引き起こす可能性があります。
短時間接続:頻繁な接続の作成と終了は、データ処理ではなく接続処理に大量の CPU リソースを消費します。
AOF:追加専用ファイル (AOF) 永続化はデフォルトで有効になっています。インスタンスに高い負荷がかかると、AOF プロセスによるディスク I/O が CPU 使用率とコマンドのレイテンシーを増加させる可能性があります。
期限切れキーの削除:多数のキーが同時に期限切れになると、Redis は期限切れキーの回収に大量の CPU を費やし、CPU 使用率が急上昇する可能性があります。
このシナリオのトラブルシューティングを行うには、次の手順に従ってください。
CPU 使用率が急上昇したと同時にメモリ使用量が減少したかどうかを確認します。キーの大量失効に伴うメモリの減少は、期限切れキーの回収が原因であることを示しています。
INFOコマンドを実行して、その時点でexpired_keysとevicted_keysのカウンターが大幅に増加したかどうかを確認します。詳細については、「デフォルトのエビクションポリシー」および「期限切れキーの削除方法」をご参照ください。
CPU 使用率が高い場合のシナリオ
高い CPU 使用率は、通常、次の 3 つの一般的なシナリオで発生します。
特定の期間に CPU 使用率が突然急上昇し、時には 100% に達することがあります。原因と解決策については、「CPU 使用率の突然のスパイク」をご参照ください。
他のデータノードの使用率が低いにもかかわらず、特定のデータノードの CPU 使用率が高い場合があります。原因と解決策については、「データノード間の CPU 使用率の偏り」をご参照ください。
他のプロキシノードの使用率が低いにもかかわらず、特定のプロキシノードの CPU 使用率が高い場合があります。原因と解決策については、「プロキシノード間の CPU 使用率の偏り」をご参照ください。
シナリオに応じて、CPU 使用率を削減するための適切な手順を実行してください。
CPU 使用率の突然のスパイク
インスタンスの全体的な CPU 使用率が急上昇した場合は、次の手順に従って問題を調査し、解決してください。
CPU 負荷の高いコマンドの特定と無効化
手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
以下のツールを使用して、CPU 負荷の高いコマンドを特定します。
レイテンシーインサイト機能は、すべてのコマンドとカスタムイベントのレイテンシーを記録します。これを使用して、特定のノードで特定の期間にレイテンシーが高いコマンドを見つけることができます。
スロークエリログ機能は、指定された実行時間 (デフォルトで 20 ms) を超えるコマンドを記録します。これを使用して、実行時間が長く、CPU 負荷の高いコマンドを見つけることができます。
解決策
FLUSHALL、KEYS、HGETALLなど、リスクの高いコマンドや CPU 負荷の高いコマンドを評価し、無効にします。詳細については、「リスクの高いコマンドを無効にする」をご参照ください。オプション: ビジネスニーズに応じて、以下のインスタンス調整を検討してください。
説明スローログにも監査ログにもリソースを大量に消費するコマンドが見つからない場合、高い CPU 使用率には通常 2 つの原因が考えられます。1つ目は、高 QPS 下で蓄積された大量の O(1) コマンド (GET や SET など) です。これらはスローログのしきい値 (デフォルトで 20 ms) よりも高速に実行されるため記録されず、コマンドの無効化は効果がありません。代わりに、以下で説明するようにアーキテクチャを調整してリクエストの負荷を分散させる必要があります。2つ目は、頻繁に確立される短時間接続です。これも CPU を消費し、スローログには表示されません。トラブルシューティングと最適化については、このトピックの「短時間接続の最適化」をご参照ください。
インスタンスを読み書き分離アーキテクチャに変更して、CPU 負荷の高いコマンドやアプリケーションをオフロードします。
インスタンスをDRAM ベースのインスタンスに変更して、そのマルチスレッド機能を活用し、CPU 使用率を削減します。
説明インスタンスのアーキテクチャとタイプを変更する方法については、「インスタンスの構成を変更する」をご参照ください。
短時間接続の最適化
手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
パフォーマンスモニタリングページで、高い CPU 使用率、高い接続数、および予想よりも低い 1 秒あたりのクエリ数 (QPS) の組み合わせを確認します。このパターンは、短時間接続の問題を示しています。
解決策
JedisPool などの接続プールを使用して、短時間接続から永続的な接続に切り替えます。詳細については、「クライアントを使用してインスタンスに接続する」をご参照ください。
インスタンスを、短時間接続向けに最適化されているDRAM ベースのインスタンスに変更します。
AOF の無効化
AOF はデフォルトで有効になっています。高負荷時には、頻繁な AOF 操作が高い CPU 使用率の一因となることがあります。
ビジネス要件で許容される場合は、永続化を無効にし、影響を最小限に抑えるためにオフピーク時にデータバックアップをスケジュールすることを検討してください。
インスタンスがDRAM ベースのインスタンスの場合、AOF を無効にすると AOF ファイルからデータを復元できなくなります。これは、データフラッシュバック機能が利用できなくなることを意味します。バックアップセットから新しいインスタンスにデータを復元することしかできません。注意して進めてください。
サービスキャパシティの評価
前述の最適化を実行した後も、通常運用中に平均 CPU 使用率が高いまま (70% 超) の場合、インスタンスにパフォーマンスのボトルネックがある可能性が高いです。
まず、異常なコマンドや特定のアプリケーションホストからの大量のリクエストなど、異常なアクセスパターンがないか確認します。これらの問題はアプリケーションレベルで対処する必要があります。すべてのアクセスが正当である場合、高い負荷はワークロードに起因する正常な結果です。安定した運用を確保するために、インスタンスの仕様をアップグレードするか、クラスターアーキテクチャまたは読み書き分離アーキテクチャに変更することを推奨します。詳細については、「インスタンスの構成を変更する」をご参照ください。
ビジネスの安定性を確保するために、本番インスタンスをアップグレードする前に、従量課金インスタンスを購入して負荷テストと互換性テストを実行することを推奨します。テスト完了後、テストインスタンスは解放できます。
データノード間の CPU 使用率の偏り
クラスターアーキテクチャまたは読み書き分離アーキテクチャを使用している場合、一部のデータノードの CPU 使用率が高く、他のデータノードの使用率が低いことがあります。問題を調査し、解決するには、次の手順に従ってください。
ホットキーのトラブルシューティングと最適化
手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
リアルタイムキー統計の履歴ページで、CPU 使用率の高いデータノードを選択し、手順 1 で特定した期間を指定してから、[Search] をクリックします。これにより、CPU 使用率が高かった期間のホットキーが表示されます。
解決策
ビジネスロジックに基づいてホットキーを分割します。たとえば、キー名にユーザー ID やタイムスタンプの範囲を追加します。
大量の読み取りリクエストがホットキーの原因である場合は、インスタンスを読み書き分離アーキテクチャに変更して、各データノードの読み取り負荷を軽減することを検討してください。
説明リクエスト量が極端に多いシナリオでは、読み書き分離アーキテクチャでは、避けられないレプリケーションの遅延が発生し、古いデータを読み取る可能性があります。したがって、このアーキテクチャは、高い読み書きの負荷があり、かつ厳密なデータ一貫性も要求されるワークロードに最適とは言えない場合があります。
CPU 負荷の高いコマンドの特定と無効化
手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
以下のツールを使用して、CPU 負荷の高いコマンドを特定します。
レイテンシーインサイト機能は、すべてのコマンドとカスタムイベントのレイテンシーを記録します。これを使用して、特定のノードで特定の期間にレイテンシーが高いコマンドを見つけることができます。
スロークエリログ機能は、指定された実行時間 (デフォルトで 20 ms) を超えるコマンドを記録します。これを使用して、実行時間が長く、CPU 負荷の高いコマンドを見つけることができます。
解決策
FLUSHALL、KEYS、HGETALL など、リスクの高いコマンドや CPU 負荷の高いコマンドを評価し、無効にします。詳細については、「リスクの高いコマンドを無効にする」をご参照ください。
ラージキーのトラブルシューティングと最適化
手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
キャッシュ分析ページで、[Analyze Now] をクリックします。CPU 使用率の高いデータノードを選択し、[OK] をクリックします。これにより、CPU 使用率が高かった期間に存在したラージキーが表示されます。
解決策
ビジネス要件に基づいて、ラージキーをより小さなキーに分割し、リクエスト負荷を分散させます。
プロキシノード間の CPU 使用率の偏り
クラスターアーキテクチャまたは読み書き分離アーキテクチャを使用している場合、一部のプロキシノードの CPU 使用率が高く、他のプロキシノードの使用率が低いことがあります。問題を調査し、解決するには、次の手順に従ってください。
手順
[パフォーマンス傾向] ページの [Proxy Node] タブで、接続使用率がノード間で均等になっているかどうかを確認します。詳細については、「パフォーマンス傾向」をご参照ください。
解決策
接続使用率が均等かどうかによって、次のいずれかの操作を実行してください。
接続使用率が均等な場合:クライアントアプリケーションまたはプロキシノードを再起動して、接続のバランスを再調整します。プロキシノードを再起動するには、「プロキシノードの再起動または再構築」をご参照ください。
接続使用率が不均衡な場合:この不均衡は、通常、大規模なパイプラインまたはバッチ操作によって引き起こされます。たとえば、大規模なバッチ操作を複数の小さな操作に分割するなどして、これらの操作のサイズを小さくします。