Tair プロキシの機能とルーティングルール - Tair (Redis® OSS-Compatible)

クラスターアーキテクチャまたは読み書き分離アーキテクチャを使用する Tair (Redis OSS-compatible) インスタンスでは、プロキシノードがリクエストのルーティング、負荷分散、フェールオーバーを担当します。プロキシノードは、クライアント側のロジックを簡素化し、複数データベース (DB) やホットキーのキャッシュなどの高度な機能をサポートします。プロキシノードのルーティングルールと特定のコマンドの処理方法を理解することは、より効率的な業務システムの設計に役立ちます。

プロキシノードの概要

プロキシノードは、Tair インスタンス内のスタンドアロンコンポーネントです。データシャードのリソースを消費しません。Tair は複数のプロキシノードを使用して、負荷分散とフェールオーバーを実装します。

機能	説明
クラスターインスタンスの使用モードの移行	プロキシノードはアーキテクチャ間の橋渡しをすることができ、スタンドアロンインスタンスのようにクラスターアーキテクチャインスタンスを使用できます。プロキシノードは、DEL、EXISTS、MGET、MSET、SDIFF、UNLINK などの複数のキーを管理するコマンドのクロススロット操作をサポートします。詳細については、「プロキシモードでサポートされるコマンドのリスト」をご参照ください。スタンドアロンアーキテクチャのインスタンスがビジネス要件を満たせなくなった場合、コードを変更することなく、プロキシノードを持つクラスターアーキテクチャのインスタンスにデータを移行できます。これにより、ビジネスの移行コストを大幅に削減できます。
負荷分散とリクエストルーティング	プロキシノードは、バックエンドのデータシャードとの接続保持を確立し、リクエストのルーティングと負荷分散を処理します。ルーティングの詳細については、「プロキシノードのルーティングルール」をご参照ください。
読み取り専用レプリカへのトラフィック管理	プロキシノードは、読み取り専用レプリカの状態を継続的に監視し、次の状況でトラフィックを制御します：読み取り専用レプリカが異常な状態にある場合：プロキシノードはレプリカのサービスウェイトを減らします。プロキシノードがレプリカへの接続に複数回失敗した場合、レプリカへのトラフィック送信を停止します。プロキシノードは、レプリカが回復した後にトラフィックの送信を再開します。読み取り専用レプリカが完全なデータ同期を実行している場合：プロキシノードは、同期が完了するまでレプリカへのトラフィック送信を一時的に停止します。
プロキシクエリキャッシュ	プロキシクエリキャッシュ機能を有効にすると、プロキシノードはホットキーを含むリクエストとそれに対応する応答をキャッシュします。プロキシノードがキャッシュ有効期間内に同じリクエストを受信すると、バックエンドのデータシャードとやり取りすることなく、結果を直接クライアントに返します。これは、ホットキーへの大量の読み取りリクエストによって引き起こされるアクセススキューを軽減するのに役立ちます。説明この機能は、query_cache_enabled パラメーターを設定することで有効にできます。この機能は、Tair メモリ最適化インスタンスおよび永続メモリ最適化インスタンスでのみ利用可能です。
複数データベース (DB) のサポート	クラスターモードでは、ネイティブ Redis およびクラスタークライアントは複数データベース (DB) をサポートしません。デフォルトのデータベース `0` のみを使用し、`SELECT` コマンドはサポートされません。ただし、プロキシノードを介してクラスターインスタンスに接続して、複数の DB と `SELECT` コマンドを使用できます。Cluster Edition インスタンスは、デフォルトで 256 個の DB をサポートします。説明 StackExchange.Redis クライアントを使用する場合、バージョン 2.7.20 以降を使用する必要があります。そうしないと、エラーが発生します。詳細については、「StackExchange.Redis のアップグレードに関するお知らせ」をご参照ください。

説明

プロキシ技術の進化に伴い、プロキシノードの数だけが処理能力を決定する要因ではありません。Alibaba Cloud は、クラスターインスタンス内のプロキシノードの比率が指定された要件を満たすことを保証します。

プロキシノードのルーティングルール

説明

コマンドの詳細については、「コマンドの概要」をご参照ください。

