PhoenixAI クラスターのスケーリング

PhoenixAI は、クラスターの垂直スケーリングと水平スケーリングの両方をサポートしています。ワークロードが増加または減少した場合、クラスターの詳細を表示するクラスターの詳細を確認し、必要なパフォーマンスレベルを最小コストで維持するためにクラスターをスケーリングするかどうかを決定できます。

スケーリング操作の概要

垂直スケーリング

クラスターノードのインスタンスタイプをアップグレードまたはダウングレードすることで、コンピューティングパワーとストレージ容量を増減し、クラスターを垂直にスケールアップまたはスケールダウンできます。以下のシナリオではスケールアップを検討してください：

• ワークロードが CPU または I/O の制限に達しており、クエリのレイテンシが増加して同時実行性が低下しているが、ストレージ容量は十分である。

• 従来の最適化手法では解決できないパフォーマンスの問題を迅速に修正する必要がある。

水平スケーリング

クラスターノードを追加または削除することで、コンピューティングパワーとストレージ容量を増減し、クラスターを水平にスケールアウトまたはスケールインできます。水平スケーリングはクラスターにダウンタイムを発生させません。以下のシナリオではスケールアウトを検討してください：

• ワークロードが CPU、I/O、およびストレージの制限に達しており、クエリのレイテンシが増加して同時実行性が低下しているが、ストレージ容量は十分である。

• サービスの最高パフォーマンスティアでもパフォーマンス要件が上限に達している。

• データが現在のノード数に収まらない。

ストレージスケーリング

データ量の変化に伴うクラスターアクティビティの急増や急減に対応するため、クラスターのストレージをスケールアップまたはスケールダウンできます。

PhoenixAI は、エラスティッククラスターのコーディネーターノードに対する自動ストレージスケールアップもサポートしています。ビジネスのワークロードが予測不可能で、クラスター作成時に固定数のストレージボリュームを割り当てられない場合、PhoenixAI クラスターのノードに対してストレージの自動スケーリングを有効にできます。この機能を有効にすると、PhoenixAI はプリセットのストレージ容量が不足していることを検出した際に、自動的にストレージサイズをスケールアップします。

エラスティッククラスターのスケーリング

PhoenixAI は、垂直スケーリング、水平スケーリング、およびコーディネーターノードのストレージスケーリングをサポートしています。また、各ウェアハウスの自動スケーリングを有効にして、ウェアハウスの CPU 使用率に基づいてシステムがコンピュートノードの数を自動的にスケーリングできるようにすることもできます。

垂直スケーリング

以下の点に注意してください：

• クラスターがストレージとして EBS ボリュームを使用している場合、スケールアップ中にクラスターノードがローリング方式で再起動され、クエリやデータロードが失敗する可能性があります。そのため、オフピーク時間帯にスケールアップを実施することをお勧めします。
• クラスターがストレージとしてインスタンスストアボリュームを使用している場合、スケールアップにかかる時間はクラスター内のデータ量によって異なります。

以下の手順に従ってください：

1. にサインインします。PhoenixAI Cloud BYOC コンソール。

2. Clustersページで、スケーリングするクラスターをクリックします。

3. クラスターの詳細ページで、Manageをクリックし、Edit clusterを選択します。

   注記

   スケーリングできるのは、Running状態にあるクラスターのみです。クラスターがRunning状態にない場合、Edit clusterメニュー項目は無効になります。

4. 表示されたページで、スケールするノードのタイプをNode typeドロップダウンリストから選択し、Scale up/downをOperation typeドロップダウンリストから選択し、Compute NodeをNode typeとして選択した場合はウェアハウスの名前を選択します。次に、スケール先のインスタンスタイプを選択し、Subscribeをクリックします。

5. 表示されたメッセージで、スケーリング設定を確認し、Subscribeをクリックします。

   クラスターはUpdating状態になります。

   PhoenixAIは新しいインスタンスタイプのインスタンスを起動し、元のインスタンスから新しいインスタンスへデータとワークロードを移行するために一定の時間を要します。その間、料金は引き続き元のインスタンスタイプに基づいて計算されます。

   スケーリング操作が完了すると、クラスターはRunning状態に戻ります。

水平スケーリング

スケールアウトまたはスケールインの場合、以下が可能です：

• ウェアハウス内のコンピュートノードの数を編集します。

