PolarDB:負荷分散

負荷分散ポリシー

プライマリノードが読み取り要求を受け入れる

[プライマリノードの読み取り要求の受け入れ] を [いいえ] に設定すると、一般的な読み取り要求はプライマリノードに転送されなくなります。 トランザクションでは、高い一貫性を必要とする読み取り要求は、ビジネス要件を満たすためにプライマリノードに転送されます。 すべての読み取り専用ノードに障害が発生した場合、読み取り要求はプライマリノードに転送されます。 ワークロードに高い整合性が必要ない場合は、整合性レベルを最終的な整合性に設定して、プライマリノードに転送される読み取り要求の数を減らすことができます。 トランザクション分割機能を使用して、トランザクションが開始される前にプライマリノードに転送される読み取り要求の数を減らすこともできます。 しかしながら、SETおよびPREPARE要求などのブロードキャスト要求は、プライマリノードに転送されます。

トランザクション分離

PolarDBクラスターへの接続に使用されるクラスターエンドポイントが読み取り /書き込みモードの場合、PolarProxyは読み取りおよび書き込みリクエストをプライマリノードと読み取り専用ノードに転送します。 セッション内のトランザクション間のデータの一貫性を確保するために、PolarProxyはセッションのトランザクション内のすべてのリクエストをプライマリノードに送信します。 例えば、Java database Connectivity (JDBC) などのデータベース・クライアント・ドライバは、要求をトランザクションにカプセル化する。 この場合、アプリケーションからのすべての要求はプライマリノードに送信されます。 これにより、プライマリノードの負荷が大きくなります。 ただし、読み取り専用ノードにはリクエストは送信されません。 次の図にプロセスを示します。

この問題を解決するために、PolarDBは、コミット済み読み取り分離レベルのセッションでトランザクション分割機能を提供します。 この機能により、セッション内のデータの一貫性が確保され、PolarDBが読み取り専用ノードに読み取り要求を送信できるようになり、プライマリノードの負荷が軽減されます。 アプリケーションのコードや構成を変更することなく、プライマリノードの読み取り負荷を減らすことができます。 このようにして、プライマリノードの安定性が改善されます。 トランザクション分割を有効にする方法の詳細については、「PolarProxyの設定」をご参照ください。

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

• 最初の書き込み要求の前の読み取り要求の分割

  PolarProxyは、最初の書き込み要求の前にトランザクションで読み取り要求を読み取り専用ノードに送信します。 これにより、プライマリノードの負荷が軽減されます。

  

• 完全なトランザクション分割 (最初の書き込み要求の前後の読み取り要求分割)

  最初の書き込み要求の前の読み取り要求分割が使用される場合、最初の書き込み要求の後のトランザクションにおける読み取り要求は、依然としてプライマリノードにルーティングされます。 これは依然として不平衡負荷を引き起こす。 アンバランスな負荷を解決するために、PolarDB for MySQLは完全なトランザクション分割機能を提供します。 これにより、トランザクション内のすべての読み取り要求が読み取り専用ノードにルーティングされ、正しい結果が返されます。 この機能は、プライマリノードへの圧力をさらに軽減します。

  

  最初の書き込み要求後の分割読み取り要求を読み取り専用ノードにルーティングする前に、すべての以前の書き込み操作を読み取り専用ノードに同期する必要があります。 セッションの一貫性が選択されている場合、システムは、最初の書き込み要求の後に分割読み取り要求をルーティングする前に、すべての以前の書き込み操作が現在のセッションの読み取り専用ノードに同期されているかどうかを確認します。 その場合、最初の書き込み要求の後の分割読み取り要求は、現在のセッションの読み取り専用ノードにルーティングできます。 それ以外の場合、最初の書き込み要求の後の分割読み取り要求は、プライマリノードにルーティングされます。 同様に、グローバル一貫性が選択された場合、システムは、最初の書き込み要求の後に分割読み取り要求をルーティングする前に、すべてのセッションのすべての以前の書き込み操作が読み取り専用ノードに同期されるかどうかをチェックします。 その場合、最初の書き込み要求の後の分割読み取り要求を読み取り専用ノードにルーティングできます。 それ以外の場合、最初の書き込み要求の後の分割読み取り要求は、プライマリノードにルーティングされます。 最終的な一貫性が選択されている場合、完全なトランザクション分割は有効にできません。

  サポートされているバージョンと制限

  トランザクション分割機能を使用するには、PolarDB for MySQLクラスターが次のいずれかの要件を満たす必要があります。

  • リビジョンバージョンが5.6.1.0.29以降のPolarDB for MySQL 5.6クラスター。

  • リビジョンバージョンが5.7.1.0.9以降のPolarDB for MySQL 5.7クラスター。

  • リビジョンバージョンが8.0.1.1.18以降のPolarDB for MySQL 8.0.1クラスター。

  • PolarDB for MySQL 8.0.2クラスター。

  • エンジンパラメーターloose_query_cache_typeはOFFに設定する必要があります。 このパラメーターのデフォルト値は、PolarDB for MySQLの5.6、5.7、8.0.1クラスターではOFF、PolarDB for MySQLの8.0.2クラスターではONです。 このパラメーターを変更する場合は、PolarDBクラスターを再起動する必要があります。

