スムーズなスケーリングのユースケース

RTに高度に敏感な業務では、テナントのスケーリングを実行する際、ログストリームのリーダーが存在するノードで行われるロードバランシング操作を厳密に制限する必要があります。これらのロードバランシング操作には、Transferタスク、ログストリームレプリカの移行・複製、リーダーのフェイルオーバーなどが含まれます。このような場合、異種ゾーンを活用することで、業務のピーク時にリーダーのフェイルオーバーやリーダーレプリカの移行が発生するのを回避し、スケーリングプロセス全体をよりスムーズに進めることができます。

注意事項

原則として、スケーリングまたはロールバック操作を実行する際、移行・複製が発生するのは UNIT_NUM 数量が変更されたゾーンのみです。他のゾーンではログストリームの移行・複製は発生せず、ローカルTransferのみが行われます。ただし、スケーリング操作を実行する前にテナントが不均衡な状態にある場合、例えばシステムがパーティションの均衡を行っている場合や、前のスケールアウトタスクが完了する前に新たなスケーリングタスクを開始した場合、システムは他のゾーンでログストリームが移行されないことを保証するものではありません。

シナリオ1：新規ゾーンの追加によるスケーリング

テナントの PRIMARY_ZONE が分散しており、一つのゾーンに集約できない場合、スムーズなスケーリングを実現するには、Localityの変更を用いたスケーリングを行う必要があります。具体的には、まずスケールアウトまたはスケールイン後のゾーンを新規に追加し、その後Localityの変更を通じて新規ゾーン上にレプリカを追加します。この補完レプリカのプロセスにより、均衡の取れた完了が保証されます。

以下、スケールアウトを例に説明します。

シナリオ情報

現在、テナント tenant1 があり、その Locality は F@zone1，F@zone2，A、PRIMARY_ZONE は zone1,zone2 です。テナントにはリソースプール pool があり、zone1 と zone2 に分散して配置されており、UNIT_NUM は 2 です（つまり UNIT_NUM は 2:2 に設定されています）。ユーザーのログストリームの分布状況は、以下の図のとおりです。

現在、テナントのリソースプールの UNIT_NUM を 4:4 に拡張する必要があります。

手順

1. root ユーザーでクラスタの sys テナントにログインします。

2. パラメータ enable_ls_leader_balance を無効にします。

   テナントレベルのパラメータ enable_ls_leader_balance はログストリームリーダーの均衡を制御するスイッチです。自動ロードバランシングの総合スイッチである enable_rebalance が有効な場合、このパラメータによりログストリームリーダーの自動均衡を個別に制御できます。デフォルト値は True で、ログストリームリーダーの自動均衡がデフォルトで有効であることを示しています。

   obclient(root@sys)[(none)]> ALTER SYSTEM SET enable_ls_leader_balance = False TENANT = 'tenant1';
   

3. 2つの4ノードゾーンを追加し、新規ゾーンにテナントのリソースを追加します。

   1. ゾーンの追加 を参照し、クラスタにそれぞれ zone3、zone4 を追加します。

   2. ノードの追加 を参照し、新規に追加した zone3、zone4 にそれぞれ4つのノードを追加します。

   3. 新規ゾーンの Zone3、Zone4 に、元のUnit仕様と同じで UNIT_NUM が4のリソースプール pool2 を作成します。

      obclient(root@sys)[(none)]> CREATE RESOURCE POOL pool2 UNIT='unit_name', UNIT_NUM = 4, ZONE_LIST=('zone3','zone4');
      

      ここで、unit_name は実際のUnit名に置き換えてください。

   4. テナントのリソースプールを変更し、新しく追加されたリソースプール pool2 をテナントに割り当てます。

      obclient(root@sys)[(none)]> ALTER TENANT tenant1 RESOURCE_POOL_LIST =('pool','pool2');
      

      実行が成功すると、この時点でテナントの zone1、zone2、zone3、zone4 の UNIT_NUM はそれぞれ 2:2:4:4 となります。

4. テナントのローカリティを変更し、新しく追加された zone3、zone4 をローカリティに追加します。

   ローカリティを F@zone1，F@zone2，A から F@zone1，F@zone2，F@zone3，F@zone4，A に変更します。ステートメントは以下のとおりです。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 LOCALITY="F@zone1，F@zone2，F@zone3，F@zone4，A";
   

   ステートメントの実行が成功すると、システムは新しく追加されたUnit上にログストリームのレプリカを自動的に補完し、各Unit上に均等に分散させます。このプロセスでは新規に追加されるのはすべてフォロワーレプリカのみであるため、リーダー切り替えは発生しません。

   この時点でのユーザーのログストリームの分布状況は以下の図のとおりです。