• コーディネーターノードの数のみを1、3、5、6、7、8、9、10、または11に設定します。

  注記

  コーディネーターノードは、リーダー、フォロワー、およびオブザーバーとして機能できます。リーダーノードはメタデータの読み取りと書き込みを行います。フォロワーノードはメタデータの読み取りのみを行い、リーダーノードがクラッシュした際のリーダー選出に参加します。オブザーバーノードはメタデータの読み取りのみを行い、選出には参加しません。クラスターのクエリ同時実行数を増やすためにのみ使用されます。

  3つまたは5つのコーディネーターノードをデプロイして、高可用性コーディネーターノードグループを構築し、サービスにおける単一障害点（SPOF）を防ぐことができます。グループ内のすべてのコーディネーターノードはフォロワーノードであり、そのうちの1つがリーダーノードとして選出されます。5つのフォロワーノード以外に、クラスターに追加されたコーディネーターノードはオブザーバーノードになります。

  高可用性ソリューションの詳細については、StarRocksアーキテクチャをご覧ください。

以下の手順に従ってください：

1. PhoenixAI Cloud BYOCコンソールにサインインします。

2. Clustersページで、スケールするクラスターをクリックします。

3. クラスターの詳細ページで、Manageをクリックし、Edit clusterを選択します。

   注記

   スケールできるのはRunning状態のクラスターのみです。クラスターがRunning状態でない場合、Edit clusterメニュー項目は無効になります。

4. 表示されたページで、Node typeドロップダウンリストからスケールするノードの種類を選択し、Scale in/outからOperation type ドロップダウンリストで、倉庫の名前を選択します（ Compute Node を Node type として選択した場合）。次に、必要なノード数を指定し、 Subscribe。

5. 表示されたメッセージで、スケーリング設定を確認し、 Subscribe をクリックします。

   クラスターは Updating 状態になります。

   PhoenixAI が現在のインスタンスタイプのインスタンスを解放または起動するまでに時間がかかる場合があり、その間も料金は元のノード数に基づいて計算されます。

   スケーリング操作が完了すると、クラスターは Running 状態に戻ります。

   注記

   クラスターでマルチAZデプロイメントが有効になっている場合、コンピュートノードは3つのアベイラビリティゾーンにできるだけ均等に分散されます。PhoenixAI のマルチAZデプロイメントの詳細については、 マルチAZデプロイメント を参照してください。

ストレージのスケーリング

手動スケーリング

ストレージのスケーリングはコーディネーターノードのみ対象です。ディスクサイズに加えて、ディスクの IOPS とスループットも編集できます。

以下の手順に従ってください：

1. にサインインします。PhoenixAI Cloud BYOC コンソール。

2. Clusters ページで、スケーリングするクラスターをクリックします。

3. クラスターの詳細ページで、 Manage をクリックし、 Edit cluster を選択します。

   注記

   スケールできるのは、Running状態にあるクラスターのみです。クラスターがRunning状態にない場合、Edit clusterメニュー項目は無効になります。

4. 表示されたページで、Coordinator NodeドロップダウンリストからNode typeを選択し、Edit storageドロップダウンリストからOperation typeを選択して、スケールするストレージのDisk IOPS、Disk throughput、およびDisk sizeを指定し、Subscribeをクリックします。

   注記

   • Coordinator Node あたりの最小ディスク IOPS は 3000 です。
   • Coordinator Node あたりの最小ディスクスループットは 150 MB/s です。
   • Coordinator Node あたりの最小ディスクサイズは 30 GB です。

5. 表示されたメッセージで、スケーリング設定を確認し、Subscribeをクリックします。

   クラスターはUpdating状態になります。

   PhoenixAI がストレージリソースの解放または起動に時間を要する場合があり、その間も料金は元のストレージサイズに基づいて計算されます。

   スケーリング操作が完了すると、クラスターはRunning状態に戻ります。

ストレージ自動スケーリング

ストレージ自動スケーリングはデフォルトで有効になっています。コーディネーターノードのストレージ自動スケーリングポリシーを定義できます。PhoenixAIはノードのストレージ使用量を監視し、ストレージ使用量が事前に定義されたしきい値に達したことを検出すると、自動的にストレージをスケールアップします。

注記

クラスターに予測不可能なワークロードがある場合、ストレージ自動スケーリングを有効のままにしておくことを強くお勧めします。予測不可能なワークロードはストレージをすぐに使い果たし、クラスターの重大な障害を引き起こす可能性があります。

コーディネーターノードのストレージ自動スケーリングポリシーを定義するには、次の手順に従ってください。

1. にサインインします。PhoenixAI Cloud BYOCコンソール。

2. Clustersページで、ストレージ自動スケーリングポリシーを設定するクラスターをクリックします。

3. クラスターの詳細ページで、Resource Schedulingタブをクリックします。

4. Storage autoscaling policyセクションで、Editをクリックします。

