ほとんどの場合、ApsaraDB for RedisインスタンスのCPU使用率の増加は、同時実行性とスループットの高さ、予想外のワークロードの高さ、および不適切なリソース使用に起因する可能性があります。 高い同時実行性と高いスループットを持つビジネス操作は、より多くのCPUリソースを消費します。 CPU使用率がシステムの容量内にある場合、増加したCPUアクティビティは正常と見なされます。 ApsaraDB for Redisインスタンスにワークロードの要求を満たすのに十分なCPUリソースがない場合は、シャードまたはレプリカの数を増やすか、インスタンスをTairインスタンスにアップグレードしてリソースのボトルネックを軽減できます。 さらに、CPU集中コマンド、ホットキー、大きなキーなどのリソースを不適切に使用すると、CPUの使用率が異常に高くなる可能性があります。 平均CPU使用率が70% より高く、5分以内の平均ピークCPU使用率が90% より高い場合、アプリケーションの安定性に影響を与える可能性があります。 この問題に細心の注意を払い、トラブルシューティングする必要があります。
CPU使用率の異常な増加を引き起こす要因は何ですか?
CPU集中コマンド: O(N) の時間複雑度を有するコマンドであり、Nは大きな値である。 例: KEYS、HGETALL、MGET、MSET、HMSET、およびHMGET。 ほとんどの場合、時間の複雑さが高いコマンドは、より多くのCPUリソースを消費します。 これにより、CPU利用率が増加する。
ApsaraDB for RedisがCPU負荷の高いコマンドを実行すると、シングルスレッドのために保留中のリクエストがキューに蓄積されます。 これにより、アプリケーションの応答が遅くなります。 特定のケースでは、ApsaraDB for Redisインスタンスが保留中のリクエストに圧倒される場合があります。 アプリケーションは、これらの要求がタイムアウトするために切断され得る。 さらに、要求はバックエンドデータベースに直接転送され、キャッシュアバランシェを引き起こす可能性があります。
説明各コマンドの時間の複雑さについては、Redis公式Webサイトをご覧ください。
ホットキー: 単一のキーまたはキーのサブセットが他のキーよりも頻繁にアクセスされる場合、考えられる理由は、1つ以上のホットキーが生成されたことです。 ホットキーは、ApsaraDB for RedisのCPUリソースを大量に消費する可能性があります。 これは、他のキーのアクセス遅延に影響します。 クラスターインスタンスのホットキーが特定のデータシャードに集中している場合、CPU使用率のスキューが発生する可能性があります。 この場合、特定のシャードのCPU使用率は、他のシャードのCPU使用率よりもはるかに高くなります。
大きいキー: 大きいキーはより多くのメモリを消費します。 大きなキーにアクセスすると、ApsaraDB for RedisのCPU負荷とトラフィックが大幅に増加します。 大きなキーはホットスポットになりやすく、CPU使用率が高くなる可能性があります。 大きなキーが特定のデータシャードに集中している場合、CPU使用率、帯域幅使用率、およびメモリ使用率が歪んでいる可能性があります。
有効期間の短い接続: 接続を頻繁に確立すると、接続処理に関連するオーバーヘッドにより、ApsaraDB for Redisインスタンスのリソースが大幅に消費される可能性があります。
AOF: ApsaraDB for Redisインスタンスでは、デフォルトで追加専用ファイル (AOF) 永続化が有効になっています。 インスタンスの負荷が大きい場合、AOFにデータを書き込むと、CPU使用率が増加し、インスタンス全体の応答レイテンシが高くなります。
CPU使用率が高いシナリオ
次のシナリオでは、CPU使用率が高くなる場合があります。
特定の期間中に、CPU使用率は突然高レベルに急上昇し、100% に達します。 原因と解決策については、「CPU使用率の突然の増加」をご参照ください。
インスタンス内のデータノードのCPU使用率は、他のデータノードと比較して高くなります。 原因と解決策については、「データノード間のCPU使用率の不一致」をご参照ください。
インスタンス内のプロキシノードは、他のプロキシノードと比較してCPU使用率が高くなります。 原因と解決策については、「プロキシノード間のCPU使用率の不一致」をご参照ください。
シナリオに基づいて、CPU使用率を下げるための適切な対策を講じてください。
CPU使用率の突然の増加
インスタンスの全体的なCPU使用率が増加した場合は、次の手順を実行して問題をトラブルシューティングします。
CPU集中型コマンドのトラブルシューティングと無効化
トラブルシューティング手順
パフォーマンスモニタリング機能を使用して、CPU使用率が高い期間を特定します。 詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
次の方法でCPU負荷コマンドを識別します。
レイテンシインサイト機能は、ApsaraDB for Redisインスタンス上のすべてのコマンドとカスタム特別イベントのレイテンシを記録します。 さまざまなノード間で特定の期間にわたって収集されたレイテンシ情報に基づいて、応答時間が長いCPU負荷の高いコマンドを特定できます。 詳細については、「遅延インサイト」をご参照ください。
図 1. レイテンシインサイトの使用例
Slow logsは、指定されたしきい値より長く実行されるコマンドを記録します。 さまざまなノード間で特定の期間にわたって収集された低速クエリとその実行期間に基づいて、CPU負荷の高いコマンドを識別できます。 詳細については、「スローログの照会」をご参照ください。
図2. スローログクエリの例
ソリューション
FLUSHALL、KEYS、HGETALLなどのリスクの高いコマンドとCPU負荷の高いコマンドを評価および無効にします。 詳細については、「高リスクコマンドの無効化」をご参照ください。
オプション: 次のいずれかの方法を使用して、ビジネス要件に基づいてインスタンスアーキテクチャを変更します。
インスタンスのアーキテクチャを読み書き分離に変更して、CPU負荷の高いコマンドまたはアプリケーション要求を均等に分散します。 読み書き分離アーキテクチャの詳細については、「読み書き分離インスタンス」をご参照ください。
インスタンスをTair DRAMベースのインスタンスに変換し、DRAMベースのインスタンスのマルチスレッド機能を使用して、インスタンスのCPU使用率を削減します。
説明インスタンスのアーキテクチャと系列タイプを変更する方法については、「インスタンスの構成の変更」をご参照ください。
トラブルシューティングと最适化短寿命接続
トラブルシューティング手順
パフォーマンスモニタリング機能を使用して、CPU使用率が高い期間を特定します。 詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
パフォーマンスモニタリングダッシュボードで、CPU使用率が高く、予想される1秒あたりのクエリ (QPS) がない接続が多数存在するかどうかを確認します。 上記のシナリオが真の場合、短期間の接続が存在する可能性があります。 この場合、次のいずれかのソリューションを使用します。
ソリューション
短命接続を永続接続に変更します。 たとえば、JedisPool接続プールを作成します。 詳細については、「クライアントを使用したApsaraDB For Redisインスタンスへの接続」をご参照ください。
インスタンスをTair DRAMベースのインスタンスに変換して、短期間の接続の処理を最適化します。
AOF持続性の無効化
ApsaraDB for Redisインスタンスでは、デフォルトでAOF永続化が有効になっています。 インスタンスの負荷が大きい場合、頻繁なAOF操作によりCPU使用率が増加する可能性があります。
これがビジネスに悪影響を及ぼさない場合は、AOFの持続性を無効にします。 さらに、オフピーク時またはメンテナンス期間中にApsaraDB for Redisインスタンスのデータをバックアップして、影響を最小限に抑えることができます。
Tair DRAMベースのインスタンスを使用している場合、インスタンスのAOF持続性を無効にした後、AOFを使用してインスタンスのデータを復元することはできません。 この場合、データフラッシュバック機能は使用できません。 バックアップセットのみを使用してデータを復元できます。 詳細については、「バックアップセットから新しいインスタンスへのデータの復元」をご参照ください。 AOF持続性を無効にするときは注意してください。
サービスパフォーマンスの評価
上記の方法は、ApsaraDB for Redisインスタンスのパフォーマンスを最適化するために使用されます。 ビジネス運用中にCPUの平均使用率が依然として70% を超える場合、インスタンスにパフォーマンスのボトルネックが発生する可能性があります。
この問題を解決するには、インスタンスのパフォーマンスを低下させる可能性のあるアプリケーションホストからのコマンドとリクエストが存在するかどうかを確認します。 そのようなコマンドやリクエストが存在する場合は、ビジネスシステムを最適化する必要があります。 このようなコマンドやリクエストが存在しないにもかかわらず、CPU使用率が高い場合は、インスタンスの仕様をアップグレードしてビジネスの安定性を確保することを推奨します。 インスタンスをクラスターインスタンスまたは読み書き分離インスタンスにアップグレードすることもできます。 インスタンスのアップグレード方法の詳細については、「インスタンスの設定の変更」をご参照ください。
ビジネスの安定性を確保するため、インスタンスをアップグレードする前に従量課金インスタンスを購入することを推奨します。 ストレステストと互換性テストを完了した後、インスタンスをリリースできます。
データノード間のCPU使用率の不一致
クラスターアーキテクチャまたは読み書き分離アーキテクチャを使用するApsaraDB for Redisインスタンスの特定のデータノードのCPU使用率が高く、他のノードのCPU使用率が低い場合は、次の手順を実行して問題をトラブルシューティングします。
トラブルシューティングと最適化ホットキー
トラブルシューティング手順
パフォーマンスモニタリング機能を使用して、CPU使用率が高い期間を特定します。 詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
[リアルタイムキー統計] ページの [履歴] タブで、CPU使用率が高いデータノードを選択し、手順1に基づいて時間フィルター条件を選択し、[検索] をクリックします。 時間範囲内で高いCPU使用率を示すホットキーを表示できます。 詳細については、「リアルタイムキー統計機能の使用」をご参照ください。
ソリューション
プロキシクエリキャッシュ機能を有効にします。 この機能を有効にすると、プロキシノードはホットキーのリクエストとレスポンスデータをキャッシュします。 プロキシノードがキャッシュされたデータの有効期間中に重複要求を受信した場合、プロキシノードはバックエンドデータシャードと対話する必要なしにクライアントに直接応答を返します。 これは、多数の読み取り要求を受信するホットキーによって引き起こされるスキューされた要求を防ぐのに役立ちます。 詳細については、「プロキシクエリキャッシュを使用したホットキーによる問題への対処」をご参照ください。
ホットキーが読み取り要求から生成された場合、インスタンスを読み書き分離インスタンスに変更して、インスタンスの各データシャードにかかる読み取り負荷を軽減できます。
説明多数のリクエストが読み書き分離インスタンスに送信された場合、特定の遅延量は避けられず、ダーティデータがインスタンスから読み取られる可能性があります。 したがって、読み書き分離アーキテクチャは、読み書き機能とデータの一貫性に対する要件が高いシナリオに最適なソリューションではありません。
CPU集中型コマンドのトラブルシューティングと無効化
トラブルシューティング手順
パフォーマンスモニタリング機能を使用して、CPU使用率が高い期間を特定します。 詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
次の方法でCPU負荷コマンドを識別します。
レイテンシインサイト機能は、ApsaraDB for Redisインスタンス上のすべてのコマンドとカスタム特別イベントのレイテンシを記録します。 さまざまなノード間で特定の期間にわたって収集されたレイテンシ情報に基づいて、応答時間が長いCPU負荷の高いコマンドを特定できます。 詳細については、「遅延インサイト」をご参照ください。
図 1. レイテンシインサイトの使用例
Slow logsは、指定されたしきい値より長く実行されるコマンドを記録します。 さまざまなノード間で特定の期間にわたって収集された低速クエリとその実行期間に基づいて、CPU負荷の高いコマンドを識別できます。 詳細については、「スローログの照会」をご参照ください。
図2. スローログクエリの例
解決策
FLUSHALL、KEYS、HGETALLなどのリスクの高いコマンドとCPU負荷の高いコマンドを評価および無効にします。 詳細については、「高リスクコマンドの無効化」をご参照ください。
トラブルシューティングと最適化大きなキー
トラブルシューティング手順
パフォーマンスモニタリング機能を使用して、CPU使用率が高い期間を特定します。 詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
[キャッシュ分析] ページで、[分析] をクリックします。 CPU使用率が高いデータノードを選択し、[OK] をクリックします。 時間範囲内で高いCPU使用率を示す大きなキーを表示できます。 詳細については、「オフラインキー分析機能の使用」をご参照ください。
解決策
実際のビジネス要件に基づいて大きなキーを小さなキーに分割し、リクエストの負荷を均等に分散します。
プロキシノード間のCPU使用率の不一致
クラスターアーキテクチャまたは読み書き分離アーキテクチャを使用するApsaraDB for Redisインスタンスの特定のプロキシノードのCPU使用率が高いのに対して、他のノードのCPU使用率が低い場合は、次の手順を実行して問題をトラブルシューティングします。
トラブルシューティング手順
[パフォーマンストレンド] ページの [プロキシノード] タブで、接続使用量が均等に分散されているかどうかを確認します。 詳細については、「パフォーマンスの傾向の表示」をご参照ください。
ソリューション
接続の使用状況が均等に分散されているかどうかに基づいて、次のいずれかの操作を実行します。
接続の使用状況が均等に分散されている場合は、接続を再分散するためにビジネスアプリケーションがデプロイされているクライアントまたはプロキシノードを再起動します。 プロキシノードを再起動する方法の詳細については、「プロキシノードの再起動または再構築」をご参照ください。
接続使用量が不均一に分散している場合、不均一な分散は通常、大規模なパイプラインまたはバッチ操作によって発生します。 たとえば、操作を複数の小さな操作に分割することで、パイプラインまたはバッチ操作の規模を縮小できます。