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

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

プロキシの概要

プロキシサーバーは、Tair インスタンス内で単一ノードアーキテクチャを使用するコンポーネントです。データシャードのリソースを消費せず、複数のプロキシノードを通じて負荷分散とフェールオーバーを実現します。

プロキシの機能	説明
クラスターインスタンスの使用パターンの変換	プロキシノードを使用すると、標準インスタンスと同じ方法でクラスターインスタンスを使用できます。プロキシは、DEL、EXISTS、MGET、MSET、SDIFF、UNLINK などのコマンドに対して、スロットをまたいだ複数キー操作をサポートします。詳細については、「プロキシモードでサポートされるコマンドのリスト」をご参照ください。標準アーキテクチャがビジネスの成長をサポートできなくなった場合、コードを変更することなく、標準アーキテクチャからプロキシを備えたクラスタアーキテクチャにデータを移行できます。これにより、ビジネスの変換コストが大幅に削減されます。
負荷分散とルーティング	プロキシはバックエンドのデータシャードとの持続的接続を確立し、負荷を分散してリクエストを転送します。転送ルールについての詳細は、「プロキシノードのルーティングメソッド」をご参照ください。
読み取り専用ノードのトラフィック管理	プロキシは読み取り専用ノードの状態をリアルタイムで検出します。以下の状況が発生した場合、プロキシはトラフィック制御アクションを実行します：読み取り専用ノードが異常状態の場合：プロキシはノードのサービスウェイトを減らします。プロキシがノードへの接続に複数回失敗した場合、ノードのサービスを停止します。これは、トラフィックがそのノードに転送されなくなることを意味します。問題が解決されると、プロキシはノードを再度有効にします。読み取り専用ノードが完全同期を実行中の場合：プロキシは完全同期が完了するまで、ノードのサービスを一時的に停止します。
プロキシクエリキャッシュ	プロキシクエリキャッシュ (Proxy Query Cache) 機能を有効にすると、プロキシはホットキーのリクエストとその応答をキャッシュします。プロキシがキャッシュ有効期間内に同じリクエストを受信すると、バックエンドのデータシャードとやり取りすることなく、クライアントに直接結果を返します。これにより、ホットキーに対する多数の読み取りリクエストによって引き起こされるアクセススキューを軽減できます。説明この機能を有効にするには、query_cache_enabled パラメーターを設定します。この機能は、Tair のメモリ最適化インスタンスおよび永続メモリインスタンスでのみサポートされています。
複数データベース (DB) のサポート	クラスターモードでは、ネイティブ Redis およびクラスタークライアントは複数データベース (DB) をサポートしません。デフォルトのデータベース `0` のみを使用し、`SELECT` コマンドをサポートしません。ただし、プロキシを介してクラスターインスタンスにアクセスすることで、複数データベース (DB) と `SELECT` コマンドを使用できます。デフォルトでは、クラスターインスタンスは 256 個の DB を提供します。説明 StackExchange.Redis クライアントを使用する場合、StackExchange.Redis 2.7.20 以降のバージョンを使用してください。そうしないと、エラーが発生します。詳細については、「StackExchange.Redis アップグレードのお知らせ」をご参照ください。

説明

プロキシの進化により、プロキシの数が直接その処理能力を表すわけではありません。Alibaba Cloud は、クラスターインスタンスタイプにおけるプロキシの比率が、インスタンスタイプの説明で指定された要件を満たすことを保証します。

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

説明

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

アーキテクチャ	ルーティングルール	説明
クラスタアーキテクチャ	基本的なルーティングルール	単一キーを操作するコマンドの場合、プロキシはキーのスロットに基づいて対応するデータシャードにリクエストを送信します。複数キーを操作するコマンドで、キーが異なるデータシャードに保存されている場合、プロキシはコマンドを複数のコマンドに分割し、それぞれのシャードに送信します。説明 Redis Community Edition 5.0 のマイナーバージョン 5.0.1 以降、およびバージョン 6.0、7.0 以降では、プロキシは Redis コミュニティと一致して、スロットレベルでコマンドを分割します。ただし、Redis Community Edition 5.0 の 5.0.1 より前のマイナーバージョン、およびバージョン 4.0 と 2.8 では、プロキシはシャードレベルでコマンドを分割します。これらのインスタンスを Redis Community Edition 5.0 以降にスペックアップすると、コマンド分割ルールの変更により、秒間クエリ数 (QPS) が増加し、トラフィックがわずかに増加する可能性があります。ただし、プロキシはパイプラインを使用してコマンドを配信するため、パフォーマンスへの影響は比較的小さいです。
クラスタアーキテクチャ	特定のコマンドのルーティングルール	Publish/Subscribe コマンド PUBLISH や SUBSCRIBE などの Publish/Subscribe コマンドの場合、プロキシはチャンネル名に対してハッシュ計算を行い、対応するデータシャードにコマンドをルーティングします。Pub/Sub コマンドはデータベースにデータを書き込みませんが、それでも一部のメモリとリソースを消費します。リソース消費は主にクライアント接続、サブスクリプション状態管理、メッセージバッファにあります。たとえば、あるチャンネルがデータシャード 1 に属している場合、このチャンネルをサブスクライブするクライアントはデータシャード 1 のメモリ、CPU、およびネットワーク帯域幅を使用します。説明コンソールのパフォーマンスモニタリングページで、データノードを選択し、カスタム監視項目を Pub/Subモニタリンググループに設定すると、各データシャードの Publish/Subscribe (Pub/Sub) コマンドの監視情報を表示できます (デフォルトでは、最初のデータシャードが表示されます)。 Alibaba Cloud 独自開発コマンド IINFO や ISCAN など、Alibaba Cloud が開発したコマンドを使用する場合、idx パラメーターを使用してデータシャード ID を指定すると、プロキシはこれらのコマンドを指定されたデータシャードに送信します。詳細については、「自己開発のプロキシコマンド」をご参照ください。
読み書き分離アーキテクチャ	基本的なルーティングルール	書き込みリクエスト：プロキシはこれらをプライマリノード (Master) に直接転送します。読み取りリクエスト：プロキシは読み取りリクエストをプライマリノードと読み取り専用ノードの間で均等に分散します。カスタム制御はサポートされていません。たとえば、3つの読み取り専用ノードを持つインスタンスでは、プライマリノードと各読み取り専用ノードの読み取りウェイトは 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、および Publish/Subscribe コマンド (例：PUBLISH、SUBSCRIBE) をプライマリノードに転送します。

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

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

