PolarProxy の負荷分散 - PolarDB - Alibaba Cloud ドキュメントセンター

PolarDB は、複数の読み取り専用ノードに負荷を分散するために、接続数に基づく負荷分散 と アクティブなリクエストベースのロードバランシング の 2 つの負荷分散ポリシーをサポートしています。

負荷分散ポリシー

接続数に基づく負荷分散：このポリシーは、整合性レベルやトランザクション分割などの高度な機能を必要としない、パフォーマンス重視のシナリオに最適です。
アクティブなリクエストベースのロードバランシング：クラスターエンドポイント内の複数の読み取り専用ノード間で、アクティブなリクエスト数に基づいて読み取りリクエストが自動的にルーティングされます。このポリシーは、整合性レベル、トランザクション分割、接続保持などの高度な機能をサポートし、各ノードのリアルタイムのステータスに基づいて負荷を分散します。

説明

PolarDB の 読み取り専用 モードのクラスターエンドポイントは、接続数に基づく負荷分散 と アクティブなリクエストベースのロードバランシング の両方をサポートします。読み書き (自動読み書き分離) モードのクラスターエンドポイントは、アクティブなリクエストベースのロードバランシング のみをサポートします。

次の表は、2 つのポリシーを比較したものです。

ポリシー名	相違点	共通点
接続数に基づく負荷分散	アプリケーションは、クラスターエンドポイント内の 1 つの読み取り専用ノードとのみ単一の接続を確立します。アプリケーションが確立できる接続の総数は、クラスターエンドポイント内のすべての読み取り専用ノードの最大接続数の合計に等しくなります。読み取り専用ノードが対応するエンドポイントから削除されると、そのノードへのユーザー接続は切断されます。整合性レベル、トランザクション分割、接続保持、自動行ストア/列ストアルーティングなどの高度な機能はサポートされていません。接続確立のみを処理し、負荷分散への関与が少ないため、パフォーマンスが向上します。	読み取り専用モードのクラスターエンドポイントでは、使用される負荷分散ポリシーに関係なく、リクエストはプライマリノードに転送されません。
アクティブなリクエストベースのロードバランシング	アプリケーションは、クラスターエンドポイント内のすべてのノードと単一の接続を確立します。アプリケーションが確立できる接続の総数は、クラスターエンドポイント内のすべてのノードの最大接続数の最小値に等しくなります。整合性レベル、トランザクション分割、接続保持、自動行ストア/列ストアルーティングなどの高度な機能をサポートします。各リクエストを解析してルーティングする必要があるため、パフォーマンスはわずかに低下します。優れた負荷分散を提供し、ノードの仕様が異なる場合でもトラフィックを効果的に分散します。

プライマリノードでの読み取りリクエストの受付

プライマリノードによる読み取りリクエストの許可 を いいえ に設定すると、PolarProxy は通常の読み取りリクエストをプライマリノードに送信しなくなります。ただし、一貫性が必要なトランザクション内の読み取りリクエストは、ビジネス要件を満たすために引き続きプライマリノードに送信されます。さらに、すべての読み取り専用ノードに障害が発生した場合も、読み取りリクエストはプライマリノードに送信されます。ビジネスの整合性要件が低い場合は、整合性レベルを結果整合性に設定して、プライマリノードへの読み取りリクエストを減らすことができます。また、トランザクション分割機能を使用して、実際のトランザクションが開始される前にプライマリノードに送信される読み取りリクエストを減らすこともできます。SET や PREPARE などのブロードキャストリクエストは、引き続きプライマリノードに送信されます。

説明

