Azure Synapse Analytics ワークロード グループ分離
この記事では、ワークロード グループを使用してワークロードの分離を構成する方法、リソースを含める方法、およびクエリ実行のランタイム ルールを適用する方法について説明します。
ワークロード グループ
ワークロード グループは、一連の要求のコンテナーであり、ワークロードの分離などのワークロードの管理をシステム上で構成するための基礎となります。 ワークロード グループは、CREATE WORKLOAD GROUP 構文を使用して作成されます。 単純なワークロード管理構成では、データの読み込みとユーザークエリを管理できます。 たとえば、wgDataLoads という名前のワークロード グループは、システムに読み込まれるデータのワークロードの側面を定義します。 また、wgUserQueries という名前のワークロード グループは、システムからデータを読み取るクエリを実行するユーザーのワークロードの側面を定義します。
次のセクションでは、ワークロード グループが分離、包含、要求リソース定義を定義し、実行ルールに準拠する機能を提供する方法について説明します。
リソース管理
ワークロード グループでは、メモリ リソースと CPU リソースを管理します。 ディスクとネットワークの IO および tempdb は管理されません。 メモリと CPU のリソース管理は次のようになります。
メモリは要求レベルで管理され、要求が存続する間は保持されます。 要求ごとのメモリ量を構成する方法の詳細については、「要求の定義ごとのリソース」を参照してください。 ワークロード グループに対する MIN_PERCENTAGE_RESOURCE パラメーターを指定すると、メモリはそのワークロード グループ専用になります。 ワークロード グループに対する CAP_PERCENTAGE_RESOURCE パラメーターは、ワークロード グループが使用できるメモリのハード制限です。
CPU リソースはワークロード グループ レベルで管理され、ワークロード グループ内のすべての要求によって共有されます。 実行期間中は要求に専用となるメモリと比べ、CPU リソースは流動的です。 CPU が流動的リソースであるため、未使用の CPU リソースはすべてのワークロード グループが使用できます。 これは、CPU 使用率がワークロード グループに対する CAP_PERCENTAGE_RESOURCE パラメーターを超える可能性があることを意味します。 また、ワークロード グループに対する MIN_PERCENTAGE_RESOURCE パラメーターが、メモリの場合のようなハード予約でないことも意味します。 CPU リソースが競合している場合、使用率はワークロード グループの CAP_PERCENTAGE_RESOURCE の定義に合わせて調整されます。
ワークロードの分離
ワークロードの分離とは、リソースがワークロード グループ専用で予約されることを意味します。 ワークロードを分離するには、CREATE WORKLOAD GROUP 構文で MIN_PERCENTAGE_RESOURCE パラメーターを 0 より大きい値に設定します。 厳格な SLA に従う必要がある継続的な実行ワークロードの場合、分離することでワークロード グループで常にリソースが使用できるようになります。
ワークロードの分離を構成することで、保証されるコンカレンシーのレベルを暗黙的に定義します。 たとえば、MIN_PERCENTAGE_RESOURCE を 30% が設定され、REQUEST_MIN_RESOURCE_GRANT_PERCENT が 2% に設定されたワークロード グループでは、15 のコンカレンシーが保証されます。 コンカレンシーのレベルが保証されるのは、リソースの 15 から 2% のスロットがワークロード グループ内で常に予約されるためです (REQUEST_MAX_RESOURCE_GRANT_PERCENT がどのように構成されているかは関係ありません)。 REQUEST_MAX_RESOURCE_GRANT_PERCENT が REQUEST_MIN_RESOURCE_GRANT_PERCENT より大きく、CAP_PERCENTAGE_RESOURCE が MIN_PERCENTAGE_RESOURCE より大きい場合、要求ごとにさらにリソースを (リソースの可用性に基づいて) 追加できます。 REQUEST_MAX_RESOURCE_GRANT_PERCENT と REQUEST_MIN_RESOURCE_GRANT_PERCENT が同じであり、CAP_PERCENTAGE_RESOURCE が MIN_PERCENTAGE_RESOURCE より大きい場合、追加のコンカレンシーが可能です。 保証されるコンカレンシーを決定するには、次の方法を検討してください。
[保証されるコンカレンシー] = [MIN_PERCENTAGE_RESOURCE]/[REQUEST_MIN_RESOURCE_GRANT_PERCENT]
Note
min_percentage_resource には、特定のサービス レベルの最小値があります。 詳細については、有効な値に関する記事を参照してください。
ワークロードの分離がされない場合、要求はリソースの共有プールで動作します。 共有プール内のリソースへのアクセスは保証されず、重要度基準で割り当てられます。
ワークロード グループにアクティブな要求がない場合でもワークロード グループにはリソースが割り当てられるため、ワークロードの分離の構成は慎重に行う必要があります。 必要以上に分離するよう構成すると、システム全体の使用率が低下する可能性があります。
ワークロードの分離を 100% 構成するワークロード管理ソリューションは使用しないでください。100% の分離は、すべてのワークロード グループで構成されている min_percentage_resource の合計が 100% である状態です。 この種類の構成は非常に限定的で厳格であり、誤って分類されたリソース要求を扱う余裕がほとんどなくなってしまいます。 分離用に構成されていないワークロード グループから要求を 1 つ実行することを許可するプロビジョニングがあります。 この要求に割り当てられたリソースは、システム DMV に 0として表示され、システムで予約されたリソースから smallrc レベルのリソース付与を借用します。
Note
リソース使用率を最適化するには、分離を活用して SLA が満たされていることを確認し、ワークロードの重要度に基づいてアクセスされる共有リソースと混在させることを検討してください。
ワークロードの包含
ワークロードの包含とは、ワークロード グループが使用できるリソースの量を制限することを指します。 ワークロードを包含するには、CREATE WORKLOAD GROUP 構文で CAP_PERCENTAGE_RESOURCE パラメーターを 100 より小さい値に設定します。 アドホック クエリを使用して what-if 分析を実行できるよう、ユーザーがシステムへの読み取りアクセスを必要とするシナリオを考えてみます。 このような要求は、システムで実行されている他のワークロードに悪影響を与える可能性があります。 包含を構成すると、リソースの量が制限されます。
ワークロードの包含の構成では、コンカレンシーの最大レベルが暗黙的に定義されます。 CAP_PERCENTAGE_RESOURCE を 60% に設定し、REQUEST_MIN_RESOURCE_GRANT_PERCENT を 1% に設定した場合、ワークロード グループではレベル 60 のコンカレンシーが保証されます。 コンカレンシーの最大数を決定するには、次の方法を検討してください。
[最大コンカレンシー] = [CAP_PERCENTAGE_RESOURCE] / [REQUEST_MIN_RESOURCE_GRANT_PERCENT]
Note
MIN_PERCENTAGE_RESOURCE のレベルが 0 より大きいワークロード グループが作成されている場合、ワークロード グループの有効な CAP_PERCENTAGE_RESOURCE は100% にはなりません。 有効なランタイム値については、「ssys.dm_workload_management_workload_groups_stats」を参照してください。
要求の定義ごとのリソース
ワークロード グループは、REQUEST_MIN_RESOURCE_GRANT_PERCENT パラメーターと REQUEST_MAX_RESOURCE_GRANT_PERCENT パラメーターで要求ごとに割り当てられるリソースの最小容量と最大量を CREATE WORKLOAD GROUP 構文で定義するメカニズムを提供します。 この場合のリソースはメモリです。 CPU リソースの管理については、「リソース管理」セクションを参照してください。
Note
REQUEST_MAX_RESOURCE_GRANT_PERCENT は省略可能なパラメーターで、既定値は REQUEST_MIN_RESOURCE_GRANT_PERCENT に対して指定されている値と同じです。
リソース クラスを選択する場合と同様に、REQUEST_MIN_RESOURCE_GRANT_PERCENT を構成すると要求によって使用されるリソースの値が設定されます。 設定値によって示されるリソース量は、要求が実行を開始する前に、その要求に割り当てられることが保証されます。 リソース クラスからワークロード グループに移行するお客様については、まずハウツーに関する記事に従って、リソース クラスからワークロード グループへマッピングすることを検討してください。
REQUEST_MIN_RESOURCE_GRANT_PERCENT を超える値に REQUEST_MAX_RESOURCE_GRANT_PERCENT を構成すると、システムは要求ごとにより多くのリソースを割り当てることができます。 要求のスケジュール設定中に、システムは、共有プールのリソースの可用性とシステムの現在の負荷に基づいて、要求に対する実際のリソース割り当てを REQUEST_MIN_RESOURCE_GRANT_PERCENT と REQUEST_MAX_RESOURCE_GRANT_PERCENT の間で決定します。 クエリがスケジュールされている場合は、リソースの共有プールにリソースが存在している必要があります。
Note
REQUEST_MIN_RESOURCE_GRANT_PERCENT と REQUEST_MAX_RESOURCE_GRANT_PERCENT には、有効な MIN_PERCENTAGE_RESOURCE と CAP_PERCENTAGE_RESOURCE の値に依存する有効な値があります。 有効なランタイム値については、「ssys.dm_workload_management_workload_groups_stats」を参照してください。
実行規則
アドホック レポート システムでは、他のユーザーの生産性に深刻な影響を与えるランナウェイ クエリを誤って実行する可能性があります。 システム管理者は、システム リソースを解放するために、ランナウェイ クエリの強制終了に時間を費やすことになります。 ワークロード グループには、指定された値を超えたクエリを取り消すクエリ実行タイムアウトルールを構成する機能があります。 ルールを構成するには CREATE WORKLOAD GROUP 構文で QUERY_EXECUTION_TIMEOUT_SEC パラメーターを設定します。
共有プールのリソース
共有プールのリソースは、分離用に構成されていないリソースです。 MIN_PERCENTAGE_RESOURCE が 0 に設定されたワークロード グループは、共有プール内のリソースを利用して要求を実行します。 CAP_PERCENTAGE_RESOURCE が MIN_PERCENTAGE_RESOURCE よりも大きいワークロード グループも、共有リソースを使用します。 共有プールで利用できるリソースの量は、次のように計算されます。
[共有プール] = 100-[すべてのワークロード グループにおける MIN_PERCENTAGE_RESOURCE の合計]
共有プール内のリソースへのアクセスは、重要度基準で割り当てられます。 重要度レベルが同じ要求は、先入れ先出しで共有プールリソースにアクセスします。