5. 表示されるダイアログボックスで、ストレージ自動スケーリングポリシーを次のように設定します。

   a. Coordinator Storageの後のスイッチをオンにして、ストレージ自動スケーリングを有効にします。

   b. 自動スケーリング操作をトリガーするストレージ使用量のしきい値（パーセンテージ）を設定します。このしきい値は80%から90%の間で設定できます。ノードのストレージ使用量がこのしきい値に達し、5分以上継続した場合、PhoenixAIは次の手順で定義したステップサイズでストレージをスケールアップします。

   c. 各自動スケーリング操作のステップサイズを設定します。ステップサイズは固定サイズ（GB）またはパーセンテージで設定できます。例えば、50 GBまたは15%（元のストレージサイズに対して）などです。

   d. 各ノードの最大ストレージサイズを設定します。ストレージのサイズがこのしきい値に達すると、PhoenixAIはストレージのスケールアップを停止します。

6. Submitをクリックしてポリシーを保存します。

注記

• 現在、Azureベースのクラスターはストレージ自動スケーリングをサポートしていません。
• AWSベースのクラスターでは、2回のスケーリング操作（手動スケーリングと自動スケーリングを含む）の間隔として最低6時間が必須です。GCPベースのクラスターでは、間隔は4時間です。
• 各ストレージの最大サイズは、AWSベースのクラスターでは16 TB、GCPベースのクラスターでは64 TBです。
• コンピュートノードは自動スケーリングをサポートしていません。

コンピュートスケーリング

コンピュート自動スケーリング

各ウェアハウスの自動スケーリング戦略を定義して、内部のコンピュートノードまたはコンピュートノードグループの数を適応的に調整できるようにすることができます。PhoenixAIはウェアハウスのCPU使用率またはクエリキューの長さをリアルタイムで評価し、設定したポリシーに基づいてコンピュートノードまたはグループをスケーリングすることで、可能な限り低コストで安定した予測可能なパフォーマンスを維持できるよう支援します。

注記

• コンピュート自動スケーリングは、v4.0より前のデータベースカーネルバージョンで実行されるマルチAZデプロイメントクラスターでは利用できません。
• v4.0以降、マルチAZデプロイメントクラスターはGroup Scaling戦略を採用してコンピューティングリソースをスケールできます。

PhoenixAIは2つのスケーリング戦略を提供します：

• Node Scaling戦略はノードの粒度でコンピューティングリソースをスケールし、2つのスケーリングポリシーを提供します -CPU utilization basedポリシーとQuery queue basedポリシー。

  • CPU utilization basedポリシーが有効になっている場合、システムはウェアハウスのCPU使用率を評価します。ウェアハウスのCPU使用率が事前に指定された時間、事前に指定された上限を超えた場合、追加のコンピュートノードがウェアハウスに追加されます。逆に、CPU使用率が指定された時間、下限を下回った場合、余分なコンピュートノードがウェアハウスから削除されます。
  • Query queue basedポリシーが有効になっている場合、システムはウェアハウスのクエリキューの長さを評価します。ウェアハウスのクエリキューの長さが事前に指定された上限を超えるか、キューの最初のクエリが事前に指定された時間以上待機している場合、追加のコンピュートノードがウェアハウスに追加されます。逆に、ウェアハウスのリソース使用率が事前に指定された時間、事前に指定された下限を下回った場合、余分なコンピュートノードがウェアハウスから削除されます。

• Group Scaling戦略はコンピュートノードグループの粒度でコンピューティングリソースをスケールします。コンピュートノードグループとは、ウェアハウス作成時にCompute Node countとして定義されたコンピュートノードのグループです。Group Scaling戦略はQuery queue basedスケーリングポリシーのみを提供します。ウェアハウスのクエリキューの長さが事前に指定された上限を超えるか、キューの最初のクエリが事前に指定された時間以上待機している場合、追加のコンピュートノードグループがウェアハウスに追加されます。逆に、ウェアハウスのリソース使用率が事前に指定された時間、事前に指定された下限を下回った場合、コンピュートノードグループがウェアハウスから削除されます。

以下の手順に従ってください：

1. PhoenixAI Cloud BYOCコンソールにサインインします。

2. Clustersページで、オートスケーリングを有効にしたいウェアハウスが存在するエラスティッククラスターをクリックします。

3. クラスター詳細ページのWarehousesタブで、ウェアハウスのカードの右下隅にカーソルを移動してView more detailsボタンを表示し、そのボタンをクリックします。

4. Resource Schedulingタブをクリックします。次に、Editの中のAutoscaling Policy セクション。

