ApsaraDB for Redisインスタンスは、アプリケーションレイヤーに近いデータレイヤーで実行されます。 したがって、データはApsaraDB for Redisインスタンスに頻繁に書き込まれたり読み取られたりします。 これは、大量の帯域幅リソースを消費する。 ApsaraDB for Redisインスタンスで使用可能な最大帯域幅は、インスタンスタイプによって異なります。 ApsaraDB for Redisインスタンスの最大帯域幅を超えた場合、アプリケーションはインスタンスに存在するデータにアクセスできない可能性があります。
ステップ1: トラフィック使用量の分析
特定の期間内のApsaraDB for Redisインスタンスのトラフィック使用量を確認します。 詳細については、「パフォーマンスモニタリングデータの表示」をご参照ください。
この例では、次の図に示すように、受信方向と送信方向の両方のトラフィック使用量は100% のままです。
ほとんどの場合、平均トラフィック使用量が約80% にとどまる場合、帯域幅リソースが使い果たされる可能性があります。 問題に注意を払い、トラブルシューティングを行うことを推奨します。
イントラネットイン比率とイントラネットアウト比率を確認する必要があります。これらは、インバウンドトラフィック使用量とアウトバウンドトラフィック使用量を別々に示します。
図 1. トラフィック使用量
の例
ステップ2: トラフィック使用量の最適化
ApsaraDB for Redisインスタンスの帯域幅を調整して、ビジネスへの影響を軽減します。 これにより、問題のトラブルシューティングに時間がかかります。 詳細については、「インスタンスの帯域幅を手動で増やす」をご参照ください。
ユーザトラフィックの量が予想される帯域幅消費と一致しない場合があります。 たとえば、トラフィック使用量の増加傾向と1秒あたりのクエリ (QPS) の増加傾向は一貫していません。 この場合、オフラインキー分析機能を使用して、ApsaraDB for Redisインスタンス上の大きなキーを識別します。 詳細については、「オフラインキー分析機能の使用」をご参照ください。
大きなキーを最適化します。 キーは通常、サイズが10 KBを超えると大きなキーとして分類されます。 たとえば、大きなキーを分割したり、大きなキーへのアクセスを減らしたり、不要になった大きなキーを削除したりできます。
図2. 大きなキー分析
の例ApsaraDB For Redis enhanced Edition (Tair) のパフォーマンスが強化されたクラスターインスタンスの場合、プロキシクエリキャッシュを有効にして、ホットキーによって引き起こされる大量のトラフィックやスキューリクエストに対処します。 詳細については、「リアルタイムキー統計機能の使用」および「プロキシクエリキャッシュを使用してホットキーによる問題に対処する」をご参照ください。
オプション: クラスターインスタンスの場合、大量のネットワークトラフィックに対処するには、直接接続モードでクラスターインスタンスに接続します。 詳細については、「直接接続モードの有効化」をご参照ください。
説明直接接続モードでは、ApsaraDB for Redisインスタンスの帯域幅制限は、各データシャードの帯域幅制限にデータシャードの数を掛けたものに等しくなります。 たとえば、クラスターインスタンスに128個のデータシャードが含まれ、各データシャードの帯域幅制限が96 Mbit/sの場合、直接接続モードを有効にした後のクラスターインスタンスの帯域幅制限は12,288 Mbit/sになります。
上記の最適化を実行した後もトラフィック使用率が高い場合は、インスタンスをより多くのメモリを持つインスタンスタイプにアップグレードします。 アップグレードにより、インスタンスのパフォーマンスが向上し、より多くのトラフィックを処理できます。 詳細については、「インスタンスの設定の変更」をご参照ください。
説明ApsaraDB for Redisインスタンスをアップグレードする前に、従量課金インスタンスを購入して、アップグレード先の仕様がワークロードの要件を満たしているかどうかをテストできます。 テストの完了後、従量課金インスタンスをリリースできます。 詳細は、「インスタンスのリリース」をご参照ください。