データスキューの処理 - Tair (Redis® OSS-Compatible) - Alibaba Cloud ドキュメントセンター

Tair (Redis OSS-compatible) のクラスターインスタンスにおいて、特定のデータノードのメモリ使用量、CPU 使用率、帯域幅使用量などのパフォーマンスメトリクスが他のデータノードよりも著しく高い場合、そのクラスターインスタンスにはデータスキューの問題が存在する可能性があります。インスタンスのデータが深刻に偏っている場合、インスタンスのメモリ使用量が低くても、キーの退去、メモリ不足 (OOM) エラー、応答の遅延などの例外が発生することがあります。

迅速な処理

このセクションでは、データスキューが存在するかどうかを確認し、ラージキーを特定して処理する方法について説明します。

インスタンス詳細ページの左側のナビゲーションウィンドウで、[CloudDBA] > [リアルタイムパフォーマンス] を選択し、メモリ使用率 メトリクスがデータノード間で均衡しているかを確認します。

この例では、db-0 データノードの メモリ使用率 が他のノードよりも著しく高く、データスキューを示しています。例えば、あるノードの [メモリ使用量] が 57% (9.22 GB) であるのに対し、他のノードが 33% (5.32 GB) である場合、データスキューが存在します。

説明
インスタンス診断機能を使用して、現在のインスタンスにデータスキューが存在するかどうかを確認することもできます。詳細については、「インスタンスの診断の実行」をご参照ください。
各データノードのキーの総数を表示します。
この例では、キーの総数は db-0 で 259 万、db-1 で 260 万、db-2 で 259 万です。キーはデータノード間で均等に分散されています。この場合、db-0 データノードにラージキーが存在する可能性が非常に高いです。
説明
キーがデータノード間で不均等に分散されている場合、ビジネスロジックにおけるキー名の設計に問題がある可能性があります。例えば、ハッシュタグを使用すると、巡回冗長検査 (CRC) アルゴリズムによる分散時に、クライアントがすべてのキーを同じデータノードにルーティングする原因となることがあります。この場合、キー名に {} を使用しないように、アプリケーションレベルで調整を行う必要があります。
オフラインキー分析機能を使用して、ラージキーを迅速に特定します。

この機能は、オンラインビジネスに影響を与えることなく、インスタンスのバックアップファイルを分析します。分析が完了すると、[上位 500 のラージキー] を表示できます。この例では、mylist という名前のキーがラージキーとして特定されています。

この list タイプのキーは quicklist エンコーディングを使用し、3.80 GB のメモリを消費し、約 204 万の要素を含んでいます。
(任意) 特定のデータノードに接続してクエリと分析を行います。
- プロキシモードのクラスターインスタンスの場合、Alibaba Cloud が独自に開発した ISCAN コマンドを使用して、指定されたデータノードで SCAN コマンドを実行できます。詳細については、「プロキシモードのインスタンスの独自コマンド」をご参照ください。
- 直接接続モードのクラスターインスタンスの場合、DescribeDBNodeDirectVipInfo 操作を呼び出して各データノードの仮想 IP アドレス (VIP) を取得し、クライアントをデータノードに接続して分析します。
次のいずれかのソリューションを使用します。
- 暫定的なソリューション：インスタンス仕様をアップグレードします。
- 長期的なソリューション (推奨)：ラージキーを適切に分割して、ビジネスロジックを再構築します。

データスキュー問題の原因とソリューションに関する詳細については、次のセクションをご参照ください。このトピックは、スタンダードインスタンスにおけるメモリ使用量、CPU 使用率、帯域幅使用量、レイテンシーなどの高いパフォーマンスメトリクスに関連する問題のトラブルシューティングにも適しています。

データスキューの原因

