すべてのプロダクト
Search
ドキュメントセンター

Tair (Redis® OSS-Compatible):プロキシノードの機能

最終更新日:Apr 17, 2025

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

プロキシノードの概要

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

機能

説明

アーキテクチャ変換

プロキシノードを使用すると、標準インスタンスと同じ方法でクラスタインスタンスを使用できます。プロキシノードは、DELEXISTSMGETMSETSDIFFUNLINK などのコマンドに対して、異なるハッシュスロットにわたる複数キー操作をサポートします。詳細については、「クラスタインスタンスと読み書き分離インスタンスでサポートされるコマンドの制限」をご参照ください。

ビジネス要件が標準インスタンスで提供できる機能を超えて成長した場合、コードを変更することなく、標準インスタンスのデータをプロキシノードを持つクラスタインスタンスに移行してコストを削減できます。

負荷分散とコマンドルーティング

プロキシノードは、バックエンドデータシャードとの持続的接続を確立して、負荷分散とコマンドルーティングを実行します。詳細については、「プロキシノードのルーティング方法」をご参照ください。

読み取り専用レプリカへのトラフィック管理

プロキシノードは、各読み取り専用レプリカのステータスをリアルタイムで監視します。読み取り専用レプリカが次のいずれかの状態にある場合、プロキシノードは読み取り専用レプリカへのトラフィックのルーティングを停止します。

  • 異常:読み取り専用レプリカが異常な場合、プロキシノードは読み取り専用レプリカへのトラフィックの重みを減らします。読み取り専用レプリカが指定された回数接続に失敗した場合、プロキシノードは読み取り専用レプリカが再び正常になるまで、読み取り専用レプリカへのトラフィックのルーティングを停止します。

  • 完全データ同期:プロキシノードが読み取り専用レプリカで完全データが同期されていることを検出した場合、プロキシノードは同期が完了するまで読み取り専用レプリカへのトラフィックのルーティングを停止します。

ホットキーデータキャッシュ

プロキシクエリキャッシュ機能を有効にすると、プロキシノードはホットキーのリクエストデータとレスポンスデータをキャッシュします。プロキシノードがキャッシュの有効期間内に同じリクエストを複数回受信した場合、プロキシノードはバックエンドデータシャードと対話することなく、キャッシュされた結果をクライアントに直接返します。これにより、ホットキーに対する大量の読み取りリクエストによって引き起こされるデータアクセススキューを防ぎます。詳細については、「プロキシクエリキャッシュを使用してホットキーによって引き起こされる問題に対処する」をご参照ください。

説明

この機能は、Tair DRAM ベースと永続メモリインスタンスでのみ使用できます。

複数データベースのサポート

クラスタモードでは、複数のデータベースはオープンソース Redis または Redis Cluster クライアントではサポートされていません。この場合、デフォルトデータベース 0 のみを使用でき、SELECT コマンドはサポートされていません。プロキシノードを使用してクラスタインスタンスにアクセスできます。この場合、複数のデータベースを使用でき、SELECT コマンドがサポートされます。デフォルトでは、単一のクラスタインスタンスに 256 個のデータベースを指定できます。

説明

StackExchange.Redis クライアントを使用する場合は、StackExchange.Redis 2.7.20 以降を使用してください。そうでない場合、エラーが発生します。詳細については、「StackExchange.Redis アップデートに関するお知らせ」をご参照ください。

説明

プロキシテクノロジーの進化に伴い、クラスタインスタンス内のプロキシノードの数は、プロキシノードの処理能力を単独で決定するものではありません。 Alibaba Cloud は、プロキシノードの割り当てと構成が仕様に記載されている要件を満たしていることを保証します。

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

説明

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

アーキテクチャ

ルーティング方法

説明

クラスタアーキテクチャ

基本ルーティング方法

  • プロキシノードが個々のキーを管理するコマンドを受信すると、プロキシノードはキーが属するハッシュスロットを識別し、ハッシュスロットが存在するデータシャードにコマンドをルーティングします。

  • プロキシノードが異なるシャードに格納されている複数のキーを管理するコマンドを受信すると、プロキシノードはコマンドを複数のコマンドに分割し、対応するシャードにコマンドをルーティングします。

    説明

    Community Edition 5.0.1 以降では、プロキシノードは Redis コミュニティの標準に合わせてスロットレベルでコマンドを分割します。

    Community Edition 5.0.1 より前のバージョンでは、プロキシノードはシャードレベルでコマンドを分割していました。これらのインスタンスを Community Edition 5.0 以降にアップグレードすると、コマンド分割ルールの変更により、クエリ/秒 (QPS) が増加し、トラフィックがわずかに増加する可能性があります。ただし、プロキシノードはパイプライン技術を使用してコマンドを発行するため、パフォーマンスへの影響は軽微です。

特定のコマンドのルーティング方法

  • Pub/Sub コマンド

    プロキシノードが PUBLISHSUBSCRIBE などの Pub/Sub コマンドを受信すると、プロキシノードはチャネル名をハッシュし、対応するデータシャードにコマンドをルーティングします。

    説明

    データシャードの Pub/Sub モニタリングデータを表示するには、Tair コンソールの パフォーマンスモニタリング ページで データノード タブをクリックし、カスタムメトリックとして Pub/Sub モニタリンググループ を選択します。デフォルトでは、最初のデータシャードの Pub/Sub データが表示されます。

  • 独自開発のコマンド

    プロキシノードが IINFOISCAN など、Alibaba Cloud によって独自に開発されたコマンドを受信し、idx パラメータによってデータシャード ID が指定されている場合、プロキシノードはコマンドを指定されたデータシャードにルーティングします。詳細については、「プロキシモードのインスタンスの独自コマンド」をご参照ください。

