総リクエスト数が過大
ダウンロード
フォーカスモード
フォントサイズ
現象記述
現象1：QPS指標が高いです。
現象2：応答遅延が大きくなります。
現象3：接続タイムアウトを引き起こす可能性があります。
考えられる原因
自身のビジネスは最適化が必要です。
インスタンス設定はアップグレードが必要です。
解決の考え方
ノードの負荷を確認します：クラスタアーキテクチャの場合、ノードの負荷状況を確認します。1つまたは少数のノードのQPSのみがアラート値を超えている場合は、ホットKeyが存在する可能性があります。大部分のノードが超えている場合は、全体の負荷が高いことを示しており、この場合はインスタンス設定のアップグレードを検討します。
スロークエリの確認：コンソールを開いてスロークエリが存在するかどうかを確認できます。存在し、かつ時間が問題発生の時間と一致する場合は、大きいKeyの問題が存在する可能性があります。
CPU使用率の確認：CPU使用率が高すぎるかどうかを確認できます。高すぎる場合はマシンリソースが不足している可能性があり、インスタンス設定のアップグレードを検討できます。
判断を経て、業務の最適化が必要な場合は、ホットKey、大Keyに対して最適化できます。インスタンス設定のアップグレードが必要な場合は、読み書き分離を有効化し、シャードを追加することで現在のビジネス要件を満たすことができます。
処理手順
1. Distributed Cacheコンソールにログインします。
2. インスタンス一覧で、目的のインスタンスを見つけ、インスタンスIDをクリックし、インスタンス管理ページに移動します。
3. インスタンス管理ページで、システム監視タブを選択し、DBrainページで、データベースの健全性状態を確認し、QPSが高すぎるか、または突発的なホットKeyがあるかを確認します。
4. 異常アクセスを調査した後、ビジネスロジックを最適化します。
ホットKeyの場合、複雑なデータ構造を分割し、ホットKeyを複数の新しいKeyに分割して異なるRedisノードに分散させることで、負荷を軽減できます。ハッシュ型を例にすると、このホットKeyの型は二次データ構造であり、このハッシュの要素数が多い可能性があるため、現在のhashを分割することを検討できます。
大Keyの場合、valueが大きすぎる場合は、オブジェクトを複数のkey-valueに分割し、操作の負荷を複数のRedisインスタンスに分散できます。Keyが多すぎる場合は、hash構造による格納を参考にし、複数のKeyを1つのhash構造に格納できます。
インスタンスのアップグレード
インスタンスのアップグレード
読み取り負荷が過大なシーン
注意：
読み書き分離を有効にすると、データの読み取り不整合が発生する可能性があります（レプリカノードのデータがプライマリノードより遅延します）。業務上、データ不整合の問題が許容されるかどうかを事前に確認してください。
書き込み負荷が過大なシーン
クラスタアーキテクチャ
説明：
設定変更後、インスタンスは新しいスペックに基づいて課金されます。
シャードを追加すると、システムが自動的にSlot設定を均衡化し、データを移行します。移行操作は失敗する可能性があるため、業務アクセスへの影響を避けるために、業務の低ピーク時に操作することをお勧めします。
各シャードが提供可能なQPSは8W～10Wです。必要に応じて追加してください。
標準アーキテクチャ
クラスタ版へのアップグレードによりCPU処理能力を向上させます。クラスタへのアップグレード前に互換性を確認する必要があります。詳細は標準アーキテクチャからクラスタアーキテクチャへの移行チェックをご覧ください。
1. Distributed Cacheコンソールにログインし、インスタンス一覧でインスタンスIDをクリックして、インスタンス詳細ページに進みます。
2. インスタンス詳細ページのスペック情報で、アーキテクチャアップグレードをクリックします。
3. クラスタアーキテクチャをアップグレードした後、インスタンス一覧に戻り、操作列の構成変更 > シャード追加を選択します。
説明：
フィードバック