専用 SQL プール用のコンピューティング リソースを管理する
この記事では、Azure Synapse Analytics で専用 SQL プール (旧称 SQL DW) 用のコンピューティング リソースを管理する方法について説明します。 専用 SQL プールを一時停止してコストを抑えたり、パフォーマンスの需要に応じて専用 SQL プールをスケーリングしたりできます。
コンピューティングの管理とは
専用 SQL プールのアーキテクチャではストレージとコンピューティングを分離して、それぞれを個別にスケーリングできます。 その結果、データ ストレージとは無関係に、パフォーマンス需要に応じてコンピューティングをスケーリングできます。 コンピューティング リソースは、一時停止して再開することもできます。
このアーキテクチャの自然な結果として、コンピューティングとストレージの価格は個別になっています。 専用 SQL プールをしばらく使用する必要がない場合は、コンピューティングを一時停止して、コンピューティング コストを節約できます。
コンピューティングのスケーリング
専用 SQL プールの Data Warehouse ユニット (DWU) 数の設定を調整して、コンピューティングをスケールアウトまたはスケールバックできます。 DWU を追加するほど、読み込みとクエリのパフォーマンスは直線的に高くなり。
スケールアウトの手順については、Azure portal、PowerShell、または T-SQL に関するクイックスタートを参照してください。 REST API を使って、スケールアウト操作を実行することもできます。
スケーリング操作を実行するため、専用 SQL プールは最初にすべての着信クエリを中止した後、トランザクションをロールバックして一貫性のある状態にします。 スケーリングは、トランザクションのロールバックが完了して初めて実行されます。 スケーリング操作では、システムはストレージ レイヤーをコンピューティング ノードからデタッチし、コンピューティング ノードを追加した後、ストレージ レイヤーをコンピューティング レイヤーに再アタッチします。
各専用 SQL プールは、60 個のディストリビューションとして格納され、それがコンピューティング ノードに均等に分配されます。 コンピューティング ノードを追加していくと、コンピューティング能力も向上していきます。 コンピューティング ノードの数が増加すると、それにつれてコンピューティング ノードあたりのディストリビューションの数が減少し、クエリ用のコンピューティング能力がより多く得られます。 同様に、DWU を減らすと、コンピューティング ノードの数が減少し、クエリ用のコンピューティング リソースが減ります。
次の表は、DWU が変わると、コンピューティング ノードあたりのディストリビューションの数がどのように変わるかを示したものです。 DW30000c は、60 個のコンピューティング ノードを提供し、DW100c よりはるかに高いクエリ パフォーマンスを実現します。
| データ ウェアハウス ユニット | コンピューティング ノードの数 | ノードあたりのディストリビューションの数 |
|---|---|---|
| DW100c | 1 | 60 |
| DW200c | 1 | 60 |
| DW300c | 1 | 60 |
| DW400c | 1 | 60 |
| DW500c | 1 | 60 |
| DW1000c | 2 | 30 |
| DW1500c | 3 | 20 |
| DW2000c | 4 | 15 |
| DW2500c | 5 | 12 |
| DW3000c | 6 | 10 |
| DW5000c | 10 | 6 |
| DW6000c | 12 | 5 |
| DW7500c | 15 | 4 |
| DW10000c | 20 | 3 |
| DW15000c | 30 | 2 |
| DW30000c | 60 | 1 |
データ ウェアハウス ユニットの適正サイズの確認
スケールアウトのパフォーマンス上のメリット (特に、大規模なデータ ウェアハウス ユニットのスケールアウトのパフォーマンス上の メリット) を確認するには、少なくとも 1 TB のデータ セットを使用する必要があります。 専用 SQL プールの最適な DWU 数を見つけるには、スケールアップとスケールダウンを試します。 データを読み込んだ後、異なる DWU 数で何回かクエリを実行します。 スケーリングは簡単に行えるので、1 時間以内でさまざまなパフォーマンス レベルを試すことができます。
最適な DWU 数を発見する際の推奨事項:
- 専用 SQL プールを開発するときは、少ない数の DWU で始めます。 手始めとしては、DW400c または DW200c が適しています。
- アプリケーションのパフォーマンスを監視し、選択した DWU の数に対するパフォーマンスの変化を観察します。
- 直線的なスケーリングを想定して、DWU をどれだけ増減する必要があるかを決めます。
- ビジネス要件に応じた最適なパフォーマンス レベルに到達するまで調整を行います。
スケールアウトを実行するタイミング
DWU をスケールアウトすると、次のパフォーマンスに影響があります。
- スキャン、集計、CTAS ステートメントに関するシステムのパフォーマンスが直線的に向上します
- データ読み込み用のリーダーとライターの数が増えます
- コンカレント クエリとコンカレンシー スロットの最大数
DWU をスケールアウトすべきときに関する推奨事項:
- 大量データの読み込みまたは変換操作を実行する前に、データが短時間で使用可能になるようにスケールアウトします。
- 営業時間のピーク時は、より多くの同時実行クエリに対応できるようにスケールアウトします。
スケールアウトしてもパフォーマンスが向上しない場合の対処
DWU を追加すると、並列処理が増えます。 作業がコンピューティング ノード間に均等に分割されている場合、並列処理が増えるとクエリのパフォーマンスが向上します。 スケールアウトしてもパフォーマンスが変わらない場合、それを引き起こす可能性のある理由がいくつかあります。 ディストリビューション全体でデータが傾斜しているか、クエリによって大量のデータ移動が発生している可能性があります。 クエリのパフォーマンスの問題を調査するには、パフォーマンスのトラブルシューティングに関する記事を参照してください。
コンピューティングの一時停止と再開
コンピューティングを一時停止すると、ストレージ レイヤーがコンピューティング ノードからデタッチされます。 コンピューティング リソースがアカウントから解放されます。 コンピューティングの一時停止中は、コンピューティングに対して課金されません。 コンピューティングを再開すると、ストレージがコンピューティング ノードに再アタッチされ、コンピューティングの課金が再開されます。
専用 SQL プールを一時停止すると、次のようになります。
- コンピューティングとメモリ リソースは、データ センターで使用可能なリソースのプールに返されます。
- 一時停止の期間中、Data Warehouse ユニットのコストは 0 になります。
- データ ストレージは影響を受けず、データはそのまま残ります。
- 実行中またはキュー内の操作はすべて取り消されます。
- DMV カウンターがリセットされます。
専用 SQL プールを再開すると、次のようになります。
- 専用 SQL プールは、DWU の設定用のコンピューティングとメモリ リソースを取得します。
- DWU の再開に対する料金を計算します。
- データが使用可能になります。
- 専用 SQL プールがオンラインになった後、ユーザーはワークロード クエリを再開する必要があります。
専用 SQL プールを常にアクセス可能にしておきたい場合は、一時停止ではなく、最小サイズへのスケールダウンを検討します。
一時停止と再開の手順については、Azure portal または PowerShell のクイックスタートに関する記事を参照してください。 一時停止 REST API または 再開 REST API を使用することもできます。
一時停止またはスケールの前にトランザクションを排出する
一時停止操作またはスケール操作を開始する前に、既存のトランザクションを完了することをお勧めします。
専用 SQL プールを一時停止またはスケーリングすると、一時停止またはスケーリングの要求を開始した時点で、クエリがバックグラウンドで取り消されます。 単純な SELECT クエリの取り消しは、すばやい操作なので、インスタンスの一時停止またはスケールにかかる時間にほとんど影響しません。 ただし、データやデータ構造を変更するトランザクション クエリは、すぐに停止できない場合があります。 トランザクション クエリについては、当然、すべてが完了するか、変更をロールバックする必要があります。
トランザクション クエリが完了した作業をロールバックするには、クエリが元の変更の適用にかかった時間と同じか、それよりも長くかかる場合があります。 たとえば、行の削除を既に 1 時間実行しているクエリを取り消した場合、削除された行を挿入し直すのに 1 時間かかる可能性があります。 トランザクションが行われているときに一時停止またはスケーリングを実行した場合、一時停止またはスケーリングは、ロールバックの完了を待ってから処理を続ける必要があるため、時間がかかるように感じることがあります。
詳しくは、トランザクションの使用とトランザクションの最適化に関する記事をご覧ください。
コンピューティングの管理を自動化する
コンピューティングの管理操作の自動化については、Azure Functions を使用した専用 SQL プールのコンピューティング リソースの管理に関する記事をご覧ください。
スケール アウト、一時停止、再開の各操作は、完了するのに数分かかる場合があります。 スケーリング、一時停止、または再開を自動的に行っている場合は、特定の操作が完了したのを確認してから別のアクションに進むロジックを実装することをお勧めします。 さまざまなエンドポイントを通じて専用 SQL プールの状態を調べると、このような操作の自動化を正しく実装できます。
専用 SQL プールの状態の確認については、PowerShell または T-SQL のクイックスタートを参照してください。 REST API で専用 SQL プールの状態を確認することもできます。
アクセス許可
専用 SQL プールのスケーリングには、「ALTER DATABASE」で説明されているアクセス許可が必要です。 一時停止と再開には、SQL DB 共同作成者ロール (具体的には Microsoft.Sql/servers/databases/action) が必要です。