5. Edit autoscaling policyダイアログボックスで、Autoscalingドロップダウンリストからオートスケーリング戦略を選択します。Node ScalingまたはGroup Scalingを選択できます。自動スケーリング戦略の選び方に関する詳しい手順については、付録 - コンピュートスケーリング戦略の選択に関するベストプラクティスを参照してください。

   • Node Scaling戦略を選択した場合、Scaling range（ウェアハウス内のコンピュートノードの最小数と最大数）を指定し、次にScaling policyを選択します。CPU utilization basedまたはQuery queue basedを選択できます。

     Experimental

     この機能はPhoenixAIサポートによって有効化される必要があります。ご利用を希望される場合は、サポートケースを開いてください。

     実験的機能の使用に関するアドバイス

     • CPU utilization basedスケーリングポリシーを選択した場合、スケールアウトおよびスケールインポリシーを次のように設定します：

       a. Scale out policyセクションで、CPU使用率の上限、時間しきい値、および各ステップでスケールアウトするコンピュートノードの数を設定します。

       b. Scale in policyセクションで、CPU使用率の下限、時間しきい値、および各ステップでスケールインするコンピュートノードの数を設定します。

     • Query queue basedスケーリングポリシーを選択した場合、スケールアウトおよびスケールインポリシーを次のように設定します：

       Experimental

       この機能はPhoenixAIサポートによって有効化される必要があります。ご利用を希望される場合は、サポートケースを開いてください。

       実験的機能の使用に関するアドバイス

       a. Scale out policyセクションで、最大クエリキュー長およびキュー内の最初のクエリの待機時間しきい値を設定します。

       b. Scale in policyセクションで、リソース使用率の下限、時間しきい値、および各ステップでスケールインするコンピュートノードの数を設定します。

   • Group Scaling戦略を選択した場合、Scaling range（ウェアハウス内のコンピュートノードグループの最小数と最大数）を指定し、以下のようにスケールアウトおよびスケールインポリシーを設定する必要があります：

     Experimental

     この機能はPhoenixAIサポートによって有効化される必要があります。ご利用を希望される場合は、サポートケースを開いてください。

     実験的機能の使用に関するアドバイス

     a. Scale out policyセクションで、最大クエリキュー長およびキュー内の最初のクエリの待機時間しきい値を設定します。

     b. Scale in policyセクションで、リソース使用率の下限、時間しきい値、および各ステップでスケールインするコンピュートノードグループの数を設定します。

     注記

     • 自動スケーリングポリシーは、ウェアハウスが実行中の場合にのみ有効になります。
     • Node Scalingの場合、Scaling rangeの下限は 1、上限は 100 です。
     • Group Scalingの場合、Scaling rangeの下限は 1、上限はシングルAZデプロイメントでは 10、マルチAZデプロイメントでは 2 および 20 です。
     • スケールアウトポリシーは、現在のコンピュートノードまたはコンピュートノードグループの数が、定義したScaling rangeの上限未満の場合にのみ有効になります。
     • スケールインポリシーは、現在のコンピュートノードまたはコンピュートノードグループの数が、定義したScaling rangeの下限を超える場合にのみ有効になります。
     • スケールアウトポリシーのCPU使用率の上限は、スケールインポリシーの下限より大きくなければなりません。
     • クラスターパフォーマンスの大幅な変動を避けるため、1ステップあたりスケールインできるコンピュートノードまたはコンピュートノードグループは最大2つまでです。
     • ウェアハウスクエリキューおよびコンピュートノードグループの監視メトリクスについては、ウェアハウスクエリキューのメトリクスおよびウェアハウスCNグループのメトリクスを参照してください。

6. クリックSave changesポリシーを保存するには。

スケジュールされたコンピュートスケーリング

各ウェアハウスのコンピュートリソースに対して、スケジュールされたスケーリングポリシーを定義できます。

以下の手順に従ってください：

1. にサインインします PhoenixAI Cloud BYOC コンソール。

2. Clusters ページで、オートスケーリングを有効にするウェアハウスが存在するエラスティッククラスターをクリックします。

3. Warehouses クラスター詳細ページのタブで、ウェアハウスのカードの右下隅にカーソルを移動して View more details ボタンを表示し、そのボタンをクリックします。

4. Resource Scheduling タブをクリックします。次に、Create の Scheduled Scaling Policy セクションをクリックします。

5. Scheduled Scaling Policy ダイアログボックスで、スケジュールされたスケーリングポリシーを次のように設定します：

   a. Policy name フィールドに、作成するポリシーの名前を入力します。

   b. 必要に応じて、Policy description フィールドにポリシーの説明を追加します。

   c. Time zone ドロップダウンリストで、ポリシーのタイムゾーンを選択します。この設定はポリシーの有効時間にのみ影響します。

   d. Policy enabled スイッチをオンのままにします。

   e. Warehouse size フィールドで、スケールするコンピュートノード数を指定します。

   注記

   • の下限は Warehouse size の範囲は 1。
   • の上限は Warehouse size の範囲は 100。

