ApsaraDB for Redisを使用すると、大きなキーやホットキーをタイムリーに識別して処理しないと、パフォーマンスの低下、ユーザーエクスペリエンスの低下、さらには大規模な障害が発生する可能性があります。 このトピックでは、大きなキーとホットキーの原因、大きなキーとホットキーによって引き起こされる可能性のある問題、大きなキーとホットキーをタイムリーに識別して最適化する方法について説明します。
大きなキーとホットキーの定義
期間 | 説明 |
大きなキー | キーのサイズとキーのメンバー数によって、キーが大きなキーと見なされるかどうかが決まります。 次のリストにいくつかの例を示します。 サイズが大きいキーは、大きなキーと見なされます。 たとえば、サイズが5 MBのSTRINGキーは大きなキーと見なされます。 多数のメンバーを有するキーは、大きなキーとみなされる。 たとえば、10,000のメンバーを持つZSETキーは大きなキーと見なされます。 メンバーデータのサイズが大きいキーは、大きなキーと見なされます。 例えば、HASHキーは、キーが2,000のメンバーしか有していないが、これらのメンバーの合計サイズが100 MBである場合、大きなキーと見なされる。
|
hotkey | キーが要求される頻度は、キーがホットキーと見なされるかどうかを決定する。 次のリストにいくつかの例を示します。 1秒間に大量のクエリ (QPS) を受け取るキーは、ホットキーと見なされます。 たとえば、Tair インスタンスの合計QPSが10,000で、インスタンス内の1つのキーが7,000 QPSを受け取る場合、そのキーはホットキーと見なされます。 高い帯域幅使用量を有するキーは、ホットキーとみなされる。 たとえば、数千のメンバーを持ち、サイズが1 MBのHASHキーが1秒あたり多数のHGETALLコマンドを受信した場合、そのキーはホットキーと見なされます。 CPU使用率が高いキーはホットキーと見なされます。 たとえば、数万のメンバーを持つZSETキーが1秒あたりに多数のZRANGEコマンドを受信した場合、そのキーはホットキーと見なされます。
|
説明 前述の例で提供される特定の値は、参照のみのためであり、現実世界のシナリオに基づいて変化し得る。
大きなキーとホットキーによる問題
カテゴリ | 説明 |
大きなキー | クライアントがコマンドを実行するのに時間がかかります。 ApsaraDB for Redisインスタンスのメモリ使用量がmaxmemoryパラメーターで指定された上限に達すると、操作がブロックされたり、重要なキーが削除されたり、メモリ不足 (OOM) エラーが発生したりする可能性があります。 ApsaraDB for Redisクラスターインスタンスのデータシャードのメモリ使用量が他のデータシャードのメモリ使用量をはるかに上回っているため、インスタンス内のデータシャード間でメモリ使用量が不均衡になります。 大きなキーに対して読み取り要求が行われると、応答時間が増加し、他のサービスが影響を受ける可能性があります。 これは、キーが属するApsaraDB for Redisインスタンスの帯域幅が使い果たされたためです。 1次データベースは、大きなキーが削除されている間、長期間ブロックされる可能性があります。 これは、同期障害またはマスター-レプリカ切り替えにつながる可能性があります。
|
ホットキー | ホットキーは大量のCPUリソースを消費するため、通常のキーのリクエストへの応答が遅くなり、ApsaraDB for Redisインスタンスのパフォーマンスが低下します。 リクエストスキューは、ApsaraDB for Redisクラスターインスタンスで発生する可能性があります。 リクエストスキューは、インスタンス内の1つのデータシャードが多数のリクエストを受信し、インスタンス内の他のデータシャードがアイドル状態のままである場合に発生します。 この状況では、データシャードへの接続の最大数に達することができ、シャードへの新しい接続は拒否されることができる。 フラッシュセール中に、商品に対応するキーがApsaraDB for Redisで処理できるよりも多くのリクエストを受け取ると、過剰販売が発生する可能性があります。 ホットキーがApsaraDB for Redisで処理できるよりも多くのリクエストを受信した場合、キャッシュの内訳が発生します。 この場合、大量のリクエストがバックエンドストレージに直接送信され、バックエンドストレージの故障が発生する可能性があります。 これは他のビジネスに影響します。
|
大きなキーとホットキーの原因
ApsaraDB for Redisの誤った使用、不十分なワークロード計画、無効なデータの蓄積、トラフィックの急増など、さまざまな理由で大きなキーやホットキーが発生する可能性があります。
大きなキー
ApsaraDB for Redisの不正使用: 不適切なシナリオでApsaraDB for Redisが使用されている場合、キーのサイズが必要以上に大きくなる可能性があります。 例えば、サイズが大きいバイナリファイルを格納するためにSTRINGキーが使用される場合、キーのサイズは必要以上に大きくなり得る。
不十分なワークロード計画: 機能がリリースされる前に、ワークロードを十分に計画できないと問題が発生する可能性があります。 例えば、メンバーがキー間で適切に分割されない場合があり、一部のキーは必要以上のメンバーを有する場合がある。
無効なデータの蓄積: 無効なデータが定期的に削除されない場合に発生します。 例えば、無効なデータが適時にクリアされない場合、HASHキーのメンバの数は常に増加する。
コード障害: LISTキーを使用するコンシューマアプリケーションでコード障害が発生し、キーのメンバーが増加するだけです。
ホットキー
大きなキーとホットキーを特定する
ApsaraDB for Redisには、大きなキーとホットキーを識別するためのさまざまな方法があります。
移動方法 | 利点と欠点 | 説明 |
リアルタイムキー統計機能の使用 (推奨) | | リアルタイムキー統計機能を使用すると、インスタンス内の大きなキーとホットキーの統計をリアルタイムで表示できます。 過去4日間に生成された大きなキーとホットキーの履歴統計を照会することもできます。 この機能を使用して、メモリ使用量やアクセス頻度などの主要な統計を取得できます。 次に、統計に基づいて問題をトラブルシューティングし、インスタンスを最適化できます。 |
オフラインキー分析機能の使用 | | オフラインキー分析機能を使用すると、ApsaraDB for RedisインスタンスのRDBバックアップファイルをカスタマイズして分析し、これらのインスタンス内の大きなキーを特定できます。 キーのメモリ使用量、分布、生存時間 (TTL) など、インスタンス内のキーの統計を表示できます。 これらの統計を使用して、インスタンスを最適化し、キーの不適切な配布によるメモリ不足やパフォーマンスの低下などの問題を防ぐことができます。 |
redis-cliでbigkeysパラメーターとhotkeysパラメーターを使用して、大きなキーとホットキーを識別する | | redis-cliは、bigkeysおよびhotkeysパラメーターを提供します。これらを使用して、Redisインスタンス内のすべてのキーをスキャンして分析できます。 これらのパラメーターは、キーに関する包括的な統計を提供し、各データ型の最大のキーを識別します。 bigkeysは、STRING、LIST、HASH、SET、ZSET、STREAMの6種類のデータのみを分析して提供できます。サンプルコマンド: redis-cli -h r-****************** .redis.rds.aliyuncs.com -a <password> -- bigkeys
説明 STRING型の大きなキーのみを分析したり、メンバーが10を超えるHASHキーを特定したりする場合、bigkeysパラメーターはニーズを満たすことができません。 |
ApsaraDB for Redisの組み込みコマンドを使用して特定のキーを分析する | | 次のセクションでは、さまざまなデータ型のキーを分析して、キーが大きなキーであるかどうかを判断するための低リスクコマンドを示します。 STRINGキーの場合は、STRLENコマンドを実行します。 このコマンドは、キーに格納されている文字列値の長さ (バイト数) を返します。 LISTキーの場合は、LLENコマンドを実行します。 このコマンドは、キーに格納されているリスト値の長さを返します。 HASHキーの場合は、HLENコマンドを実行します。 このコマンドは、キー内のメンバーの数を返します。 SETキーの場合は、SCARDコマンドを実行します。 このコマンドは、キー内のメンバーの数を返します。 ZSETキーの場合は、ZCARDコマンドを実行します。 このコマンドは、キー内のメンバーの数を返します。 STREAMキーの場合は、XLENコマンドを実行します。 このコマンドは、キー内のメンバーの数を返します。
説明 DEBUG OBJECTおよびMEMORY USAGEコマンドは、実行時に大量のリソースを消費します。 さらに、これらのコマンドの時間複雑度はO(N) です。これは、これらのコマンドがApsaraDB for Redisインスタンスをブロックする可能性があることを示しています。 したがって、これらのコマンドは使用しないことを推奨します。 |
ビジネスレイヤーでホットキーを特定する | | この方法では、コードをビジネスレイヤーに追加して、ApsaraDB for Redisインスタンスに送信されたリクエストを記録し、収集した統計を非同期で分析できます。 |
redis-rdb-toolsプロジェクトを使用して、カスタマイズした方法で大きなキーを識別する | | redis-rdb-toolsプロジェクトはPythonプログラミング言語で記述されています。 redis-rdb-toolsは、カスタマイズされた方法でRedis RDBファイルを分析するために使用できるオープンソースツールです。 ApsaraDB for Redisインスタンスのすべてのキーのメモリ使用量を分析し、各キーの統計をきめ細かくクエリおよび分析できます。 |
MONITORコマンドを使用してホットキーを識別する | | ApsaraDB for Redisで使用できるMONITORコマンドは、インスタンスに関連するすべてのリクエストの統計 (時間、クライアント、コマンド、キーに関する統計など) を表示できます。 緊急の場合は、MONITORコマンドを実行して出力をファイルにエクスポートできます。 MONITORコマンドを無効にした後、出力のリクエストを分析して分類し、緊急期間中に生成されたホットキーを特定できます。
説明 ただし、MONITORコマンドを使用すると、ApsaraDB for Redisインスタンスのパフォーマンスが大幅に低下します。 特別な場合にのみMONITORコマンドを使用することを推奨します。 |
大きなキーとホットキーを最適化する
カテゴリ | 最適化方法 |
大きなキー | 大きなキーを分割 たとえば、数万のメンバーを含むHASHキーを、それぞれ適切な数のメンバーを持つ複数のHASHキーに分割できます。 ApsaraDB For Redisクラスターインスタンスの場合、大きなキーを分割して、複数のデータシャード間でメモリ使用量のバランスを取ることができます。 大きなキーを削除する ApsaraDB for Redisに適していないデータを他のストレージエンジンに保存したり、ApsaraDB for Redisからデータを削除したりできます。
説明 Redis 4.0以降: UNLINKコマンドを実行すると、大きなキーまたは超大きなキーを安全に削除できます。 このコマンドを使用すると、ApsaraDB for Redisからキーを徐々に削除して、ApsaraDB for Redisがブロックされないようにすることができます。 Redis 4.0より前: SCANコマンドを実行してデータを読み取り、データを削除できます。 ApsaraDB for Redisがブロックされないようにするには、一度に多数のキーを削除しないことを推奨します。
ApsaraDB for Redisのメモリ使用量のモニタリング モニタリングシステムで、ApsaraDB for Redisインスタンスのメモリ使用量に適したアラートしきい値を指定できます。 たとえば、ApsaraDB For Redisインスタンスのメモリ使用量のアラートしきい値として70% を指定し、1時間にわたるインスタンスのメモリ使用量の増加のアラートしきい値として20% を指定できます。 これにより、潜在的な問題を防ぐことができます。 たとえば、事前にアラートを生成するしきい値を設定して、LISTキーを使用するコンシューマーアプリケーションの障害によるキー数の増加を防ぐことができます。 詳細については、「アラート設定」をご参照ください。 期限切れのデータを定期的に削除する 期限切れのデータの蓄積は大きなキーにつながります。 たとえば、大量のデータをHASHキーに増分的に書き込み、データのTTLを無視すると、HASHキーが大きなキーになることがあります。 スケジュール済みタスクを使用して、無効なデータを削除できます。
説明 無効なハッシュデータを削除したときにApsaraDB for Redisがブロックされないようにするには、HSCANおよびHDELコマンドを実行することを推奨します。 ApsaraDB for Redis Enhanced Edition (Tair) の使用 多数のHASHキーがあり、一部のキーから多数の無効なメンバーを削除する場合、スケジュールされたタスクは無効なメンバーをタイムリーに削除できません。 この場合、Tairを使用できます。 Tairは、オープンソースのRedisのすべての機能と、さまざまな新しい高度な機能を提供します。 Tairは、TairHashデータ構造を提供します。 TairHashは、TTLとバージョン番号をフィールドに指定できるHASHデータ型です。 TairHashは、Redis HASHと同様に、さまざまなデータインターフェイスと高い処理パフォーマンスを提供します。 ただし、Redis HASHでは、キーにTTLのみを指定できます。 TairHashでは、バージョン番号を指定することもできます。 TairHashはより柔軟で、ほとんどのシナリオでビジネス開発を簡素化します。 さらに、TairHashはアクティブ有効期限アルゴリズムを使用してフィールドのTTLをチェックし、期限切れのフィールドを削除します。 このプロセスでは、データベースの応答時間は増加しません。 このような高度な機能を使用して、O&Mの効率を向上させ、トラブルシューティングのワークロードを削減し、ビジネスコードを簡素化できます。 詳細については、「exHash」をご参照ください。
|
ホットキー | ApsaraDB for Redisクラスターインスタンスのホットキーの複製 ApsaraDB for Redisクラスターインスタンスでホットキーを移行できる最小単位がキーであるため、データシャード内のホットキーに対して行われたリクエストをインスタンス内の他のデータシャードに再配布することはできません。 これにより、単一のデータシャードに対して常に高いワークロードが発生します。 この場合、データシャードでホットキーをレプリケートして同一のキーを生成し、これらの新しいキーを他のデータシャードに移行できます。 たとえば、fooという名前のホットキーをデータシャードにレプリケートして、foo2、foo3、およびfoo4という名前の3つの同じホットキーを生成できます。 次に、foo2、foo3、およびfoo4を他のデータシャードに移行して、fooを含むデータシャードへの負荷を軽減できます。
説明 この方法の欠点は、対応するコードを変更する必要があり、1つのキーではなく複数のキーを更新する必要があるため、データの不整合が発生する可能性があることです。 このため、この方法は一時的な解決策としてのみ検討することをお勧めします。 読み書き分離アーキテクチャの使用 読み取りリクエストの蓄積によってホットキーが発生する場合は、インスタンスを読み書き分離インスタンスに変更して、インスタンスの各データシャードの読み取り負荷を軽減するか、インスタンスのレプリカノードの数を増やすことができます。 ただし、読み書き分離アーキテクチャでは、ビジネスコードとApsaraDB for Redisクラスターインスタンスの両方の複雑さが増します。 プロキシやLinux Virtual server (LVS) などのサーバー負荷分散ツールを複数のレプリカノードに提供し、レプリカノード数の大幅な増加に起因する障害率の増加に対処する準備をする必要があります。 ApsaraDB for Redisインスタンスをクラスターインスタンスに変更すると、モニタリング、Q&M、トラブルシューティングにおいて大きな課題が発生する可能性があります。 これらの課題に対応して、ApsaraDB for Redisはすぐに使えるソリューションを提供します。 ニーズの進化に伴い、マスターレプリカインスタンスを読み書き分離インスタンスに、読み書き分離インスタンスをクラスターインスタンスに、Community Editionインスタンスを多数の高度な機能を提供するEnhanced Edition (Tair) インスタンスに変換するなど、構成を変更することで、インスタンスアーキテクチャを変更できます。 詳細については、「インスタンスの設定の変更」をご参照ください。
説明 読み出し /書き込み分割アーキテクチャにも欠点がある。 多数のリクエストが読み書き分離インスタンスに送信されると、ある程度の遅延が避けられず、インスタンスからダーティデータが読み取られる可能性があります。 したがって、読み書き分離アーキテクチャは、読み書き機能とデータの一貫性に対する要件が高いシナリオに最適なソリューションではありません。 Tairのプロキシクエリキャッシュ機能を使用する Tair（Redis OSS-compatible）は、効果的なソートと統計アルゴリズムを使用してホットキーを識別します。ホットキーは、1秒あたり5,000クエリ (QPS) を超えるキーです。 プロキシクエリキャッシュ機能を有効にすると、プロキシノードは設定したルールに基づいてホットキーのリクエストとレスポンスデータをキャッシュします。 プロキシノードは、キー全体ではなく、ホットキーの要求および応答データのみをキャッシュします。 プロキシノードがキャッシュされたデータの有効期間内に重複要求を受信した場合、プロキシノードは、バックエンドデータシャードと対話する必要なしに、要求の応答をクライアントに直接返す。 これにより、読み取り速度が向上し、ホットキーがデータシャードのパフォーマンスに与える影響が軽減され、リクエストの偏りが防止されます。 ApsaraDB for Redisインスタンスでプロキシクエリキャッシュ機能を有効にすると、クライアントからの重複リクエストがバックエンドデータノードではなくプロキシノードに直接送信されます。 次に、プロキシノードはクライアントに応答を返す。 ホットキーに対して行われたリクエストは、単一のデータノードではなく、複数のプロキシノードによって処理できます。 これにより、データノードのホットキーのワークロードが大幅に削減されます。 Tairのプロキシクエリキャッシュ機能には、プロキシクエリキャッシュをクエリおよび管理するためのさまざまなコマンドも用意されています。 たとえば、querycache keysコマンドを実行してキャッシュされたすべてのホットキーを照会し、querycache listallコマンドを実行してキャッシュされたすべてのコマンドを照会できます。 詳細については、「プロキシクエリキャッシュを使用してホットキーによる問題に対処する」をご参照ください。
|