アーキテクチャ	ルーティングルール	説明
クラスターアーキテクチャ	基本的なルーティングルール	単一のキーを操作するコマンドの場合、プロキシノードはキーが属するスロットに基づいて、対応するデータシャードにリクエストを送信します。異なるデータシャードに保存されている複数のキーを操作するコマンドの場合、プロキシノードはコマンドを複数のコマンドに分割し、対応するシャードに送信します。説明 Redis オープンソース版 5.0.1 以降、およびバージョン 6.0、7.0 以降では、プロキシノードは Redis コミュニティと一致して、スロットレベルでコマンドを分割します。ただし、5.0.1 より前の Redis オープンソース版 5.0 のマイナーバージョン、およびバージョン 4.0 と 2.8 では、プロキシはシャードレベルでコマンドを分割します。これらのインスタンスが Redis オープンソース版 5.0 以降にアップグレードされると、コマンド分割ルールの変更により QPS が増加し、トラフィックがわずかに増加する可能性があります。ただし、プロキシはパイプラインを使用してコマンドを配信するため、パフォーマンスへの影響は比較的小さいです。
クラスターアーキテクチャ	特定のコマンドのルーティングルール	Pub/Sub コマンド Pub/Sub コマンド (例：SUBSCRIBE) の場合、プロキシノードはチャンネル名のハッシュを計算し、対応するデータシャードにリクエストをルーティングします。Pub/Sub コマンドはデータベースにデータを書き込みませんが、メモリとリソースを消費します。この消費は、主にクライアント接続、サブスクリプション状態の管理、およびメッセージバッファによるものです。たとえば、チャンネルがデータシャード 1 に属している場合、このチャンネルをサブスクライブするクライアントは、データシャード 1 のメモリ、CPU、およびネットワーク帯域幅を消費します。説明 Tair コンソールで、[パフォーマンスモニタリング] ページに移動し、[データノード] を選択してから、カスタムメトリックリストから [Pub/Sub モニタリンググループ] を選択します。これにより、各データシャード上の Pub/Sub 関連コマンドのモニタリング情報を表示できます。デフォルトでは、最初のデータシャードのデータが表示されます。 Alibaba Cloud 開発コマンド IINFO や ISCAN などの Alibaba Cloud 開発コマンドを使用する場合、idx パラメーターを使用してデータシャード ID を指定できます。プロキシノードは、これらのコマンドを指定されたデータシャードに送信します。詳細については、「Alibaba Cloud 開発プロキシコマンド」をご参照ください。
読み書き分離アーキテクチャ	基本的なルーティングルール	書き込みリクエスト：プロキシノードは書き込みリクエストをマスターノードに直接転送します。読み取りリクエスト：プロキシノードは、マスターノードと読み取り専用レプリカの間で読み取りリクエストを均等に分散します。分散のカスタマイズはサポートされていません。たとえば、1 つのマスターノードと 3 つの読み取り専用レプリカを持つインスタンスでは、4 つのノードのそれぞれが読み取りリクエストの 25% を処理します。説明 SLOWLOG および DBSIZE も読み取りコマンドと見なされます。
読み書き分離アーキテクチャ	特定のコマンドのルーティングルール	SCAN コマンド HSCAN、SSCAN、または ZSCAN コマンドを実行すると、プロキシノードはまずキーが属するスロットを計算します。次に、剰余演算を使用してターゲットノードを決定します。これにより、リクエストがマスターノードと読み取り専用レプリカの間で均等に分散されることが保証されます。 Alibaba Cloud 開発コマンド RIINFO や RIMONITOR などの Alibaba Cloud 開発コマンドを使用する場合、ro_slave_idx パラメーターを使用してターゲットの読み取り専用レプリカを指定し、idx パラメーターを使用してデータシャードを指定します。詳細については、「Alibaba Cloud 開発プロキシコマンド」をご参照ください。その他のコマンドプロキシノードは、トランザクションコマンド (MULTI または EXEC)、Lua スクリプトコマンド (EVAL または EVALSHA)、SCAN、INFO、および Pub/Sub コマンド (PUBLISH や SUBSCRIBE など) をマスターノードに転送します。

プロキシクエリキャッシュ

プロキシノードは、ホットキーを含むリクエストとそれに対応するクエリ結果をキャッシュできます。プロキシノードがキャッシュ有効期間内に同じリクエストを受信すると、バックエンドのデータシャードとやり取りすることなく、結果を直接クライアントに返します。この機能は、ホットキーへの大量の読み取りリクエストによるアクセススキューによって引き起こされるパフォーマンスの低下を軽減または防止できます。