プライマリノードによる読み取りリクエストの許可 の設定は、読み書き が 読み書き (自動読み書き分離) に設定されている場合にのみ構成できます。プライマリノードによる読み取りリクエストの許可 の設定を変更する方法については、「PolarProxy の設定」をご参照ください。
PolarProxy のバージョンが 1.x.x または 2.5.1 以降の場合、プライマリノードによる読み取りリクエストの許可 の設定変更はすぐに有効になります。
PolarProxy のバージョンが 2.x.x で 2.5.1 より前の場合、プライマリノードによる読み取りリクエストの許可 の設定変更は、接続保持を再確立した後にのみ有効になります。短時間接続の場合、変更はすぐに有効になります。

トランザクション分割

PolarDB クラスターエンドポイントを読み書き (自動読み書き分離) モードで使用すると、PolarProxy は読み取りおよび書き込みリクエストをプライマリノードと読み取り専用ノードに分散します。セッション内でのトランザクションの一貫性を確保するために、PolarProxy はトランザクション内のすべてのリクエストをプライマリノードに送信します。たとえば、JDBC などの一部のデータベースクライアントドライバーは、デフォルトでリクエストをトランザクションでラップします。その結果、すべてのアプリケーションリクエストがプライマリノードに送信され、プライマリノードの負荷が高くなる一方で、読み取り専用ノードは十分に活用されない可能性があります。次の図に示します。

この問題に対処するために、PolarDB はリードコミッティド分離レベルでトランザクション分割機能を提供します。この機能は、トランザクション内の読み取りリクエストを読み取り専用ノードに送信してプライマリノードの負荷を軽減し、サービスの読み書きの一貫性を確保します。アプリケーションのコードや構成を変更することなく、プライマリノードの読み取り負荷を読み取り専用ノードにオフロードし、プライマリノードの安定性を向上させることができます。トランザクション分割を有効にする方法の詳細については、「PolarProxy の設定」をご参照ください。

PolarDB for MySQL は、最初の書き込みリクエスト前の読み取りリクエスト分割 (デフォルト、元のトランザクション分割機能) と完全なトランザクション分割 (最初の書き込みリクエスト前後での読み取りリクエスト分割) の 2 つのレベルのトランザクション分割を提供します。

最初の書き込みリクエスト前の読み取りリクエスト分割

PolarProxy は、トランザクション内の最初の書き込みリクエストより前の読み取りリクエストを読み取り専用ノードに送信し、プライマリノードの負荷を軽減します。
完全なトランザクション分割 (最初の書き込みリクエスト前後での読み取りリクエスト分割)

最初の書き込みリクエスト前の読み取りリクエスト分割では、書き込み後に発生する読み取りリクエストは依然としてプライマリノードにルーティングされるため、負荷が不均衡になる可能性があります。トランザクションによって引き起こされる負荷分散の問題を完全に解決するために、PolarDB for MySQL は完全なトランザクション分割を導入しました。この機能により、トランザクション内のすべての読み取り操作を読み取り専用ノードにルーティングしながら、正しい結果を保証し、プライマリノードへの負荷をさらに軽減できます。

書き込み後の読み取りリクエストは、トランザクション内の先行する書き込み操作からのデータがそのノードに同期されている場合にのみ、読み取り専用ノードにルーティングできます。セッションの一貫性を設定している場合、PolarProxy は書き込み後の読み取りリクエストをルーティングする前に、現在のセッションの読み取り専用ノードが以前の書き込みを同期したかどうかをまず確認します。同期している場合はリクエストを読み取り専用ノードにルーティングし、そうでない場合はプライマリノードにルーティングします。同様に、グローバル整合性を設定している場合、PolarProxy は現在のすべてのセッションからのトランザクションが読み取り専用ノードに同期されているかどうかを確認します。同期している場合はリクエストをそこにルーティングし、そうでない場合はプライマリノードにルーティングします。完全なトランザクション分割は、結果整合性をサポートしていません。

バージョンと制限事項

