メインコンテンツまでスキップ
に最終更新

ワークロードグループをコンピュートグループに紐付ける：ワークロード間のリソース分離

ワークロードグループをコンピュートグループに紐付ける理由​

Doris では、コンピュートグループを使ってクラスター内の BE ノードを論理的にグループ化し、ワークロード間でコンピュートリソースを分離する独立したサブクラスターを構成できます。

以前のバージョンでは、ワークロードグループはすべてのコンピュートグループに対してグローバルに有効であり、異なるワークロードが同じリソース割り当て設定を共有する必要がありました。たとえば、次のような状況です。

  • ワークロード A とワークロード B がそれぞれワークロードグループを作成し、そのリソース割り当ての合計がすでに 100% に達していました。
  • ワークロード A は追加のワークロードグループを作成できませんでした。
  • 二つのワークロードでは必要なワークロードグループの設定が大きく異なっていましたが、従来の構成ではワークロードごとに独立して管理できませんでした。

この問題に対処するため、現行バージョンではワークロードグループをコンピュートグループに紐付ける仕組みが導入され、各コンピュートグループが独立したワークロードグループ設定を持てるようになりました。

コンピュートグループとリソースグループの関係​

構成の種類対応する概念説明
ストレージ・コンピュート分離型コンピュートグループ独立したサブクラスターを構成するための論理的な分割単位
ストレージ・コンピュート一体型リソースグループ機能上、コンピュートグループに相当

リソース管理については、この二つを論理的に同等の概念として扱えます。本書に記載するワークロードグループとコンピュートグループの紐付けは、ストレージ・コンピュート分離型と一体型の両方の構成に適用されます。

仕組み​

以前のバージョンの設計​

クラスターに、ワークロード A を処理するコンピュートグループ A と、ワークロード B を処理するコンピュートグループ B があるとします。また、二つのワークロードグループ group_a と group_b があり、そのリソース割り当ての合計は 100% です。

以前のバージョンでは、group_a と group_b はコンピュートグループの境界に制限されず、すべての BE ノードで有効でした。次の図に示します。

以前のバージョン：ワークロードグループが全体に適用される

その結果、次の問題が生じました。

  • ワークロード A が group_a を作成するとリソース割り当てが上限に達し、追加のワークロードグループを作成できなくなりました。
  • 二つのワークロードのワークロードグループ設定が互いに影響し、用途に応じた管理が困難でした。

現行バージョンの設計​

現行バージョンでは、ワークロードグループを特定のコンピュートグループに紐付けられます。異なるコンピュートグループは、それぞれ独立したワークロードグループ設定を持ちます。 次の図に示します。

現行バージョン：コンピュートグループごとにワークロードグループを分離する

使用方法​

デフォルトのコンピュートグループ

Doris にはデフォルトのコンピュートグループの仕組みがあります。所属先を指定せずに新しい BE ノードを追加すると、そのノードは自動的にデフォルトのコンピュートグループに配置されます。

構成の種類デフォルトのコンピュートグループ名
ストレージ・コンピュート分離型default_compute_group
ストレージ・コンピュート一体型default
注意
FOR 句の動作は構成によって異なります
  • クラウド（ストレージ・コンピュート分離）モード：CREATE / ALTER / DROP WORKLOAD GROUP には、FOR <compute_group> 句を明示的に指定する必要があります。省略すると、Must specify compute group via 'FOR <compute_group>' in cloud mode. というエラーが発生します。
  • 非クラウド（ストレージ・コンピュート一体）モード：FOR <compute_group> 句は省略可能です。この値は実際のコンピュートグループではなく、リソースグループ（Tag）を指します。クラウドモードと構文を統一するために同じ文法を使用しています。省略した場合は、デフォルトのリソースグループ（default）が使用されます。

ワークロードグループの作成​

特定のコンピュートグループに紐付ける場合：

CREATE WORKLOAD GROUP group_a FOR compute_group_a PROPERTIES ('cpu_share'='1024');

コンピュートグループを指定しない場合（非クラウドモードのみ。デフォルトのリソースグループに紐付けられます）：

CREATE WORKLOAD GROUP group_a PROPERTIES ('cpu_share'='1024');

ワークロードグループの削除​

特定のコンピュートグループから削除する場合：

DROP WORKLOAD GROUP group_a FOR compute_group_a;

コンピュートグループを指定しない場合（非クラウドモードのみ。デフォルトのリソースグループから削除されます）：

DROP WORKLOAD GROUP group_a;

ワークロードグループのプロパティの変更​

特定のコンピュートグループに属するワークロードグループのプロパティを変更する場合：

ALTER WORKLOAD GROUP group_a FOR compute_group_a PROPERTIES ('cpu_share'='2048');

コンピュートグループを指定しない場合（非クラウドモードのみ。デフォルトのリソースグループに属するワークロードグループが変更されます）：

ALTER WORKLOAD GROUP group_a PROPERTIES ('cpu_share'='2048');
注記

ALTER 文は、ワークロードグループのプロパティの変更にのみ使用します。ワークロードグループとコンピュートグループの紐付けは変更できません。

ワークロードポリシーからワークロードグループを参照する​

ワークロードポリシーの workload_group プロパティ（CREATE WORKLOAD POLICY / ALTER WORKLOAD POLICY）では、ワークロードグループがコンピュートグループに属するため、値は次の規則に従う必要があります。

  • クラウド（ストレージ・コンピュート分離）モード：<compute_group>.<workload_group> という完全修飾形式が必要です。例：

    CREATE WORKLOAD POLICY p1 CONDITIONS(query_time > 3000) ACTIONS(cancel_query)
    PROPERTIES('workload_group'='compute_group_a.wg1');

  • 非クラウド（ストレージ・コンピュート一体）モード：<workload_group>（デフォルトのリソースグループ）と <resource_group>.<workload_group> の両方を使用できます。

注意事項​

  1. 紐付けは変更できません：ワークロードグループは作成時に特定のコンピュートグループに割り当てられ、コンピュートグループ間で移動することはできません。

  2. アップグレード時の動作：以前のバージョンから現行バージョンにアップグレードすると、システムは既存のワークロードグループを基に、コンピュートグループごとに同名で ID が異なる新しいワークロードグループを自動的に作成します。たとえば、以前のバージョンでコンピュートグループが二つあり、group_a が存在していた場合、アップグレード後には各コンピュートグループに group_a という名前の新しいワークロードグループが作成されます。どのコンピュートグループにも属していなかった元の group_a は自動的に削除されます。

  3. 権限管理は変更されません：ワークロードグループの権限チェックは引き続きワークロードグループ名との紐付けに基づいて行われ、管理方法も以前のバージョンと同じです。

  4. normal ワークロードグループのライフサイクル：Doris には normal という名前のデフォルトのワークロードグループがあります。新しいコンピュートグループが作成されると、対応する normal ワークロードグループがシステムによって自動的に作成されます。コンピュートグループが削除されると、関連する normal ワークロードグループも自動的に削除されます。normal ワークロードグループのライフサイクルはシステムがすべて管理するため、手動操作は不要です。

Report issue