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

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

注意事項

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

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

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

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

シナリオ情報

現在、テナントtenant1が存在し、そのローカリティは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は、ログストリームのリーダーバランシングのスイッチです。自動ロードバランシングの総合スイッチである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が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;
   

   ステートメントの実行が成功すると、ログストリームは自動的に分割され、zone1上に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. （オプション）リーダーレプリカを引き続きzone1に集中させたい場合、テナントのPRIMARY_ZONEを元のzone1に変更できます。

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