データベースカーネルは、[Top Key Analytics] 機能の Hot Key (QPS) と同様に、ソートおよび統計アルゴリズムを使用してホットキーを識別します。デフォルトでは、QPS が 5,000 を超える場合、キーはホットキーとして識別されます。このしきい値は、bigkey-threshold パラメーターを使用してカスタマイズすることもできます。
ホットキーのデータがキャッシュされている間に変更された場合、変更はキャッシュに同期されません。つまり、後続のリクエストは、キャッシュエントリの有効期限が切れるまで、キャッシュから古いデータを読み取る可能性があります。ビジネス要件に基づいて、キャッシュ有効期間を短縮できます。

説明

プロキシノードはホットキー全体をキャッシュするのではなく、ホットキーを含むリクエストと対応するクエリ結果をキャッシュします。
この機能は、プロキシモードのクラスターアーキテクチャまたは読み書き分離アーキテクチャを使用する Tair メモリ最適化インスタンスおよび永続メモリ最適化インスタンスでのみ利用可能です。

利用シーン

この機能は、トレンドトピックリスト、人気のあるユーザープロファイル、ゲームのお知らせなど、アプリケーションがわずかに古いデータを許容できるシナリオに適しています。

アーキテクチャ

使用方法

この機能はデフォルトで無効になっています。パラメーター query_cache_enabled を設定することで有効にできます。

パラメーター

パラメーター	説明

query_cache_enabled
query_cache_expire
query_cache_mode

Tair 開発の QUERYCACHE KEYS、QUERYCACHE INFO、および QUERYCACHE LISTALL コマンドを使用して、Tair プロキシクエリキャッシュの使用状況を表示できます。

コマンド

QUERYCACHE KEYS

構文： QUERYCACHE KEYS

説明：プロキシノードにキャッシュされているすべてのホットキーをクエリします。このコマンドは、各ホットキーのデータベース名とキー名を返します。

例：

QUERYCACHE KEYS

サンプル応答：

1) 1) (integer) 0
   2) "key:000000000003"
2) 1) (integer) 0
   2) "key:000000000001"
3) 1) (integer) 0
   2) "key:000000000002"
4) 1) (integer) 0
   2) "key:000000000000"

QUERYCACHE INFO

構文： QUERYCACHE INFO

説明：プロキシクエリキャッシュの動作ステータスを取得します。

例：

QUERYCACHE INFO

サンプル応答：

1) "put_qps:4.00"
2) "get_qps:16570.00"
3) "hit_rate:99.98"
4) "memory_size:180"
5) "query_count:4"
6) "bandwidth_limit_query_cnt:0"
7) "qps_limit_query_cnt:0"

応答フィールド：

put_qps：データノードからプロキシクエリキャッシュへの 1 秒あたりの書き込み数。
get_qps：クライアントによるプロキシクエリキャッシュからの 1 秒あたりの読み取り数。
hit_rate：キャッシュヒット率。
memory_size：キャッシュされたデータのメモリ使用量 (バイト単位)。
query_count：キャッシュされたリクエストの数。
bandwidth_limit_query_cnt：帯域幅制限によりプロキシクエリキャッシュへのアクセスがスロットルされた回数。スロットリングはデフォルトで無効になっています。
qps_limit_query_cnt：QPS 制限によりプロキシクエリキャッシュへのアクセスがスロットルされた回数。スロットリングはデフォルトで無効になっています。

QUERYCACHE LISTALL

構文： QUERYCACHE LISTALL

説明：キャッシュされているすべてのリクエストコマンドを取得します。

例：

QUERYCACHE LISTALL

サンプル応答：

1) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000000\r\n"
   3) (integer) 668
2) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000001\r\n"
   3) (integer) 668
3) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000003\r\n"
   3) (integer) 668
4) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000002\r\n"
   3) (integer) 667

サンプル応答の説明: 各リクエストコマンドの情報は、データベース名、リクエストコマンドの完全な内容 (Redis プロトコル仕様に従ってフォーマット)、およびミリ秒単位の残りの生存時間 (TTL) の 3 行で構成されます。

接続の使用量