完全なトランザクション分割機能を使用するには、ご利用の PolarDB for MySQL クラスターが次の要件を満たしている必要があります。
- エンジンバージョン：
  - PolarDB for MySQL 5.6、リビジョン 5.6.1.0.29 以降。
  - PolarDB for MySQL 5.7、リビジョン 5.7.1.0.9 以降。
  - PolarDB for MySQL 8.0.1、リビジョン 8.0.1.1.18 以降。
  - PolarDB for MySQL 8.0.2、任意のリビジョン。
- エンジンパラメーター：
  
  loose_query_cache_type パラメーターを OFF に設定する必要があります。PolarDB for MySQL 5.6、5.7、および 8.0.1 はデフォルトで OFF を使用します。バージョン 8.0.2 はデフォルトで ON を使用します。このパラメーターを変更するには、PolarDB クラスターを再起動する必要があります。
説明
- トランザクション分割は、リードコミッティド分離レベルのセッションでのみサポートされ、デフォルトで有効になっています。
- 読み書きの一貫性の制約により、読み取り専用ノードの整合性レベルが要件を満たさない場合、読み取りリクエストはそのノードにルーティングされません。
- PolarProxy のバージョンが 2.4.14 より前の場合、最初の書き込みリクエスト前の読み取りリクエスト分割のみがサポートされます。完全なトランザクション分割はサポートされていません。
- PolarProxy のバージョンが 2.4.14 以降で、トランザクション分割が完全なトランザクション分割に設定されている場合、変更を有効にするには接続保持を再確立する必要があります。短時間接続の場合、変更はすぐに有効になります。
トランザクション分割の無効化

トランザクション分割が無効になっている場合、トランザクション内のすべてのリクエストはプライマリノードにルーティングされます。

重みベースの負荷分散

デフォルトでは、PolarDB for MySQL の PolarProxy は、アクティブ (同時) リクエストが最も少ないノードにリクエストをルーティングします。このポリシーは通常、バックエンドノードの負荷に基づいてトラフィックを分散します。また、バックエンドノードの仕様が異なる場合でも良好に機能します。ただし、本番環境のワークロードとトラフィック分散の要件はさまざまです。

これらのニーズにより良く応えるために、PolarDB for MySQL は重みベースの負荷分散を導入しました。各ノードに異なる重みを設定できます。ルーティングプロセス中、重みと同時リクエスト数の両方が基準として使用され、最終的なルーティング決定が動的に調整されます。現在、重みは次の 2 つのレベルで設定できます。

グローバルディメンション

この構成はすべてのエンドポイントに適用されます。
エンドポイントディメンション

エンドポイントディメンションの重みは、そのエンドポイントの負荷分散にのみ適用され、グローバル設定をオーバーライドします。たとえば、最初にグローバルディメンションで重みを設定し、次に特定のエンドポイントに別の重みを設定した場合、そのエンドポイントの負荷分散はエンドポイントレベルの構成に基づきます。

読み書き分離のよくある質問

この機能には PolarProxy 2.8.3 以降が必要です。
ルーティングポリシーは現在のノード負荷とユーザー定義の重みの両方を考慮するため、全体的なトラフィック比率は設定された比率からわずかにずれる可能性があります。時間の経過とともに、徐々に設定された比率に収束します。
サーバーレスクラスターは、エンドポイントディメンションでの重み設定をサポートしていません。

仕組み

リクエストのルーティングプロセス中、各ノードの最終的な重みは、設定された重みとノード上の現在の同時リクエスト数に基づいて動的に計算されます。簡略化された数式は次のとおりです。

動的な重み = 設定された重み / 同時リクエスト数

動的な重みが高いほど、ノードの優先度が高くなります。動的な重みによる負荷分散ポリシーは、柔軟なルーティング方法を提供します。実際には、トラフィックは設定された重みに従って徐々にシフトするため、単純な重み付きラウンドロビン方式よりも時間がかかる場合があります。

操作手順

説明