5. テナントの PRIMARY_ZONE を新しく追加された zone3、zone4 に変更し、パラメータ enable_ls_leader_balance を有効にします。

   PRIMARY_ZONE を zone1,zone2 から zone3,zone4 に変更します。ステートメントは以下のとおりです。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 PRIMARY_ZONE='zone3,zone4'; 
   

   パラメータ enable_ls_leader_balance を有効にするステートメントは以下のとおりです：

   obclient> ALTER SYSTEM SET enable_ls_leader_balance = True TENANT = 'tenant1';
   

   上記のステートメントがすべて正常に実行された後、各ログストリームは自動的にリーダーレプリカを zone3、zone4 に切り替えます。ログストリームの PRIMARY_ZONE のみを変更する場合、プロセスは迅速であり、影響範囲も制御可能です。

6. 再度テナントのローカリティを変更し、ローカリティから zone1、zone2 を削除します。

   ローカリティを F@zone1，F@zone2，F@zone3，F@zone4，A から F@zone3，F@zone4，A に変更します。ステートメントは以下のとおりです。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 locality="F@zone3，F@zone4，A";
   

   ステートメントの実行が成功すると、zone1、zone2 内のログストリームレプリカは削除され、zone3、zone4 は影響を受けません。

7. テナントのリソースプールを変更し、元のリソースプール pool を削除し、新しく追加されたリソースプール pool2 のみを保持します。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 RESOURCE_POOL_LIST =('pool2');
   

   元のリソースプール pool がテナントから削除された後、元々2ノードだった zone1、zone2 も削除できます。

   操作完了後、現在のテナントには UNIT_NUM が4の zone3、zone4 のみが残り、拡張が完了します。

シナリオ2：その場でのスケーリング

一部の PRIMARY_ZONE に集中しているテナントでは、オンサイトでのスケーリングを実行できます。オンサイトでのスケーリングは、フォロワーレプリカが配置されているゾーンのみを操作することを保証します。

以下では、拡張を例に説明します。

シナリオ情報

現在、テナント tenant1 が存在し、そのローカリティは F@zone1，F@zone2，A、PRIMARY_ZONE は zone1 です。テナントにはリソースプール pool があり、zone1 と zone2 に分散しており、UNIT_NUM は 2 です（つまり UNIT_NUM は 2:2 に設定されています）。ユーザーログストリームの分布状況は、以下の図のとおりです。

現在、テナントのリソースプールの UNIT_NUM を 4:4 に拡張する必要があります。

手順

1. root ユーザーでクラスタの sys テナントにログインします。

2. テナントのリソースプールを zone1 の pool1 と zone2 の pool2 に分割します。

   obclient(root@sys)[(none)]> ALTER RESOURCE POOL pool SPLIT INTO ('pool1','pool2') ON ('zone1','zone2');
   

   リソースプールの分割に関する詳細な操作と説明については、リソースプールのメジャーコンパクションと分割を参照してください。

3. 分割されたリソースプール pool2 の UNIT_NUM を 4 に変更します。

   obclient(root@sys)[(none)]> ALTER RESOURCE POOL pool2 UNIT_NUM = 4;
   

   ステートメントの実行が成功すると、ログストリームは自動的に分割され、zone2 上に 4 つのユニットに分散します。この時点でのユーザーログストリームの分布状況は以下のとおりです。

4. テナントの PRIMARY_ZONE を zone2 に変更します。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 PRIMARY_ZONE='zone2'; 
   

5. 分割されたリソースプール pool1 の UNIT_NUM を 4 に変更します。

   obclient(root@sys)[(none)]> ALTER RESOURCE POOL pool1 UNIT_NUM = 4;
   

   ステートメントの実行が成功すると、システム内部でのバランシングが開始されます。バランシングが完了すると、拡張が完了します。ユーザーログストリームの最終的な分布状況は以下のとおりです。

6. （オプション）リーダーレプリカを引き続き zone1 に集中させたい場合は、テナントの PRIMARY_ZONE を zone1 に戻すことができます。

   obclient(root@sys)[(none)]> ALTER TENANT tenant1 PRIMARY_ZONE='zone1';