• トランザクション分割の無効化

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

重量ベースのロードバランシング

デフォルトでは、PolarDB for MySQL PolarProxyは、リクエストをルーティングする同時リクエストが最小限であるノードを選択します。 このポリシーは基本的に、トラフィックをバランスの取れた方法で異なるバックエンドノードにルーティングできます。 バックエンドノードが異なる仕様を使用している場合でも、負荷分散の結果を保証できます。 ただし、顧客はさまざまなビジネス負荷とトラフィック分散のさまざまな要件を持っています。

PolarDB for MySQLでは、重みベースの負荷分散機能が導入されています。 ノードに異なる重みを設定できます。 次いで、同時要求の重みおよび数が、最終的なルーティング決定のために参照される。 重みは、次の2つのディメンションでのみ設定できます。

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

  重み設定はすべてのエンドポイントで有効です。

• エンドポイントディメンション

  重み設定は現在のエンドポイントに対してのみ有効であり、グローバルディメンションの重み設定を上書きします。 最初にグローバルディメンションで重みを設定し、次に指定したエンドポイントの重みを設定する場合、エンドポイントの重みは実際には有効です。

使用上の注意

• この機能を使用するには、PolarProxyが2.8.3以降である必要があります。

• 現在のノード負荷とカスタム重みの両方が考慮されるため、実際の全体的な比率は指定された比率とは少し異なる場合があります。 しかし、前者は徐々に後者に近づくでしょう。

• サーバーレスクラスターは、エンドポイントディメンションでの重み設定をサポートしていません。

仕組み

各ノードの最終的な重みは、指定した重みと各ノードでの同時リクエストの数に基づいて動的に調整されます。 簡略化された式を使用できます。

動的重み=カスタム重み /同時リクエスト数

動的重みの値が高いほど、ノードが要求をルーティングするために使用される可能性が高いことを意味する。 重みベースの負荷分散ポリシーは、柔軟なルーティング方法を提供します。 実際には、ビジネストラフィックは指定した重みに基づいて徐々に変化します。 純粋な重みベースのポーリング方法と比較して、より多くの時間が必要です。

手順

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

1. PolarDBコンソールにログインします。

2. 左上隅で、クラスターがデプロイされているリージョンを選択します。

3. クラスターを見つけて、そのIDをクリックします。

4. [基本情報] ページの [Standard Enterprise Edition] または [Dedicated Enterprise Edition] セクションで、[データベースプロキシ設定] をクリックします。

5. [データベースプロキシ設定] ダイアログボックスで、ビジネス要件に基づいて各ノードの重みを設定します。

   

6. [OK] をクリックします。

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

1. PolarDBコンソールにログインします。

2. 左上隅で、クラスターがデプロイされているリージョンを選択します。

3. クラスターを見つけて、そのIDをクリックします。

4. [基本情報] ページの [Standard Enterprise Edition] または [Dedicated Enterprise Edition] セクションで、クラスターエンドポイントまたはカスタムエンドポイントの右上隅にある [設定] をクリックします。

5. [エンドポイント設定の変更] ダイアログボックスの [ノード設定] セクションで、[ノード重みの設定] を選択し、ノードの重みを設定します。

   

6. [OK] をクリックします。

テストデータ

次の図は、ノードに重みを設定した後の実際のテストデータを示しています。

3つのノードの重み比が1:2:3 (プライマリノードでは1) である場合、期待されるテスト結果を得ることができる。 sysbench oltp_read_onlyテストセットが使用されることに注意してください。

オンデマンド接続

背景情報

アクティブリクエストベースのロードバランシングで使用されるエンドポイントの場合、デフォルトではフル接続方式が使用されます。 クライアントがPolarProxyへのセッションを開始すると、PolarProxyはエンドポイント内のすべてのノードへのセッション (接続) を設定します。 1:N対応が形成される。 このクライアントセッションからの読み取り要求は、現在のノードのアクティブな負荷に応じて他のノードにルーティングされます。 SETステートメントなどのブロードキャスト要求は、すべてのノードにルーティングされます。 多数のノードが作成される場合、接続およびブロードキャストの確立は、全体的な効率を低下させます。

