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

ApsaraDB for Redisクラスターインスタンスと読み書き分離インスタンスは、プロキシノードを使用してコマンドのルーティング、負荷のバランス、およびフェイルオーバーを実行します。プロキシノードは、複数のデータベースへの接続の処理やホットキーデータのキャッシュなどの高度な機能をサポートしながら、クライアント側のロジックを簡素化するのに役立ちます。プロキシノードがコマンドをルーティングし、特定のコマンドを処理する方法を確実に理解することで、より効率的なビジネスシステムを設計できます。

プロキシノードの概要

プロキシノードは、ApsaraDB for Redisインスタンスのスタンドアロンアーキテクチャで実行されるコンポーネントです。プロキシノードはデータシャードのリソースを占有しません。 ApsaraDB for Redisインスタンスは、複数のプロキシノードを使用して負荷のバランスを取り、フェイルオーバーを実行します。

機能	説明
アーキテクチャ変革	プロキシノードを使用すると、標準インスタンスと同じ方法でクラスターインスタンスを使用できます。プロキシノードは、DEL、EXISTS、MGET、MSET、SDIFF、UNLINKなどのコマンドの異なるハッシュスロットにわたるマルチキー操作をサポートします。詳細については、「」「クラスターインスタンスと読み書き分離インスタンスでサポートされているコマンドの制限」をご参照ください。ビジネス要件が標準インスタンスで提供できる機能を超えた場合、コストを削減するためにコードを変更することなく、標準インスタンスのデータをプロキシノードを持つクラスターインスタンスに移行できます。
ロードバランシングとコマンドルーティング	プロキシノードは、バックエンドデータシャードとの永続的な接続を確立して、ロードとルーティングコマンドのバランスを取ります。詳細については、「」「プロキシノードのルーティング方法」をご参照ください。
読み取りレプリカへのトラフィックの管理	プロキシノードは、各リードレプリカのステータスをリアルタイムで監視します。読み取りレプリカが次のいずれかの状態にある場合、プロキシノードは読み取りレプリカへのトラフィックのルーティングを停止します。異常: 読み取りレプリカに異常がある場合、プロキシノードは読み取りレプリカへのトラフィックの重みを減らします。読み取りレプリカの接続が指定された回数失敗した場合、プロキシノードは、読み取りレプリカが再び正常になるまで、読み取りレプリカへのトラフィックのルーティングを停止します。完全データ同期: プロキシノードが読み取りレプリカで完全データが同期されていることを検出した場合、プロキシノードは、同期が完了するまで、読み取りレプリカへのトラフィックのルーティングを停止します。
Hotkeyデータキャッシュ	プロキシクエリキャッシュ機能を有効にすると、プロキシノードはホットキーのリクエストとレスポンスデータをキャッシュします。プロキシノードがキャッシュの有効期間内に同じリクエストを複数回受信した場合、プロキシノードは、バックエンドデータシャードと対話することなく、キャッシュされた結果をクライアントに直接返します。これは、ホットキーに対する多数の読み取り要求によって引き起こされるデータアクセススキューを防止する。詳細については、「」「プロキシクエリキャッシュを使用してホットキーによる問題に対処する」をご参照ください。説明この機能は、Tair DRAMベースおよび永続メモリ最適化インスタンスでのみ使用できます。
複数のデータベースのサポート	クラスターモードでは、複数のデータベースはオープンソースのRedisまたはRedisクラスタークライアントでサポートされません。この場合、デフォルトのデータベース`0`のみを使用でき、`SELECT`コマンドはサポートされていません。プロキシノードを使用してクラスターインスタンスにアクセスできます。この場合、複数のデータベースを使用でき、`SELECT`コマンドがサポートされます。デフォルトでは、単一のクラスターインスタンスに対して256のデータベースを指定できます。説明 StackExchange.Redisクライアントを使用する場合は、StackExchange.Redis 2.7.20以降を使用します。そうしないと、エラーが発生します。詳細については、「」「StackExchange.Redis更新通知」をご参照ください。

説明