初期状態では、各バックエンドノードのデフォルトの重みは同じく 1 です。
重みの設定可能な範囲は 0 から 100 です。
重みが 0 に設定されている場合、PolarProxy は通常、そのノードにリクエストをルーティングしません。そのノードは、他のすべてのノードが利用できない場合にのみ選択されます。
クラスターに読み取り専用列ストアノードが 1 つしかない場合、その重みは無視できます。クラスターに複数の読み取り専用列ストアノードがある場合、列ストアリクエストはそれらのノードの重みに基づいて負荷分散されます。

グローバルディメンションでの重みの設定

PolarDB コンソールにログインします。
左上のコーナーで、クラスターがデプロイされているリージョンを選択します。
対象のクラスターを見つけて、その ID をクリックします。
基本情報 ページの 標準 Enterprise Edition または 専用 Enterprise Edition セクションで、データベースプロキシサービスの設定 をクリックします。
データベースプロキシサービスの設定 ダイアログボックスで、ビジネス要件に基づいて各ノードの重みを設定します。

ダイアログボックスには、各ノードの ロール (プライマリノードまたは読み取り専用ノード) と重みの入力ボックスが表示されます。上部のメッセージには、ルーティングの決定が重みと同時リクエスト数の両方に基づいて動的に調整されることが示されます。重みの設定が完了したら、[OK] をクリックします。
重みを設定した後、OK をクリックします。

エンドポイントディメンションでの重みの設定

PolarDB コンソールにログインします。
左上のコーナーで、クラスターがデプロイされているリージョンを選択します。
対象のクラスターを見つけて、その ID をクリックします。
基本情報 ページの 標準 Enterprise Edition または 専用 Enterprise Edition セクションで、クラスターエンドポイントまたはカスタムエンドポイントの右上隅にある構成をクリックします。
ノードの設定 ページのサービスノードエリアで、カスタムノードの重み をオンにし、各ノードの重みを設定します。

読み取り専用列ストアノードなどの対象ノードを [利用可能なノード] リストから [選択されたノード] リストに移動します。次に、選択したノードに 1 などの重みを設定し、[OK] をクリックします。
重みを設定した後、[OK] をクリックします。

テストデータ

以下に、ノードの重みを設定した後の実際のテストデータを示します。

テストで使用された 3 つのノードの重み比は 1:2:3 です (プライマリノードの重みは 1)。ストレステストの結果は期待どおりでした (Sysbench oltp_read_only テストスイートを使用)。

456789

説明

2 つの内部ノード、pi-bp1d1mtcobuzv** と pcbp14vvpolardbma23957** はルーティングに関与しないため、これらのメトリックは無視できます。

オンデマンド接続

背景情報

アクティブなリクエストベースのロードバランシング を使用するエンドポイントでは、PolarProxy はデフォルトでフル接続を作成します。クライアントセッションが PolarProxy を介して確立されると、PolarProxy はそのエンドポイント内のすべてのデータベースノードとのセッション (接続) を確立し、1:N の接続関係を作成します。このセッション内の通常の読み取りリクエストは、現在の負荷状況に基づいてさまざまなデータベースノードにルーティングされますが、ブロードキャストリクエスト (SET 文など) はすべてのデータベースノードにルーティングされます。データベースノードが多い場合、接続確立とブロードキャストのオーバーヘッドにより、全体的な効率が大幅に低下します。

仕組み

オンデマンド接続では、PolarProxy は必要に応じてのみバックエンドデータベースとの接続を確立します。整合性と読み書きの負荷要件を満たしながら、バックエンド接続の数を最小限に抑えます。これにより、プロキシ接続やブロードキャスト実行によるデータベースのオーバーヘッドが削減されます。ほとんどの場合、1 つのセッションは最大で 1 つのプライマリノードと 1 つの読み取り専用ノードとの接続を確立します (結果整合性を想定)。これにより、短時間接続や多くのブロードキャスト文を含むワークロードのパフォーマンスが大幅に向上します。

