すべてのプロダクト
Search

このプロダクト

    Tair (Redis® OSS-Compatible):CPU 使用率が高い場合のトラブルシューティング

    ドキュメントセンター

    Tair (Redis® OSS-Compatible):CPU 使用率が高い場合のトラブルシューティング

    最終更新日:Jun 22, 2026

    Tair (または Redis オープンソース版) インスタンスにおける高い CPU 使用率には、いくつかの原因が考えられます。高い同時実行性とスループットを持つアプリケーションでは、CPU がボトルネックになっていない限り、高い CPU 使用率は正常な動作である場合があります。しかし、多くの場合、問題があることを示しています。たとえば、ワークロードが Redis オープンソース版インスタンスの容量を超える場合があります。この場合、シャードやレプリカを追加するか、Tair (エンタープライズ版) にアップグレードすることで、リソースのボトルネックを解決できます。CPU 負荷の高いコマンドの実行、ホットキーやラージキーへのアクセスなど、不適切な使用も CPU 使用率の異常な急上昇を引き起こす可能性があります。アプリケーションの安定性を確保するために、平均 CPU 使用率が 70% を超える場合、または 5 分間連続で 90% を超える状態が続く場合は、調査を実施してください。

    CPU 使用率が高くなる原因

    • CPU 負荷の高いコマンド：KEYS、HGETALL のようなコマンドや、MGET、MSET、HMSET、HMGET を用いて一度に多数のキーを操作するコマンドは、時間計算量が O(N) (N は大きな値) となります。時間計算量が大きいコマンドは、より多くの CPU リソースを消費し、CPU 使用率の上昇につながります。

      コマンドは単一のスレッドで実行されるため、これらのコマンドを実行するとインスタンスがブロックされ、他のリクエストがキューに入れられ、アプリケーションのレイテンシーが増加する原因となります。極端な場合には、タイムアウトにつながり、キャッシュアバランシェを引き起こし、トラフィックがキャッシュレイヤーをバイパスしてバックエンドデータベースに直接アクセスする可能性があります。

      説明

      各コマンドの時間計算量の詳細については、「Commands」をご参照ください。

    • ホットキー：少数のキーが不釣り合いに多数のリクエストを受けると、それらはホットキーになります。ホットキーは、大量の CPU リソースを消費し、他の操作のレイテンシーを増加させる可能性があります。クラスターアーキテクチャでは、ホットキーが少数のデータノードに集中すると、CPU 使用率のスキューが発生し、それらのノードの CPU 使用率が他のノードよりもはるかに高くなる可能性があります。

    • ラージキー：ラージキーへのアクセスは、より多くのメモリ、CPU リソース、およびネットワーク帯域幅を消費します。ラージキーはホットキーになる可能性が高く、高い CPU 使用率の一因となります。ラージキーが特定のデータノードに集中すると、CPU 使用率のスキューだけでなく、メモリと帯域幅の使用率のスキューにもつながる可能性があります。

    • 短命な接続：頻繁な接続の確立と切断は、データ処理ではなく接続処理に多くの CPU リソースを消費します。

    • AOF：AOF (Append-only file) 永続化はデフォルトで有効になっています。インスタンスに高い負荷がかかると、AOF プロセスによるディスク I/O が CPU 使用率とコマンドのレイテンシーを増加させる可能性があります。

    CPU 使用率が高いシナリオ

    高い CPU 使用率は、通常、次の 3 つのシナリオで発生します：

    シナリオに応じて、CPU 使用率を削減するための適切な手順を実行してください。

    CPU 使用率の突然の急上昇

    インスタンス全体の CPU 使用率が急上昇した場合は、次の手順に従って問題を調査し、解決してください。

    CPU 負荷の高いコマンドの特定と無効化

    手順

    1. パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。

    2. 次のツールを使用して CPU 負荷の高いコマンドを特定します：

      • レイテンシーインサイト機能は、すべてのコマンドとカスタムイベントのレイテンシーを記録します。これを使用して、特定のノードで特定の期間にレイテンシーが高いコマンドを見つけることができます。

      • スロークエリログ機能は、指定された実行時間 (デフォルトでは 20 ms) を超えるコマンドを記録します。これを使用して、実行時間が長く、CPU 負荷の高いコマンドを見つけることができます。

    解決策

    • FLUSHALL、KEYS、HGETALL など、リスクの高いコマンドと CPU 負荷の高いコマンドを評価し、無効化します。詳細については、「リスクの高いコマンドの無効化」をご参照ください。

    • オプション： ビジネスニーズに基づいて、次のインスタンスの調整を検討してください：

      説明

      インスタンスのアーキテクチャとタイプを変更する方法については、「インスタンスの設定変更」をご参照ください。

    短命な接続の最適化

    手順

    1. パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。

    2. パフォーマンスモニタリングページで、高い CPU 使用率、高い接続数、および想定よりも低い 1 秒あたりのクエリ数 (QPS) の組み合わせを確認します。このパターンは、短命な接続の問題を示しています。

    解決策

    AOF の無効化

    AOF はデフォルトで有効になっています。高負荷時には、頻繁な AOF 操作が高い CPU 使用率の一因となることがあります。

    ビジネス要件で許容される場合は、永続化を無効にし、影響を最小限に抑えるためにオフピーク時にデータバックアップをスケジュールすることを検討してください。

    警告

    インスタンスが DRAM ベースのインスタンスの場合、AOF を無効にすると AOF ファイルからデータを復元できなくなります。これは、データフラッシュバック機能が利用できなくなることを意味します。バックアップセットから新しいインスタンスにデータを復元することしかできません。慎重に進めてください。

    サービスキャパシティの評価

    前述の最適化を実行した後も、通常運用中に平均 CPU 使用率が高いまま (70% 超) である場合、インスタンスにパフォーマンスのボトルネックがある可能性が高いです。

    まず、異常なコマンドや特定のアプリケーションホストからの大量のリクエストなど、異常なアクセスパターンがないか確認します。これらの問題は、アプリケーションレベルで対処する必要があります。すべてのアクセスが正当である場合、高負荷はワークロードの正常な結果です。安定した運用を確保するため、インスタンスの仕様をアップグレードするか、クラスターアーキテクチャまたは 読み書き分離アーキテクチャに変更することを推奨します。詳細については、「インスタンスの設定変更」をご参照ください。

    説明

    ビジネスの安定性を確保するため、本番インスタンスをアップグレードする前に、従量課金インスタンスを購入して負荷テストと互換性テストを実行することを推奨します。テスト完了後、テストインスタンスをリリースできます。

    データノードの CPU 使用率のスキュー

    クラスターアーキテクチャまたは 読み書き分離アーキテクチャを使用している場合、一部のデータノードの CPU 使用率が高く、他のデータノードの使用率が低いことがあります。次の手順に従って問題を調査し、解決してください。

    ホットキーのトラブルシューティングと最適化

    手順

    1. パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。

    2. リアルタイムキー統計の履歴ページで、CPU 使用率が高いデータノードを選択し、ステップ 1 で特定した期間を指定してから、[Search] をクリックします。これにより、CPU 使用率が高かった期間中のホットキーが表示されます。

    解決策

    • ビジネスロジックに基づいてホットキーを分割します。たとえば、キー名にユーザー ID やタイムスタンプ範囲を追加します。

    • 大量の読み取りリクエストがホットキーの原因である場合は、インスタンスを読み書き分離アーキテクチャに変更して、各データノードの読み取り圧力を軽減することを検討してください。

      説明

      非常に高いリクエスト量のシナリオでは、読み書き分離アーキテクチャでは避けられないレプリケーションレイテンシーが発生し、古いデータを読み取る可能性があります。したがって、このアーキテクチャは、高い読み書き負荷と強いデータ一貫性の両方を必要とするワークロードには最適な解決策ではない場合があります。

    CPU 負荷の高いコマンドの特定と無効化

    手順

    1. パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。

    2. 次のツールを使用して CPU 負荷の高いコマンドを特定します：

      • レイテンシーインサイト機能は、すべてのコマンドとカスタムイベントのレイテンシーを記録します。これを使用して、特定のノードで特定の期間にレイテンシーが高いコマンドを見つけることができます。

      • スロークエリログ機能は、指定された実行時間 (デフォルトでは 20 ms) を超えるコマンドを記録します。これを使用して、実行時間が長く、CPU 負荷の高いコマンドを見つけることができます。

    解決策

    FLUSHALL、KEYS、HGETALL など、リスクの高いコマンドと CPU 負荷の高いコマンドを評価し、無効化します。詳細については、「リスクの高いコマンドの無効化」をご参照ください。

    ラージキーのトラブルシューティングと最適化

    手順

    1. パフォーマンスモニタリング機能を使用して、CPU 使用率が高かった特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。

    2. オフラインキー分析ページで、[Analyze Now] をクリックします。CPU 使用率が高いデータノードを選択し、[OK] をクリックします。これにより、CPU 使用率が高かった期間中に存在したラージキーが表示されます。

    解決策

    ビジネス要件に基づいて、ラージキーをより小さなキーに分割してリクエスト負荷を分散します。

    プロキシノードの CPU 使用率のスキュー

    クラスターアーキテクチャまたは 読み書き分離アーキテクチャを使用している場合、一部のプロキシノードの CPU 使用率が高く、他のプロキシノードの使用率が低いことがあります。次の手順に従って問題を調査し、解決してください。

    手順

    [Performance Trends] ページの [Proxy Node] タブで、接続使用率がノード間で均等であるかどうかを確認します。詳細については、「パフォーマンス傾向」をご参照ください。

    解決策

    接続使用率が均等であるかどうかに基づいて、次のいずれかの操作を実行してください：

    • 接続使用率に偏りがない場合：クライアントアプリケーションまたはプロキシノードを再起動して、接続を再分散します。プロキシノードを再起動するには、「プロキシノードの再起動または再構築」をご参照ください。

    • 接続使用率に偏りがある場合：この不均衡は、通常、大規模なパイプラインまたはバッチ操作によって引き起こされます。たとえば、大規模なバッチ操作を複数の小規模な操作に分割するなどして、これらの操作のサイズを小さくします。