通常、プロキシノードはデータシャードとの接続保持を確立してリクエストを処理します。ただし、リクエストに次のいずれかのコマンドが含まれている場合、プロキシノードはコマンドの要件に基づいて、対応するデータシャード上に追加の集約不可能な接続を作成します。これらの場合、インスタンスの最大接続数は、単一のデータシャードの接続制限によって制限されます。単一シャードの接続制限については、ご利用のインスタンスの仕様をご参照ください。接続制限を超えないように、これらのコマンドは注意して使用してください。

説明

プロキシモードでは、各データシャードの最大接続数は、Redis オープンソース版インスタンスでは 10,000、 Tair (Enterprise Edition) インスタンスでは 30,000 です。

ブロッキングコマンド：BRPOP、BRPOPLPUSH、BLPOP、BZPOPMAX、BZPOPMIN、BLMOVE、BLMPOP、および BZMPOP。
トランザクションコマンド：MULTI、EXEC、および WATCH。
MONITOR コマンド：MONITOR、IMONITOR、および RIMONITOR。
サブスクリプションコマンド：SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE、SSUBSCRIBE、および SUNSUBSCRIBE。

よくある質問

読み取り操作のみを実行する Lua スクリプトを読み取り専用レプリカに転送できますか？
はい、読み取り操作のみを実行する Lua スクリプトを読み取り専用レプリカに転送できます。ただし、次の要件を満たす必要があります：
- 読み取り専用アカウントが使用されていること。詳細については、「アカウントの作成と管理」をご参照ください。
- Tair インスタンスで readonly_lua_route_ronode_enable パラメーターが 1 に設定されていること。値が 1 の場合、読み取り操作のみを実行する Lua スクリプトが読み取り専用レプリカにルーティングされることを示します。詳細については、「インスタンスパラメーターの設定」をご参照ください。
Q: プロキシモードと直接接続モードの違いは何ですか？どちらのモードが推奨されますか？
A: プロキシモードの使用を推奨します。違いは次のとおりです：
- プロキシモード：プロキシノードがクライアントリクエストをデータシャードに転送します。このモードは、負荷分散、読み書き分離、フェールオーバー、プロキシクエリキャッシュ、接続保持などの機能を提供します。
- 直接接続モード：直接接続エンドポイントを使用してプロキシノードをバイパスし、バックエンドのデータシャードに直接接続できます。これは、ネイティブ Redis クラスターへの接続に似ています。プロキシモードと比較して、直接接続モードはプロキシ処理のオーバーヘッドを削減し、レスポンスレイテンシーを向上させます。

Q: バックエンドのデータシャードが利用できなくなった場合、データの読み取りと書き込みはどのように影響を受けますか？

各データシャードは、高可用性のマスター/レプリカアーキテクチャを使用します。マスターノードで障害が発生した場合、システムは自動的にフェールオーバーを実行して高可用性を確保します。次の表では、極端なシナリオでのデータシャードの障害がデータの読み取りと書き込みに与える影響について説明し、最適化ソリューションを提示します。

シナリオ	影響と最適化
図 1. 複数キーコマンド	影響：クライアントは 4 つの接続を介して 4 つのリクエストを送信します。データシャード 2 が利用できない場合、リクエスト 1 (GET Key1) のみがデータを正常に読み取ることができます。データシャード 2 にルーティングされたリクエストはタイムアウトします。最適化： MGET などの複数キーコマンドの使用を減らすか、単一リクエスト内のキーの数を減らします。これにより、単一の利用できないデータシャードが原因でリクエスト全体が失敗するのを防ぎます。トランザクションコマンドの使用を減らすか、トランザクションのサイズを小さくします。これにより、サブトランザクションの失敗が原因でトランザクション全体が失敗するのを防ぎます。
図 2. 単一接続	影響：クライアントは単一の接続を介して 2 つの個別のリクエストを送信します。データシャード 2 が利用できない場合、リクエスト 2 (GET Key2) はタイムアウトします。リクエスト 1 (GET Key1) は同じ接続を共有しているため、結果を返すこともできません。最適化：パイプラインの使用を避けるか減らします。単一接続のみをサポートするクライアントの使用を避けます。コネクションプーリングをサポートするクライアントを使用することを推奨します。詳細については、「クライアント接続チュートリアル」をご参照ください。適切なタイムアウトと接続プールサイズを設定してください。