読み書き分離アーキテクチャ

基本ルーティング方法

  • プロキシノードは書き込みコマンドをマスターノードにルーティングします。

  • システムは、読み取りリクエストをマスターノードと読み取り専用レプリカに均等に分散します。これらのノードの重みは変更できません。たとえば、3 つの読み取り専用レプリカを持つインスタンスを購入した場合、マスターノードと 3 つの読み取り専用レプリカの重みはすべて 25% です。

    説明

    SLOWLOGDBSIZE は読み取りコマンドです。

特定のコマンドのルーティング方法

  • SCAN コマンド

    HSCANSSCAN、または ZSCAN コマンドを実行すると、プロキシノードは最初に関連するキーが存在するスロットを計算します。次に、スロットに基づいてモジュロ計算を実行することにより、目的のノードを決定します。これにより、リクエストがマスターノードと読み取り専用レプリカに均等に分散されます。

  • 独自開発のコマンド

    プロキシノードが RIINFORIMONITOR など、Alibaba Cloud によって独自に開発されたコマンドを受信すると、プロキシノードは ro_slave_idx パラメータで指定された読み取り専用レプリカと idx パラメータで指定されたデータシャードにコマンドをルーティングします。詳細については、「プロキシモードのインスタンスの独自コマンド」をご参照ください。

  • その他のコマンド

    プロキシノードは、トランザクションコマンド (MULTIEXEC など)、Lua スクリプトコマンド (EVALEVALSHA など)、SCAN コマンド、INFO コマンド、Pub/Sub コマンド (PUBLISHSUBSCRIBE など) をマスターノードにルーティングします。

接続数

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

説明

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

  • ブロッキングコマンド:BRPOPBRPOPLPUSHBLPOPBZPOPMAXBZPOPMINBLMOVEBLMPOPBZMPOP

  • トランザクションコマンド:MULTIEXECWATCH

  • 監視コマンド:MONITORIMONITORRIMONITOR

  • Pub/Sub コマンド:SUBSCRIBEUNSUBSCRIBEPSUBSCRIBEPUNSUBSCRIBESSUBSCRIBESUNSUBSCRIBE

FAQ

  • 読み取り操作のみを実行する Lua スクリプトを読み取り専用レプリカに転送できますか?

    はい、読み取り操作のみを実行する Lua スクリプトを読み取り専用レプリカに転送できます。ただし、次の要件を満たす必要があります。

    • 読み取り専用アカウントが使用されています。詳細については、「データベースアカウントの作成と管理」をご参照ください。

    • Tair インスタンスの readonly_lua_route_ronode_enable パラメータが 1 に設定されています。値 1 は、読み取り操作のみを実行する Lua スクリプトが読み取り専用レプリカにルーティングされることを示します。詳細については、「 インスタンスパラメータの構成」をご参照ください。

  • プロキシモードと直接接続モードの違いは何ですか?どちらのモードが推奨されますか?

    プロキシモードを使用することをお勧めします。プロキシモードと直接接続モードの違いは次のとおりです。

    • プロキシモード:プロキシノードは、クライアントからのリクエストをデータシャードに転送します。このモードは、負荷分散、読み書き分離、フェールオーバー、プロキシクエリキャッシュ、持続的接続などの機能を提供します。

    • 直接接続モード:このモードでは、プライベートエンドポイントを使用してプロキシノードをバイパスし、オープンソース Redis クラスタに接続するのと同じ方法でインスタンスのバックエンドデータシャードに直接接続できます。プロキシモードと比較して、直接接続モードはルーティング時間を短縮し、Redis の応答を高速化します。

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

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

    シナリオ

    影響と最適化

    図 2. 複数のキーを管理するコマンド 多Key命令场景

    • 影響:

      クライアントは 4 つの接続で 4 つのリクエストを送信します。データシャード 2 が異常な場合、データシャード 2 にルーティングされたリクエストに対してタイムアウトエラーが返されます。クエリされたデータは、リクエスト 1 (GET Key1) に対してのみ返されます。

    • 最適化方法:

      • MGET など、複数のキーを管理するコマンドの使用頻度を減らすか、リクエストによって管理されるキーの数を減らします。これにより、単一のデータシャードが異常であるという理由だけで、すべてのリクエストが失敗することはありません。

      • トランザクションコマンドの使用頻度を減らすか、トランザクションサイズを減らします。こうすることで、サブトランザクションが失敗した場合でも、トランザクション全体が失敗することはありません。

    図 3. 単一接続 单连接场景

    • 影響:

      クライアントは同じ接続で 2 つのリクエストを送信します。データシャード 2 が異常な場合、リクエスト 1 (GET Key1) とリクエスト 2 (GET Key2) に対してタイムアウトエラーが返されます。この例では、リクエスト 1 はリクエスト 2 と同じ接続を使用しているため失敗します。

    • 最適化方法:

      • パイプラインの使用を最小限に抑えます。

      • Lettuce など、単一接続のみをサポートするクライアントは使用しないでください。 Jedis など、接続プールをサポートするクライアントを使用することをお勧めします。 Jedis を使用する場合は、適切なタイムアウト期間と接続プールサイズを設定する必要があります。 Jedis の詳細については、「クライアントを使用してインスタンスに接続する」をご参照ください。