このホットキーは、トップキー統計機能のホットキー (QPS) と同じです。これは、データベースカーネルがソートおよび統計アルゴリズムに基づいて識別します。デフォルトでは、秒間クエリ数 (QPS) が 5,000 を超えるキーがホットキーと見なされます。このしきい値は、bigkey-threshold パラメーターを使用してカスタマイズすることもできます。
ホットキーがキャッシュ有効期間中に変更された場合、その変更はキャッシュに同期されません。つまり、後続のリクエストはキャッシュが有効期限切れになるまで、キャッシュからダーティデータを読み取る可能性があります。これに対処するには、必要に応じてキャッシュ有効期間を短縮できます。

説明

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

利用シーン

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

機能アーキテクチャ

使用方法

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

詳細な説明の表示

パラメーター	説明

query_cache_enabled	プロキシノードのクエリキャッシュ機能。有効にすると、プロキシノードはホットキーのリクエストとクエリ結果をキャッシュします。有効期間内に同じリクエストを受信した場合、プロキシノードはバックエンドのデータシャードとやり取りすることなく、クライアントに直接結果を返します。重要プロキシノードにキャッシュされたホットキーのキーと値のペアは、有効期間中は更新されません。この機能を有効にする前に、ご利用の業務がキャッシュ有効期間内のデータの結果整合性を許容できることを確認してください。 query_cache_enabled：この機能を有効にするかどうかを指定します。有効値は 0 (無効、デフォルト) と 1 (有効) です。 query_cache_expire：キャッシュデータの有効期間。単位はミリ秒です。範囲は [100-60000] です。デフォルトは 1000 です。キャッシュデータが有効期間中に変更された場合、その変更はキャッシュに同期されません。つまり、同じ読み取りリクエストはキャッシュが有効期限切れになるまで、キャッシュからダーティデータを取得します。特定の業務シナリオとダーティデータへの許容度に基づいて、このパラメーターの値を慎重に評価する必要があります。この値を低く設定しすぎるとキャッシュヒット率が低下し、高く設定しすぎるとクライアントが長期間ダーティデータを読み取ることになります。 query_cache_mode：プロキシノードのクエリキャッシュ機能の動作モード。有効値： 0 (デフォルト)：データシャードからプッシュされたホットキーのみをキャッシュします。 1：すべてのキーをキャッシュし、Least Recently Used (LRU) アルゴリズムに基づいてキーを削除します。プロキシノードのキャッシュスペースは限られているため (スレッドあたり 100 MB)、このパラメーターを 1 に設定すると、プロキシノードは LRU アルゴリズムに従ってキーを削除します。これにより、キャッシュヒット率が低下し、全体的なパフォーマンスが低下する可能性があります。
query_cache_expire
query_cache_mode

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

使用状況の表示

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

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 Community Edition インスタンスの接続数上限はデータシャードあたり 10,000 です。(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 クラスターへの接続に似ています。プロキシモードと比較して、直接接続モードはプロキシ経由でリクエストを処理する時間を節約し、Redis サービスの応答速度をある程度向上させることができます。

Q：バックエンドのデータシャードが異常になった場合、データの読み書きにどのような影響がありますか？

A：データシャードはプライマリ/セカンダリ高可用性アーキテクチャを使用しています。プライマリノードに障害が発生した場合、システムは自動的にプライマリ/セカンダリフェールオーバーを実行し、高いサービス可用性を確保します。まれにデータシャードが異常になった場合、データへの影響と最適化ソリューションは以下の通りです。

シナリオ	影響と最適化ソリューション
図 1. 複数キーコマンドのシナリオ	影響：クライアントは4つの接続を介して4つのリクエストを送信します。データシャード 2 が異常な場合、リクエスト 1 (GET Key1) のみが正常にデータを読み取ることができます。データシャード 2 にアクセスする他のリクエストはタイムアウトします。最適化ソリューション： MGET などの複数キーコマンドの使用頻度を減らすか、単一リクエスト内のキーの数を減らします。これにより、単一の異常なデータシャードが原因でリクエスト全体が失敗するのを防ぎます。トランザクションコマンドの使用頻度を減らすか、トランザクションのサイズを小さくします。これにより、失敗したサブトランザクションが原因でトランザクション全体が失敗するのを防ぎます。
図 2. 単一接続のシナリオ	影響：クライアントは単一の接続を介して2つの個別のリクエストを送信します。データシャード 2 が異常な場合、リクエスト 2 (GET Key2) はタイムアウトします。リクエスト 1 (GET Key1) とリクエスト 2 は同じ接続を共有しているため、リクエスト 1 も正常に返されません。最適化ソリューション： pipeline の使用を避けるか、減らします。単一接続のクライアントの使用を避け、代わりにクライアントプログラム接続チュートリアルで説明されているように、接続プールを持つクライアントを使用します (適切なタイムアウトと接続プールサイズを設定する必要があります)。