プロキシ技術が進化するにつれて、クラスタインスタンス内のプロキシノードの数だけがプロキシノードの処理能力を決定するのではない。 Alibaba Cloudは、プロキシノードの割り当てと設定が仕様に記載されている要件を満たしていることを保証します。

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

説明

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

アーキテクチャ	ルーティング方法	説明
クラスターアーキテクチャ	基本的なルーティング方法	プロキシノードが個々のキーを管理するコマンドを受信すると、プロキシノードは、キーが属するハッシュスロットを識別し、ハッシュスロットが存在するデータシャードにコマンドをルーティングする。プロキシノードが異なるシャードに格納された2つ以上のキーを管理するコマンドを受信すると、プロキシノードはコマンドを複数のコマンドに分割し、コマンドを対応するシャードにルーティングします。
クラスターアーキテクチャ	特定のコマンドのルーティング方法	Pub/SubコマンドプロキシノードがPUBLISHやSUBSCRIBEなどのPub/Subコマンドを受信すると、プロキシノードはチャネル名をハッシュし、コマンドを対応するデータシャードにルーティングします。説明データシャードのPub/Subモニタリングデータを表示するには、Tairコンソールの [パフォーマンスモニター] ページのデータノードタブをクリックし、カスタムメトリクスとして Pub/Sub モニタリンググループを選択します。デフォルトでは、最初のデータシャードのPub/Subデータが表示されます。詳細については、「」「パフォーマンスモニタリングデータの表示」をご参照ください。自己開発コマンドプロキシノードがAlibaba Cloudが社内で開発したIINFOやISCANなどのコマンドを受信し、データシャードIDがidxパラメーターで指定されている場合、プロキシノードはコマンドを指定されたデータシャードにルーティングします。詳細については、「」「プロキシモードのApsaraDB For Redisインスタンスの社内コマンド」をご参照ください。
読み書き分離アーキテクチャ	基本的なルーティング方法	プロキシノードは、書き込みコマンドをマスターノードにルーティングします。システムは、読み取り要求をマスターノードと読み取りレプリカに均等に分散します。これらのノードの重みは変更できません。たとえば、3つのリードレプリカを持つインスタンスを購入した場合、マスターノードと3つのリードレプリカの重みはすべて25% です。説明 SLOWLOG と DBSIZE は読み取りコマンドです。
読み書き分離アーキテクチャ	特定のコマンドのルーティング方法	SCANコマンドプロキシノードがHSCAN、SSCAN、またはZSCANコマンドを受信すると、プロキシノードは、関与するキーが存在するスロットを計算し、マスターノードおよびすべての読み取りレプリカに対してモジュロ演算を実行し、次いで、コマンドを対応するノードにルーティングする。自己開発コマンド RIINFOやRIMONITORなど、Alibaba Cloudが社内で開発したコマンドをプロキシノードが受信すると、プロキシノードはコマンドをro_slave_idxパラメーターで指定されたリードレプリカとidxパラメーターで指定されたデータシャードにルーティングします。詳細については、「」「プロキシモードのApsaraDB For Redisインスタンスの社内コマンド」をご参照ください。その他のコマンドプロキシノードは、トランザクションコマンド (MULTIやEXECなど) 、Luaスクリプトコマンド (EVALやEVALSHAなど) 、SCANコマンド、INFOコマンド、Pub/Subコマンド (PUBLISHやSUBSCRIBEなど) をマスターノードにルーティングします。

接続数

通常、プロキシノードは、要求を処理するためにデータシャードとの永続的な接続を確立します。リクエストに次のいずれかのコマンドが含まれている場合、プロキシノードは必要に応じてデータシャードとの追加の接続を確立します。この場合、インスタンスの最大接続数と1秒あたりの新規接続の最大数は、直接接続モードの単一データシャードの最大接続数の影響を受けます。これは、このシナリオでは接続を集約できないためです。インスタンスの仕様を参照して、1つのデータシャードの最大接続数を表示できます。次のコマンドを実行するときは、各データシャードへの接続数が上限を超えないようにしてください。

説明