上の図に示すように、PolarDB クラスターに 1 つのプライマリノード (RW) と 3 つの読み取り専用ノード (RO) があると仮定します。整合性を考慮しない場合、3 つのシナリオにおけるリクエストのルーティングとデータ読み取りの効率は次のようになります。

フル接続

PolarProxy を介した単一のユーザーセッションは、4 つすべてのデータベースノードとの接続を確立し、ブロードキャスト文は 4 つすべてのノードにルーティングされます。
オンデマンド接続、読み取り専用セッション

PolarProxy を介した単一のユーザーセッションは、1 つの RO ノードとのみ接続を確立します。読み取りリクエスト (ブロードキャストを含む) はこの単一の RO ノードにのみルーティングされ、データ読み取りの効率が大幅に向上します。
オンデマンド接続、読み書きセッション

PolarProxy を介した単一のユーザーセッションは、1 つの RO ノードと 1 つの RW ノードとのみ接続を確立します。ブロードキャストリクエストはこれら 2 つのデータベースノードにのみルーティングされ、これもデータ読み取りの効率を大幅に向上させます。

利用シーン

多数の RO ノードを持つクラスター。
短時間接続。
多くのブロードキャスト文があるシナリオ (たとえば、PHP の短時間接続シナリオでは、セッションの最初の文はしばしば set names utf8mb4 のようになります)。
短い PREPARE 文を使用するクエリが多いワークロード。

制限事項

PolarProxy 2.8.34 以降が必要です。クラスターの PolarProxy バージョンを確認する方法については、「バージョン番号の確認」をご参照ください。
SHOW PROCESSLISTS を使用してデータベース接続数を表示する場合、すべてのデータベースへの接続総数が表示されないことがあります。
KILL コマンドを使用して特定の接続を終了する場合、コマンドがすべてのデータベースで指定された接続を終了しないことがあります。

パフォーマンステスト

テスト環境

データベースノード：1 つの読み書き (RW) ノード、7 つの読み取り専用 (RO) ノード
テストに使用した SQL：SET NAMES utf8mb4、SELECT 1
テストツール：Sysbench、各テストで同数の同時接続
テストシナリオ：テストは、接続プールなし、セッションレベル接続プール、トランザクションレベル接続プールの 3 つのシナリオを対象としました。各テストは 2 つの部分に分かれており、前半はオンデマンド接続を有効にせず、後半はオンデマンド接続を有効にしました。

テスト結果

接続プールなしのシナリオでのパフォーマンステスト結果：
- 下の図は、データベースノードの CPU 消費量を示しています。オンデマンド接続を有効にした後、データベースの CPU 消費量は 60% 以上減少しました。
- 下の図は、データベースノードへの接続総数の変化を示しています。オンデマンド接続を有効にした後、接続総数は 80% 以上減少しました。
- 下の図は、全体的な QPS の変化を示しています。オンデマンド接続を有効にした後、全体的な QPS は 35% 増加しました。
セッションレベル接続プールのシナリオでのパフォーマンステスト結果：
- 下の図は、データベースノードの CPU 消費量を示しています。オンデマンド接続を有効にした後、データベースの CPU 消費量は 50% から 60% 以上減少しました。
- 下の図は、データベースノードへの接続総数の変化を示しています。オンデマンド接続を有効にした後、接続総数は 60% 減少しました。
- 下の図は、全体的な QPS の変化を示しています。オンデマンド接続を有効にした後、QPS は 30% 増加しました。
トランザクションレベル接続プールのシナリオでのパフォーマンステスト結果：
- 下の図は、データベースノードの CPU 消費量を示しています。オンデマンド接続を有効にした後、データベースの CPU 消費量は 60% 減少しました。
- 下の図は、データベースノードへの接続総数の変化を示しています。オンデマンド接続を有効にした後、接続総数は 50% 減少しました。
- 下の図は、全体的な QPS の変化を示しています。オンデマンド接続を有効にした後、QPS は 260% 増加しました。