仕組み

オンデマンド接続方式を使用すると、PolarProxyはオンデマンドでバックエンドノードへの接続を確立します。 データの一貫性が保証され、プライマリノードが負荷を処理することができる限り、接続の確立およびブロードキャストに関連するオーバーヘッドを低減するために、ノードへのより少ない接続が確立される。 ほとんどの場合、セッションは1つのプライマリノードと1つの読み取り専用ノードに接続されます (最終的な一貫性のみが提供されます) 。 多数の短期間の接続またはブロードキャストステートメントがあるシナリオでは、この方法でパフォーマンスが大幅に向上します。

上の図では、PolarDBクラスターにプライマリノードが1つ、読み取り専用ノードが3つしか含まれておらず、データの一貫性が考慮されていない場合、3つのシナリオでのリクエストルーティングとデータ読み取りに関する次の効率結果が得られます。

• 非オンデマンド接続

  セッションにより、PolarProxyは4つのノードへの接続を確立し、ブロードキャストステートメントは4つのノードにルーティングされます。

• 読み取り専用セッションのオンデマンド接続

  セッションにより、PolarProxyは1つの読み取り専用ノードへの接続を確立します。 読み取り専用要求 (ブロードキャスト要求を含む) は、この読み取り専用ノードにのみルーティングされます。 これにより、データの読み取り効率が大幅に向上します。

• 読み取り /書き込みセッションのオンデマンド接続

  セッションにより、PolarProxyは1つの読み取り専用ノードへの接続と1つのプライマリノードへの接続を確立します。 ブロードキャスト要求は、2つのノードのみにルーティングされる。 これはまた、データ読み出し効率を著しく改善する。

シナリオ

• 多数の読み取り専用ノード

• 短命の接続

• 多数のブロードキャストステートメント (たとえば、PHPの短期間の接続シナリオでは、セッションの最初のステートメントは通常、SET NAMES utf8mb4ステートメントです)

• 短いPREPAREステートメントを使用するほとんどのクエリ

制限事項

• PolarProxyは2.8.34以降である必要があります。 クラスターのPolarProxyバージョンを表示する方法の詳細については、「PolarProxyバージョンの照会」をご参照ください。

• SHOW PROCESSLISTSステートメントを実行して接続ノード数を表示すると、すべての接続が表示されない場合があります。

• KILL文を実行して指定した接続を終了すると、指定したすべてのノードへの接続が終了するわけではありません。

パフォーマンステスト

テスト環境

• ノード: 1つのプライマリノードと7つの読み取り専用ノード

• 使用するSQL文: SET NAMES utf8mb4およびSELECT 1

• テストツール: Sysbench。 毎回同じ数の同時リクエストが送信されます。

• テストシナリオ: 接続プール機能は無効になっており、接続プール機能はセッションレベルで有効になっており、接続プール機能はトランザクションレベルで有効になっています。 各シナリオは2つの部分に分かれています。最初の部分ではオンデマンド接続機能が無効になり、2番目の部分ではオンデマンド接続機能が有効になります。

テスト結果

• 接続プール機能が無効の場合のパフォーマンステストの結果:

  • ノードのCPU使用率の変化を次の図に示します。 オンデマンド接続機能を有効にすると、ノードのCPU使用率は60% を超えて低下します。

    

  • 次の図は、ノードへの合計接続の変化を示しています。 オンデマンド接続機能を有効にすると、ノードへの接続の合計は80% を超えて減少します。

    

  • 次の図は、QPS全体の変化を示しています。 オンデマンド接続機能を有効にすると、全体のQPSは35% 増加します。

    

• 接続プールがセッションレベルで有効になっているシナリオのパフォーマンステストの結果:

  • ノードのCPU使用率の変化を次の図に示します。 オンデマンド接続機能が有効になった後、ノードのCPU使用率は50% から60% に減少します。

    

  • 次の図は、ノードへの合計接続の変化を示しています。 オンデマンド接続機能を有効にすると、ノードへの接続の合計は60% 減少します。

    

  • 次の図は、QPS全体の変化を示しています。 オンデマンド接続機能を有効にすると、全体のQPSは30% 増加します。

    

• 接続プール機能がトランザクションレベルで有効になっている場合のパフォーマンステストの結果:

  • ノードのCPU使用率の変化を次の図に示します。 オンデマンド接続機能が有効になると、ノードのCPU使用率は60% 減少します。

    

  • 次の図は、ノードへの合計接続の変化を示しています。 オンデマンド接続機能を有効にすると、ノードの合計接続数は50% 減少します。

    

  • 次の図は、QPS全体の変化を示しています。 オンデマンド接続機能を有効にすると、全体のQPSは260% 増加します。