マルチクラスターウェアハウス¶
マルチクラスターウェアハウスを使用すると、コンピューティングリソースを拡張して、ピーク時や営業時間外など、ユーザーとクエリの同時実行性のニーズを管理できます。
このトピックの内容:
マルチクラスターウェアハウスとは¶
デフォルトでは、仮想ウェアハウスは、クエリを実行するためにウェアハウスで使用可能なコンピューティングリソースの単一クラスターで構成されます。クエリがウェアハウスに送信されると、ウェアハウスは各クエリにリソースを割り当て、クエリの実行を開始します。ウェアハウスに送信されたすべてのクエリを実行するのに十分なリソースが利用できない場合、Snowflakeは必要なリソースが利用可能になるまで追加のクエリをキューに入れます。
Snowflakeは、マルチクラスターウェアハウスを使用して、静的または動的に追加のクラスターを割り当てて、より多くのコンピューティングリソースを利用できるようにします。マルチクラスターウェアハウスは、次のプロパティを指定することで定義されます。
クラスターの最大数。1より大きい(最大10)。
クラスターの最小数。最大値以下(最大10)。
さらに、マルチクラスターウェアハウスは、以下を含む単一クラスターウェアハウスと同じプロパティとアクションをすべてサポートしています:
ウェアハウスサイズの指定。
ウェアハウスのサイズの随時変更。
非アクティブ時における稼働中のウェアハウスの自動中断。これは個別のクラスターではなく、マルチクラスターウェアハウス全体に適用されることに注意してください。
新しいクエリの送信時における中断中のウェアハウスの自動再開。
最大化と自動スケール¶
次のいずれかのモードでマルチクラスターウェアハウスを実行することを選択できます:
- 最大化:
このモードを有効にするには、クラスターの最大数と最小数の両方に 同じ 値を指定します(指定した値は1より大きくなければならないことに注意してください)。このモードでは、ウェアハウスの起動時にSnowflakeがすべてのクラスターを起動するため、ウェアハウスの実行中に最大のリソースが利用可能になります。
このモードは、利用可能なコンピューティングリソースを静的に制御する場合、特に多数の同時ユーザーセッションやクエリがあり、その数が大幅に変動しない場合に効果的です。
- 自動スケール:
このモードを有効にするには、クラスターの最大数と最小数に 異なる 値を指定します。このモードでは、Snowflakeは必要に応じてクラスターを開始および停止し、ウェアハウスの負荷を動的に管理します:
ウェアハウスの同時ユーザーセッションやクエリの数が増加し、リソースが不十分なためクエリがキューに入り始めると、Snowflakeは自動的に追加のクラスターを、ウェアハウスに定義された最大数まで開始します。
同様に、ウェアハウスの負荷が減少すると、Snowflakeはクラスターを自動的にシャットダウンして、実行中のクラスターの数と、それに応じてウェアハウスで使用されるクレジットの数を減らします。
自動スケールモードでクレジットの使用を制御するために、Snowflakeは追加クラスターを自動的に開始またはシャットダウンするときに使用するスケーリングポリシーを決定するプロパティ SCALING_POLICYを提供します。詳細については、 マルチクラスターウェアハウスのスケーリングポリシーの設定 (このトピック内)をご参照ください。
Tip
マルチクラスターウェアハウスを作成するには、 マルチクラスターウェアハウスの作成 をご参照ください(このトピック内)。
次の点に注意してください。
マルチクラスターウェアハウスの場合、 Maximum Clusters フィールド(ウェブインターフェイス)または MAX_CLUSTER_COUNT プロパティ(SQL)の最大クラスター数は1 より大きく する必要があります。
単一クラスターウェアハウスでは、クラスターの最大数と最小数の 両方が1に等しくなる 必要があります。
オートスケールモードでは、最大クラスター数は最小クラスター数より 大きくする 必要があります。
最大化モードでは、最大クラスター数は最小クラスター数と 等しくなる 必要があります。
マルチクラスターウェアハウスに使用するクラスターの最大数と最小数を決定するときは、自動スケールモードと、小さい数値から始めます(例: 最大 = 2または3、最小= 1)。ウェアハウスの負荷が時間とともにどのように変動するかを追跡しながら、ユーザー/クエリの同時実行の上限と下限を最もよくサポートする数値を決定するまで、クラスターの最大数と最小数を増やしていきます。
マルチクラスターサイズとクレジット使用状況¶
各クラスターのコンピューティングリソースの量は、ウェアハウスのサイズによって決まります。
マルチクラスターウェアハウスのクラスターの合計数は、ウェアハウスサイズにクラスターの最大数を掛けて計算されます。これは、1時間の使用あたりのウェアハウスによって消費されるクレジットの最大数も示します(つまり、1時間に すべて のクラスターが実行される場合)。
たとえば、クラスターが3個あるMサイズのマルチクラスターウェアハウスで1時間あたりに消費されるクレジットの最大数は12クレジットです。
マルチクラスターウェアハウスのサイズが変更されると、新しいサイズは、現在実行中のクラスターや、マルチクラスターウェアハウスのサイズ変更後に開始されたクラスターを含む、ウェアハウスのクラスターの すべて に適用されます。
1時間あたりに消費されるクレジットの実際の数は、ウェアハウスが実行されている各時間中に実行されているクラスターの数によって異なります。詳細については、 マルチクラスタークレジットの使用状況例 (このトピック内)をご参照ください。
マルチクラスターウェアハウスの利点¶
標準の単一クラスタウェアハウスでは、ユーザー/クエリの負荷が増加して、より多くの計算リソースが必要になる場合:
ウェアハウスのサイズを増やすか、追加のウェアハウスを開始して、追加のユーザー/クエリをこれらのウェアハウスに明示的にリダイレクトする必要があります。
次に、リソースが不要になったら、クレジットを節約するために、より大きなウェアハウスを手動で縮小するか、追加のウェアハウスを中断する必要があります。
対照的に、マルチクラスターウェアハウスでは、より多くのユーザーが同じサイズのウェアハウスに接続できます。追加条件:
自動スケールモードでは、マルチクラスターウェアハウスにより、ウェアハウスのサイズを変更したり、変動するワークロードを処理するために追加のウェアハウスを開始および停止したりする必要がなくなります。Snowflakeは、必要に応じて追加のクラスターを自動的に開始および停止します。
最大化モードでは、必要に応じてクラスターの数を増減することにより、マルチクラスターウェアハウスの容量を制御できます。
Tip
マルチクラスターウェアハウスは、リソースをスケーリングしてユーザー/クエリの同時実行性を向上させるのに最適です。これらは、低速のクエリやデータのロードのパフォーマンスを向上させるのにそれほど有益ではありません。これらのタイプの操作の場合、 サイズ変更 ウェアハウスにはさらに多くの利点があります。
マルチクラスタークレジットの使用状況例¶
次の4つの例は、マルチクラスターウェアハウスのクレジット使用状況を示しています。ウェアハウスのサイズごとに、1時間あたりの請求されるクレジットの数については、 仮想ウェアハウスのクレジット使用状況 をご参照ください。
注釈
簡単にするために、これらのすべての例では、クレジットの使用状況を1時間、30分、および15分単位で示しています。1秒あたりの請求を使用する実際のシナリオでは、秒ごとの請求により、各クラスターが実行される秒数に基づいて、実際のクレジット使用状況に端数が含まれます。
例1: 最大化(2時間)¶
この例では、3個のクラスターを備えたMサイズのウェアハウスが、最大化モードで2時間実行されます。
クラスター1 |
クラスター2 |
クラスター3 |
クレジット合計 |
|
1時間目 |
4 |
4 |
4 |
12 |
2時間目 |
4 |
4 |
4 |
12 |
クレジット合計 |
8 |
8 |
8 |
24 |
例2: 自動スケール(2時間)¶
この例では、3個のクラスターを備えたMサイズのウェアハウスが、自動スケールモードで2時間実行されます。
クラスター1は継続的に実行されます。
クラスター2は2時間目だけ継続的に実行されます。
クラスター3、2時間目の間に30分間実行されます。
クラスター1 |
クラスター2 |
クラスター3 |
クレジット合計 |
|
1時間目 |
4 |
0 |
0 |
4 |
2時間目 |
4 |
4 |
2 |
10 |
クレジット合計 |
8 |
4 |
2 |
14 |
例3: 自動スケール(3時間)¶
この例では、3個のクラスターを備えたMサイズのウェアハウスが、自動スケールモードで3時間実行されます。
クラスター1は継続的に実行されます。
クラスター2は、3時間目の2時間全体と30分にわたって継続的に実行されます。
クラスター3は3時間目で30分間実行されます。
クラスター1 |
クラスター2 |
クラスター3 |
クレジット合計 |
|
1時間目 |
4 |
0 |
0 |
4 |
2時間目 |
4 |
4 |
0 |
8 |
3時間目 |
4 |
2 |
2 |
8 |
クレジット合計 |
12 |
6 |
2 |
20 |
例4: 自動スケール(3時間)とサイズ変更¶
この例では、例3と同じウェアハウスが自動スケールモードで3時間実行され、サイズがMからLに変更されます。
クラスター1は継続的に実行されます。
クラスター2は、2時間目と3時間目まで連続して実行されます。
ウェアハウスのサイズは、1時間半で中から大に変更されます。
クラスター3は3時間目で15分間実行されます。
クラスター1 |
クラスター2 |
クラスター3 |
クレジット合計 |
|
1時間目 |
4 |
0 |
0 |
4 |
2時間目 |
4+2 |
4+2 |
0 |
12 |
3時間目 |
8 |
8 |
2 |
18 |
クレジット合計 |
18 |
14 |
2 |
34 |
マルチクラスターウェアハウスの作成¶
ウェブインターフェイスまたは SQL を使用して、マルチクラスターウェアハウスを作成できます:
- ウェブインターフェイス:
Maximum Clusters フィールドで、1より大きい値を選択します。
Minimum Clusters フィールドで、オプションで1より大きい値を選択します。
必要に応じてウェアハウスのその他の情報を入力し、 Finish をクリックします。
- SQL:
次を使用して CREATE WAREHOUSE コマンドを実行します。
MAX_CLUSTER_COUNT
を1
より大きい値に設定します。
MIN_CLUSTER_COUNT
(オプション)を1
より大きい値に設定します。
作成したマルチクラスターウェアハウスに関する情報を表示するには、
- Classic Console:
Clusters 列には、各ウェアハウスの最小クラスターと最大クラスター、およびウェアハウスが開始された場合に現在実行されているクラスターの数が表示されます。
- SQL:
SHOW WAREHOUSES コマンドを実行します。
出力には3つの列(
min_cluster_count
、max_cluster_count
、started_clusters_column
)が含まれ、ウェブインターフェイスの Clusters 列で提供されるのと同じ情報が表示されます。
マルチクラスターウェアハウスの他のすべてのタスク(このトピックで説明する残りのタスクを除く)は、シングルクラスター ウェアハウスタスク と同じです。
マルチクラスターウェアハウスのスケーリングポリシーの設定¶
自動スケールモードで実行されているマルチクラスターウェアハウスによって消費されるクレジットを制御するために、Snowflakeはスケーリングポリシーを提供します。これは、クラスターを開始またはシャットダウンするタイミングを決定するために使用されます。
マルチクラスターウェアハウスのスケーリングポリシーは、自動スケールモードで実行されている場合にのみ適用されます。最大化モードでは、すべてのクラスターが同時に実行されるため、個々のクラスターを起動またはシャットダウンする必要はありません。
Snowflakeは、次のスケーリングポリシーをサポートしています:
ポリシー |
説明 |
ウェアハウスが始まります... |
ウェアハウスがシャットダウンします... |
---|---|---|---|
標準(デフォルト) |
クレジットの節約よりも追加クラスターの開始を優先することにより、キューを防止/最小化します。 |
クエリの処理待ち、 または システムが現在実行中のクラスターで実行できるクエリよりも1つ多いクエリが検出されると、最初のクラスターがただちに始まります。 連続する各クラスターは、前のクラスターが始まってから20秒の間、開始を待機します。たとえば、ウェアハウスが最大クラスター数10個で構成されている場合、クラスター10個すべてを開始するのに必要な時間は、丸々200秒以上かかる場合があります。 |
2~3つのチェック(1分間隔で実行)に連続して成功した後、クラスターを再起動せずに、最小負荷クラスターの負荷を他のクラスターに再分散できるかどうかが決定されます。 |
エコノミー |
追加のクラスターを開始するのではなく、実行中のクラスターを完全にロードしたままにしておくことでクレジットを節約します。これにより、クエリがキューに入れられ、完了までに時間がかかることがあります。 |
システムが、クラスターを少なくとも6分間ビジー状態に保つのに十分なクエリ負荷があると推定する場合のみ。 |
5から6の連続した成功したチェック(1分間隔で実行)の後。これにより、クラスターを再起動せずに、最小負荷クラスターの負荷を他のクラスターに再分散できるかどうかが決定されます。 |
注釈
下位互換性のために、3番目のスケーリングポリシー、Legacyが提供されました。他のポリシーとは対照的に、ウェアハウスがアクティブ/非アクティブである時間の長さに基づいた静的アプローチを使用しました。
Legacyは廃止/削除されました。Legacyポリシーを使用していたすべてのウェアハウスは、デフォルトの標準ポリシーを使用するようになりました。
マルチクラスターウェアハウスのスケーリングポリシーは、作成時またはその後いつでも、ウェブインターフェイスまたは SQL を使用して設定できます。
- Classic Console:
次をクリックします。
Scaling Policy フィールドで、ドロップダウンリストから目的の値を選択します。
- SQL:
SCALING_POLICY
を目的の値に設定して CREATE WAREHOUSE または ALTER WAREHOUSE コマンドを実行します。
例えば、SQLでは次のようになります。
ALTER WAREHOUSE mywh SET SCALING_POLICY = 'ECONOMY';
マルチクラスターウェアハウスのクラスターの増加または減少¶
ウェアハウスのクラスターの数は、稼働中でステートメントを実行しているときでも、随時増減できます。ウェブインターフェイスまたは SQL を使用して、ウェアハウスのクラスターを増減できます。
- Classic Console:
- SQL:
ALTER WAREHOUSE コマンドを実行します。
実行中のウェアハウスの最大および最小クラスターを変更する効果は、最大化モードまたは自動スケールモードのどちらで実行されているかによって異なります:
最大化:
- ↑ 最大および最小:
指定された数のクラスターがすぐに開始されます。
- ↓ 最大および最小:
ステートメントの実行が終了し、自動中断期間が経過すると、指定された数のクラスターがシャットダウンします。
自動スケール:
- ↑ 最大:
new_max_clusters > running_clusters
の場合、追加のクラスターが必要になるまで変更はありません。- ↓ 最大:
new_max_clusters < running_clusters
の場合、過剰なクラスターはステートメントの実行を終了してシャットダウンし、 スケーリングポリシー の条件が満たされます。- ↑ 最小:
new_min_clusters > running_clusters
の場合、追加クラスターはすぐに最小値を満たし始めました。- ↓ 最小:
new_min_clusters < running_clusters
の場合、過剰なクラスターはステートメントの実行を終了してシャットダウンし、 スケーリングポリシー の条件が満たされます。
マルチクラスターウェアハウスの監視¶
ウェブインターフェイスを介して、マルチクラスターウェアハウスの使用状況を監視できます: