Tair (および Redis Open-Source Edition) インスタンスの高い CPU 使用率は、通常、3 つの主な要因によって引き起こされます。第一に、高い同時実行性と高いスループットを持つサービスは、大量の CPU リソースを消費します。CPU リソースがボトルネックに達していない場合、これは正常と見なされます。第二に、サービス負荷が想定を超え、Redis Open-Source Edition インスタンスの CPU リソースがビジネス要件に対して不十分である場合です。このリソースのボトルネックは、シャードまたはレプリカの数を増やすか、Tair (Enterprise Edition) にアップグレードすることで解決できます。第三に、高消費コマンドの実行やホットキーまたは large キーへのアクセスなどの不適切な使用により、CPU 使用率が異常に高くなる場合です。平均 CPU 使用率が 70% を超えるか、連続 5 分間の平均ピーク CPU 使用率が 90% を超える場合は、アプリケーションが安定して実行されるように、迅速に問題を調査して解決する必要があります。
CPU 使用率が異常に高くなる原因
高消費コマンド: これらは、時間計算量が O(N) で、N が大きな値であるコマンドです。例としては、KEYS、HGETALL、または MGET、MSET、HMSET、HMGET を使用して一度に多くのキーを操作する場合などがあります。
Redis はシングルスレッドであるため、インスタンスで高消費コマンドを実行すると、他のコマンドがキューに入れられ、アプリケーションの応答が遅くなります。極端な場合、これによりインスタンス全体がブロックされ、アプリケーションのタイムアウトや、トラフィックがキャッシュレイヤーをバイパスしてバックエンドデータベースに直接ヒットし、アバランシェ効果を引き起こす可能性があります。
説明各コマンドの時間計算量の詳細については、「コマンド」をご参照ください。
ホットキー: 1 つ以上のキーへのアクセスリクエスト数が他のキーのそれを大幅に超えると、ホットキーが存在します。ホットキーはインスタンスの CPU リソースを大量に消費し、他のキーへのアクセスレイテンシに影響を与えます。クラスタアーキテクチャでは、ホットキーが少数のデータシャードに集中すると、CPU 使用率の偏りが発生し、一部のシャードの CPU 使用率が他のシャードよりもはるかに高くなる可能性があります。
Large キー: Large キーはより多くのメモリを占有します。Large キーにアクセスすると、インスタンスの CPU 負荷とネットワークトラフィックも大幅に増加します。Large キーはホットスポットになりやすく、高い CPU 使用率を引き起こします。Large キーが少数のデータシャードに集中すると、CPU 使用率、帯域幅使用量、メモリ使用量に偏りが生じる可能性があります。
短命な接続: 頻繁な接続の確立と終了は、接続処理のためにインスタンスのリソースを大量に消費します。
AOF: インスタンスでは、デフォルトで追記専用ファイル (AOF) が有効になっています。インスタンスが高負荷状態にある場合、AOF のディスク書き込み動作により、CPU 使用率とインスタンスの全体的な応答レイテンシが増加します。
CPU 使用率が異常に高くなるシナリオの分類
高い CPU 使用率は、通常、次の 3 つのシナリオのいずれかで発生します:
特定の期間中に、CPU 使用率が突然増加し、時には 100% に達します。トラブルシューティングと解決策については、「CPU 使用率の急増」をご参照ください。
1 つのデータノードの CPU 使用率が高く、他のデータノードの CPU 使用率が低い。トラブルシューティングと解決策については、「データノード間の CPU 使用率の不一致」をご参照ください。
1 つのプロキシノードの CPU 使用率が高く、他のプロキシノードの CPU 使用率が低い。トラブルシューティングと解決策については、「プロキシノード間の CPU 使用率の不一致」をご参照ください。
特定のシナリオに基づいて、CPU 使用率を削減するための対策を講じてください。
CPU 使用率の急増
インスタンスのグローバル CPU 使用率が突然増加した場合は、次の手順に従ってトラブルシューティングと最適化を行ってください。
高消費コマンドの検出と無効化
トラブルシューティングの手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高い特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
次のメソッドを使用して高消費コマンドを検出します:
レイテンシインサイト機能は、インスタンスのすべてのコマンドとカスタムイベントのレイテンシを記録します。指定した期間とノードのレイテンシ情報を使用して、レイテンシの長い高消費コマンドを見つけることができます。
図 1. レイテンシインサイトの例
スロークエリログ機能は、指定されたしきい値 (デフォルトでは 20 ms) よりも長く実行されるコマンドを記録します。指定した期間とノードのスロークエリ文と実行時間を使用して、実行時間の長い高消費コマンドを見つけることができます。
ソリューション
FLUSHALL、KEYS、HGETALL などの高リスクおよび高消費コマンドを評価して無効にします。詳細については、「高リスクコマンドを無効にする」をご参照ください。
オプション: ビジネスニーズに基づいて、次のいずれかのメソッドを使用してインスタンスを調整します:
インスタンスを読み書き分離アーキテクチャに変更して、高消費コマンドまたはアプリケーションをオフロードします。
インスタンスをTair メモリ最適化タイプに変更して、そのマルチスレッド機能を使用して CPU 使用率を削減します。
説明インスタンスのアーキテクチャとタイプの変更方法の詳細については、「インスタンスの構成を変更する」をご参照ください。
短命な接続の検出と最適化
トラブルシューティングの手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高い特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
パフォーマンスモニタリングページで、CPU 使用率と接続数は高いが、クエリ/秒 (QPS) が予想よりも低いかどうかを確認します。その場合、短命な接続が存在する可能性があります。以下の解決策を参照してください。
ソリューション
JedisPool 接続プールを使用するなどして、短命な接続を持続的接続に変更できます。詳細については、「クライアント接続チュートリアル」をご参照ください。
インスタンスをTair メモリ最適化タイプに変更できます。Tair メモリ最適化インスタンスには、短命な接続の最適化機能があります。
AOF の無効化
インスタンスでは、デフォルトで AOF が有効になっています。インスタンスが高負荷状態にある場合、頻繁な AOF 操作によって CPU 使用率が増加する可能性があります。
ビジネスロジックで許容される場合は、永続化を無効にすることを検討できます。また、インスタンスのデータバックアップをトラフィックの少ない期間やメンテナンスタイムウィンドウにスケジュールして、影響を軽減することもできます。
インスタンスがTair メモリ最適化タイプの場合、AOF を無効にすると AOF ファイルからデータを復元できなくなります。これは、データフラッシュバック機能が利用できなくなることを意味します。バックアップセットから新しいインスタンスにデータを復元することしかできません。注意して進めてください。
サービスキャパシティの評価
上記の手順でトラブルシューティングと最適化を行った後でも、通常運用中にインスタンス全体の負荷が依然として頻繁に高い (平均 CPU 使用率が 70% を超える) 場合は、パフォーマンスボトルネックが存在する可能性があります。
まず、異常なコマンドや特定のアプリケーションホストからの異常なアクセスなど、異常なビジネスアクセスがないか確認します。これらの問題は、アプリケーションレベルでの最適化が必要です。すべてのアクセスが正常である場合、高負荷はビジネスの動作の正常な結果です。安定した運用を確保するために、インスタンスの仕様をアップグレードするか、クラスタアーキテクチャまたは読み書き分離アーキテクチャにアップグレードできます。インスタンスのアップグレード方法の詳細については、「インスタンスの構成を変更する」をご参照ください。
通常のビジネス運用を確保するために、インスタンスをアップグレードする前に、従量課金インスタンスを購入して負荷テストと互換性テストを完了してください。テスト完了後、インスタンスをリリースできます。
データノード間の CPU 使用率の不一致
インスタンスがクラスタアーキテクチャまたは読み書き分離アーキテクチャを使用しており、一部のデータシャードノードの CPU 使用率が高く、他のノードの CPU 使用率が低いことがわかった場合は、次の手順に従ってトラブルシューティングと最適化を行うことができます。
ホットキーの検出と最適化
トラブルシューティングの手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高い特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
トップキースタッツの履歴ページで、CPU 使用率の高いデータノードを選択します。次に、ステップ 1 で特定した期間に基づいて、時間フィルターを選択し、[表示] をクリックします。この期間にどのホットキーが存在したかを確認できます。
ソリューション
ユーザー ID や時間範囲など、ビジネスロジックに基づいてホットキーを分割します。
ホットキーが読み取りリクエストによって生成される場合は、インスタンスを読み書き分離アーキテクチャに変更して、各データシャードへの読み取りリクエストの圧力を軽減できます。
説明リクエスト量が非常に多いシナリオでは、読み書き分離アーキテクチャには避けられないレプリケーションレイテンシがあり、ダーティデータの読み取りにつながる可能性があります。したがって、このアーキテクチャは、読み書きの圧力が高く、データ整合性に対する要件が厳しいシナリオには最適なソリューションではありません。
高消費コマンドの検出と無効化
トラブルシューティングの手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高い特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
次のメソッドを使用して高消費コマンドを検出します:
レイテンシインサイト機能は、インスタンスのすべてのコマンドとカスタムイベントのレイテンシを記録します。指定した期間とノードのレイテンシ情報を使用して、レイテンシの長い高消費コマンドを見つけることができます。
図 1. レイテンシインサイトの例
スロークエリログ機能は、指定されたしきい値 (デフォルトでは 20 ms) よりも長く実行されるコマンドを記録します。指定した期間とノードのスロークエリ文と実行時間を使用して、実行時間の長い高消費コマンドを見つけることができます。
ソリューション
FLUSHALL、KEYS、HGETALL などの高リスクおよび高消費コマンドを評価して無効にします。詳細については、「高リスクコマンドを無効にする」をご参照ください。
Large キーの検出と最適化
トラブルシューティングの手順
パフォーマンスモニタリング機能を使用して、CPU 使用率が高い特定の期間を特定します。詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
オフラインフルキー分析ページで、[今すぐ分析] をクリックします。CPU 使用率の高いデータノードを選択し、[OK] をクリックします。この期間にどの large キーが存在したかを確認できます。
ソリューション
ビジネスニーズに基づいて、large キーをより小さなキーに分割して、リクエストの圧力を分散させることができます。
プロキシノード間の CPU 使用率の不一致
インスタンスがクラスタアーキテクチャまたは読み書き分離アーキテクチャを使用しており、一部のプロキシノードの CPU 使用率が高く、他のプロキシノードの CPU 使用率が低いことがわかった場合は、次の手順に従ってトラブルシューティングと最適化を行うことができます。
トラブルシューティングの手順
パフォーマンストレンドのプロキシノードページで、接続数の使用量が均等であるかどうかを確認します。
ソリューション
接続の使用量が均等であるかどうかに基づいて、次の対策を講じます:
接続の使用量が均等な場合: サービスのクライアントまたはプロキシノードを再起動して、接続を再割り当てします。プロキシノードを再起動するには、「プロキシノードの再起動または再構築」をご参照ください。
接続の使用量が不均等な場合: これは通常、大きすぎる pipeline または batch 操作が原因です。これらの操作を複数の小さな操作に分割するなどして、規模を縮小できます。