Tair (Redis OSS-compatible) のクラスターインスタンスは分散アーキテクチャを使用しています。クラスターインスタンスのストレージスペースは 16,384 のスロットに分割されます。各データノードは、特定のスロット内のデータを格納および処理します。例えば、3 シャードのクラスターインスタンスでは、スロットは 3 つのシャードに次のように分散されます。最初のシャードは [0,5460] の範囲のスロットを処理し、2 番目のシャードは [5461,10922] の範囲のスロットを処理し、3 番目のシャードは [10923,16383] の範囲のスロットを処理します。クラスターインスタンスにキーを書き込むか、クラスターインスタンスのキーを更新する場合、クライアントは次の数式を使用してキーが属するスロットを決定します：Slot=CRC16(key)%16384。その後、クライアントはキーをスロットに書き込みます。理論上、このメカニズムはキーをデータノード間で均等に分散させ、すべてのデータノードでメモリ使用量や CPU 使用率などのメトリクスの値をほぼ同じレベルに維持するのに十分です。

しかし、実際の運用では、事前の計画不足、異常なデータ書き込み、またはデータアクセスの急増により、データスキューが発生することがあります。

説明

通常、データスキューは、特定のデータノードのリソースが他のデータノードに比べて需要が高くなるときに発生します。コンソールの [パフォーマンスモニター] ページの データノード タブでデータノードのメトリクスを表示できます。あるデータノードのメトリクスが他のデータノードよりも一貫して 20% 高い場合、データスキューが存在する可能性があります。データスキューの深刻度は、異常なデータノードと正常なデータノードのメトリクスの差に比例します。
単一のデータノードのメモリ使用量が 100% に達すると、データノードはデータエビクションをトリガーします。デフォルトのエビクションポリシーは volatile-lru です。

次の図は、2 つの典型的なデータスキューのシナリオを示しています。キーがクラスターインスタンス全体に均等に分散されていても (データノードごとに 2 つのキー)、データスキューは依然として発生します。

Shard 1 データノード上の key1 の秒間クエリ数 (QPS) は、他のキーよりもはるかに高いです。これは データアクセススキュー のケースであり、データノードの高い CPU 使用率と帯域幅使用量につながる可能性があります。これは、データノード上のすべてのキーのパフォーマンスに影響します。
Shard 2 データノード上の key5 のサイズは 1 MB で、他のキーよりもはるかに大きいです。これは データ量スキュー のケースと見なされ、データノードの高いメモリおよび帯域幅使用量につながる可能性があります。これは、データノード上のすべてのキーのパフォーマンスに影響します。

暫定的なソリューション

インスタンスでデータスキューが発生した場合、短期的に問題を軽減するために暫定的なソリューションを実装できます。

問題	考えられる原因	暫定的なソリューション
メモリ使用量スキュー	ラージキーとハッシュタグ	インスタンス仕様をアップグレードします。詳細については、「インスタンス構成の変更」をご参照ください。重要システムは、インスタンス仕様の変更中にデータスキューの事前チェックを開始します。選択したインスタンスタイプがデータスキューの問題を処理できない場合、システムはエラーを報告します。より高い仕様のインスタンスタイプを選択して、もう一度お試しください。インスタンス仕様をアップグレードすると、メモリ使用量のスキューは軽減される可能性があります。ただし、帯域幅と CPU リソースでもスキューが発生する可能性があります。
帯域幅使用量スキュー	ラージキー、ホットキー、リソースを大量に消費するコマンド	1 つ以上のデータノードの帯域幅を増やします。詳細については、「インスタンス帯域幅の手動増加」をご参照ください。説明データノードの帯域幅は、インスタンスのデフォルト帯域幅の最大 6 倍まで増やすことができますが、帯域幅の増加は 192 Mbit/s を超えることはできません。この措置でもデータスキューの問題が解決しない場合は、アプリケーションレベルで調整を行うことを推奨します。
CPU 使用率スキュー	ラージキー、ホットキー、リソースを大量に消費するコマンド	ホットキーが異なるスロットに分散している場合は、オフピーク時にデータノードを追加して、システム全体の負荷をより均等に分散させます。リソースを大量に消費するコマンドを最適化します。例えば、各 SCAN コマンドで取得されるキーの数を減らします。説明スケーリング中に行われるデータ移行プロセスは、かなりの CPU リソースを消費する可能性があるため、オフピーク時にインスタンスをスケーリングしてください。

データスキューに一時的に対処するために、ラージキーやホットキーへのリクエストを減らすこともできます。ラージキーやホットキーに関連する問題を解決するには、アプリケーションレベルで調整を行う必要があります。インスタンスのデータスキューの原因を迅速に特定し、アプリケーションレベルで問題を処理してインスタンスのパフォーマンスを最適化することを推奨します。詳細については、このトピックの原因とソリューションセクションをご参照ください。

