スムーズなアプリケーションのスケーリング事例

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

注意事項

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

シナリオ1：新しいZoneを追加してスケーリングを行う

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

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

シナリオ情報

現在、テナントtenant1が存在し、そのLocalityはF@zone1，F@zone2，A、PRIMARY_ZONEはzone1,zone2です。テナントにはリソースプールpoolが1つあり、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は、ログストリームのLeaderバランシングのスイッチです。自動ロードバランシングの総合スイッチであるenable_rebalanceが有効な場合、このパラメータでログストリームのリーダーの自動バランシングを個別に制御できます。デフォルト値はTrueで、ログストリームのLeaderの自動バランシングがデフォルトで有効であることを示しています。

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

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

   1. Zoneの追加を参照し、クラスタにそれぞれ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. テナントのLocalityを変更し、新しく追加したzone3とzone4をLocalityに追加します。

   Localityを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';
   

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

6. 再度テナントのLocalityを変更し、Localityからzone1とzone2を削除します。

   Localityを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に集中しているテナントの場合、オンサイトでのスケーリングを実行できます。オンサイトでのスケーリングは、フォロワーレプリカが配置されているZoneのみを操作することを保証します。

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

シナリオ情報

現在、テナントtenant1があり、そのLocalityはF@zone1，F@zone2，A、PRIMARY_ZONEはzone1です。テナントにはリソースプールpoolが1つあり、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つのUnitに分散します。この時点でのユーザーログストリームの分布状況は以下のようになります。

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. （オプション） Leaderレプリカを引き続きzone1に集中させたい場合、テナントのPRIMARY_ZONEを元のzone1に変更できます。

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