:::

f. Schedule type ドロップダウンリストで、ポリシーの繰り返しタイプを選択します。One-time、Daily、Weekly、または Monthlyを選択できます。

• One-timeを選択した場合、Select the date フィールドでスケジュールの有効日を選択する必要があります。
• Weeklyを選択した場合、Days of week フィールドでスケジュールの曜日を選択する必要があります。
• Monthlyを選択した場合、Days of month フィールドでスケジュールの日付を選択する必要があります。

g. Start time および End timeフィールドで、ポリシーの有効な時間範囲を指定できます。

6. Save changesをクリックして、ポリシーを作成します。

注記

• クラスターの異なるポリシー間で有効期間が重複することは許可されていません。
• スケジュールされたスケーリングポリシーは、クラスターがRunning状態のときのみ有効です。クラスターが（自動または手動で）一時停止されている場合、ポリシーは有効になりません。クラスターが再開されると、ポリシーは次の開始時刻に有効になります。

付録

コンピュートスケーリング戦略の選択に関するベストプラクティス

PhoenixAI では、コンピュートのオートスケーリング戦略として Node Scaling と Group Scaling の 2 種類を提供しています。どちらの戦略も、ワークロードに応じてウェアハウスのコンピュートリソースを自動的にスケールしますが、スケールの単位が異なるため、適したワークロードやデプロイメント構成も異なります。

スケーリングポリシーを選択する前に、以下の比較を参考に、ワークロードに最適なスケーリング戦略を選択してください。

項目	ノードスケーリング	グループスケーリング
スケール単位	個々の Compute Node	Compute Node Group
適したワークロード	小規模クエリが多い環境、きめ細かなスケーリングが必要な場合	複数ノードにまたがる大規模集計クエリ、高い同時実行性が求められる場合
Multi-AZ デプロイメント	v4.0 以降では非対応	ネイティブ対応（AZ 間の高可用性を提供）
AZ 間データ転送	集計処理時に AZ をまたいでデータシャッフルが発生する可能性がある	シャッフル処理はグループ内の AZ に限定される
利用可能なスケーリングポリシー	CPU 使用率、クエリキュー	クエリキューのみ

グループスケーリングを選択すべきケース

次のいずれかに該当する場合は、グループスケーリングを推奨します。

• Multi-AZ デプロイメントを利用している場合。v4.0 以降では、Multi-AZ をサポートするスケーリング戦略はグループスケーリングのみです。Compute Node Group 単位で追加削除を行うため、各 AZ のノード配置を均等に維持し、偏ったリソース配置を防止できます。
• 複数ノードにまたがる大規模な集計クエリを実行する場合。グループスケーリングでは、関連するコンピュートリソースを同じグループ内に配置できるため、JOIN や集計処理に伴うデータシャッフルを単一グループ内に限定できます。これにより、AZ 間通信によるレイテンシやデータ転送量を削減できます。
• 大規模クエリを高い同時実行数で処理する必要がある場合。多数の重いクエリが同時に実行される環境では、ノードを 1 台ずつ追加するよりも、Compute Node Group 全体を一度に追加する方が、より迅速かつ予測可能なスケールアウトを実現できます。
• AZ 間データ転送コストを削減したい場合。Compute Node Group は単一 AZ 内に配置されるため、シャッフルトラフィックは AZ 内に留まり、AZ 間データ転送が発生しません。
• AZ 障害に対する高可用性 (HA) が必要な場合。Compute Node Group は複数の AZ に分散配置されるため、単一 AZ の障害が発生しても、ウェアハウス全体の可用性を維持できます。

ノードスケーリングを選択すべきケース

次のいずれかに該当する場合は、ノードスケーリングを推奨します。

• 小規模なクエリを多数実行する場合。Compute Node を 1 台単位で追加削除するきめ細かなスケーリングにより、小規模クエリによる緩やかな負荷変動へ効率よく対応できます。
• CPU 使用率に基づくスケーリングを利用したい場合。CPU 使用率をトリガーとするスケーリングポリシーは、ノードスケーリングのみでサポートされています。グループスケーリングでは、クエリキュー長のみを基準としてスケーリングが行われます。
• Single-AZ デプロイメントでコストを重視する場合。ノードスケーリングは、より小さな単位でリソースを増減できるため、グループ単位のスケーリングが不要なワークロードでは、コストをより細かく制御できます。