プロキシモードでは、Community Editionインスタンスは各データシャードへの最大10,000の接続を許可し、Enhanced Edition () インスタンスは各データシャードへの最大30,000の接続を許可します。

ブロックコマンド: BRPOP、BRPOPLPUSH、BLPOP、BZPOPMAX、BZPOPMIN、BLMOVE、BLMPOP、BZMPOP。
トランザクションコマンド：MULTI、EXEC、WATCH。
監視コマンド：MONITOR、IMONITOR、RIMONITOR。
Pub/Subコマンド: SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE、SSUBSCRIBE、SUNSUBSCRIBE。

よくある質問

読み取り操作のみを実行するLuaスクリプトを読み取りレプリカに転送できますか?
はい、読み取り操作のみを実行するLuaスクリプトを読み取りレプリカに転送できます。ただし、次の要件を満たす必要があります。
- 読み取り専用アカウントが使用されます。詳細については、「」「データベースアカウントの作成と管理」をご参照ください。
- Tairインスタンスのreadonly_lua_route_ronode_enableパラメーターは1に設定されています。値1は、読み取り操作のみを実行するLuaスクリプトが読み取りレプリカにルーティングされることを示します。詳細については、「」「インスタンスパラメーターの設定」をご参照ください。
プロキシモードと直接接続モードの違いは何ですか? どのモードが推奨されますか?
プロキシモードの使用を推奨します。プロキシモードとダイレクト接続モードの違いを次に示します。
- プロキシモード: プロキシノードは、クライアントからのリクエストをインスタンス内のデータシャードに転送します。このモードでは、負荷分散、読み書き分離、フェールオーバー、プロキシクエリキャッシュ、永続接続などの機能を提供します。
- 直接接続モード: このモードでは、プライベートエンドポイントを使用してプロキシノードをバイパスし、ネイティブRedisクラスターに接続するのと同じ方法でクライアントからApsaraDB for Redisインスタンスに接続できます。プロキシモードと比較して、直接接続モードは、要求を処理するためにプロキシノードを使用する必要性を排除する。これにより、ApsaraDB for Redisの応答速度をある程度高速化できます。

異常なデータシャードはデータの読み取りと書き込みにどのように影響しますか?

A: 各データシャードは、高可用性のマスターレプリカアーキテクチャで実行されます。マスターノードに障害が発生した場合、システムは高可用性を確保するためにワークロードをレプリカノードに切り替えます。次の表は、特定のシナリオでのデータの読み取りと書き込みに対する異常なデータシャードの影響と、各シナリオの最適化方法を示しています。

シナリオ	インパクトと最適化
図2. 複数のキーを管理するコマンド	影響: クライアントは4つの接続で4つの要求を送信します。 Data Shard 2が異常の場合、Data Shard 2にルーティングされるリクエストに対してタイムアウトエラーが返されます。クエリされたデータは、リクエスト1のGET Key1に対してのみ返されます。最適化メソッド: MGETなどの複数のキーを管理するコマンドの使用頻度を減らすか、リクエストによって管理されるキーの数を減らします。これにより、単一のデータシャードが異常であるという理由だけで、すべてのリクエストが失敗するわけではありません。トランザクションコマンドの使用頻度を減らすか、トランザクションサイズを減らします。このように、サブトランザクションが失敗した場合、トランザクション全体が失敗することはありません。
図3. シングル接続	影響: クライアントは同じ接続を介して2つの要求を送信します。 Data Shard 2が異常の場合、リクエスト1のGET Key1とリクエスト2のGET Key2のタイムアウトエラーが返されます。この例では、リクエスト1はリクエスト2と同じ接続を使用するため失敗します。最適化メソッド: パイプラインの使用を最小限に抑えます。レタスなど、単一の接続のみをサポートするクライアントを使用しないでください。 Jedisなどの接続プールをサポートするクライアントを使用することを推奨します。 Jedisを使用する場合は、適切なタイムアウト期間と接続プールサイズを設定する必要があります。 Jedisの詳細については、「クライアントを使用したApsaraDB For Redisインスタンスへの接続」をご参照ください。