原因とソリューション

データスキューの根本原因を解決するために、ビジネスの成長を評価し、将来の成長に必要な準備を行うことを推奨します。ラージキーを分割し、予想される使用法に準拠した方法でデータを書き込むための措置を講じることができます。

原因	説明	ソリューション
ラージキー	ラージキーは、キーのサイズとキー内のメンバー数に基づいて識別されます。通常、ラージキーは Hash、List、Set、Zset などのキーバリューデータ構造で一般的です。ラージキーは、これらの構造が多数のフィールドまたは過度に大きいフィールドを格納するときに発生します。ラージキーは、データスキューの主な原因の 1 つです。ビジネスに影響を与えることなくラージキーやホットキーを安全に削除する方法の詳細については、「ラージキーとホットキーの特定と処理」をご参照ください。	ラージキーの発生を防ぎます。数万のメンバーを含むハッシュキーを、管理可能な数のメンバーを持つ複数のハッシュキーに分割します。
ホットキー	ホットキーは、他のキーよりもはるかに高い QPS 値を持つキーです。ホットキーは、単一キーでのストレステスト中や、人気のある商品 ID を含むタイムセールシナリオで一般的に見られます。ホットキーの詳細については、「ラージキーとホットキーの特定と処理」をご参照ください。	ホットキーの発生を防ぎます。プロキシクエリキャッシュ機能を使用して、ホットデータをキャッシュします。詳細については、「ステップ 2：ラージキーとホットキーの最適化」をご参照ください。
リソースを大量に消費するコマンド	各コマンドには、そのリソースと時間の消費を測定する時間計算量と呼ばれるメトリックがあります。ほとんどの場合、コマンドの時間計算量が高いほど、コマンドが消費するリソースは多くなります。例えば、`HGETALL` コマンドの時間計算量は O(n) です。これは、コマンドが指定されたフィールドの数に比例してリソースを消費することを示します。同様に、`SET` または `GET` コマンドが大量のデータ量を伴う場合、コマンドは大量のデータノードリソースを消費します。	データノードのスロークエリログをクエリします。詳細については、「スロークエリログのクエリ」をご参照ください。レイテンシーインサイト機能を使用して、大量のパフォーマンスリソースを消費するコマンドを表示します。詳細については、「レイテンシーインサイト」をご参照ください。リソース負荷の高いコマンドは使用しないでください。特定のコマンドを無効にするには、パラメーター設定ページで `#no_loose_disabled-commands` パラメーターを設定します。
ハッシュタグ	Tair は、キー名の `{}` 部分に含まれる内容に基づいて、キーを特定のデータノードに分散します。例えば、`{item}id1`、`{item}id2`、`{item}id3` のキーは、同じ `{}` の内容を共有しているため、同じデータノードに格納されます。その結果、このデータノードのメモリ使用量とリソース消費が大幅に増加します。	キー名に `{}` を使用しないでください。説明キー名に `{}` を使用する場合は、異なるキーが `{}` 内に異なる内容を持つようにしてください。これにより、キーを複数のデータノードに格納できます。

よくある質問

ラージキーを持つクラスターインスタンスで、ラージキーが存在するデータノードの仕様をアップグレードできますか？
いいえ。Tair (Redis OSS-compatible) では、個々のデータノードの仕様を個別にアップグレードすることはできません。インスタンス内のすべてのデータノードの仕様を同時にアップグレードすることのみが許可されています。
データノードを追加し、キーを再分散してクラスターインスタンス内のラージキーをなくすことはできますか？
いいえ。データノードを追加すると、既存のデータノードのメモリ負荷の一部を軽減するのに役立ちますが、Tair (Redis OSS-compatible) はキーレベルでデータを分散するため、ラージキーを自動的に分割することはできません。その結果、キーが再分散された後でも、1 つのデータノードが他のノードよりも高いメモリ使用量を持つ可能性があり、データスキューが発生します。推奨されるアプローチは、ラージキーをより小さなキーに手動で分割することです。