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