Azure SQL Database でエラスティック プールのリソースをスケーリングする
適用対象: Azure SQL データベース
この記事では、Azure SQL Database でエラスティック プールとプールされたデータベースに使用できるコンピューティング リソースとストレージ リソースをスケーリングする方法について説明します。
コンピューティング リソース (仮想コアまたは DTU) の変更
仮想コアまたは eDTU の数を最初に選択した後は、以下の方法のいずれかを使って、実際の状況に基づいて、エラスティック プールを動的にスケールアップまたはスケールダウンできます。
サービス レベルの変更またはコンピューティング サイズの再スケーリングの影響
エラスティック プールのサービス レベルとコンピューティング サイズの変更は、単一データベースと同様のパターンに従い、主に次の手順を実行するサービスが含まれます。
エラスティック プール用に新しいコンピューティング インスタンスを作成する
要求されたサービス レベルとコンピューティング サイズを持つ新しいコンピューティング インスタンスがエラスティック プール用に作成されます。 サービス レベルとコンピューティング サイズの一部の組み合わせの変更では、新しいコンピューティング インスタンスに各データベースのレプリカを作成する必要があります。これにはデータをコピーすることが含まれ、全体の待機時間に大きく影響する場合があります。 いずれにしても、この手順の間、データベースはオンラインのままで、接続は元のコンピューティング インスタンスのデータベースに引き続き向けられます。
接続のルーティングを新しいコンピューティング インスタンスに切り替える
元のコンピューティング インスタンス内のデータベースへの既存の接続が切断されます。 新しいコンピューティング インスタンス内のデータベースへの新しい接続が確立されます。 サービス レベルとコンピューティング サイズの一部の組み合わせの変更では、データベース ファイルがデタッチされ、切り替え時に再アタッチされます。 いずれにしても、切り替えにより、データベースが使用できなくなる短時間の中断が発生する場合があります。中断は通常は 30 秒未満で、多くの場合はほんの数秒です。 接続が削除されたときにアクティブな実行時間の長いトランザクションがあると、中止されたトランザクションを復旧するために、この手順の所要時間が長くなる場合があります。 高速データベースの復旧により、長時間実行されているトランザクションの中断による影響を軽減できます。
重要
ワークフローのいずれの手順でもデータが失われることはありません。
サービス レベルの変更またはコンピューティング サイズの再スケーリングの待機時間
サービス レベルの変更、単一データベースまたはエラスティック プールのコンピューティング サイズのスケーリング、エラスティック プールとの間のデータベースの移動、またはエラスティック プール間でのデータベースの移動に伴う推定待ち時間は、次のようにパラメーター化されます。
エラスティック プールのスケーリング待機時間 | Basic、Standard、General Purpose エラスティック プールへ | Premium、Business Critical エラスティック プールへ | Hyperscale エラスティック プール |
---|---|---|---|
Basic、Standard、General Purpose エラスティック プールから | データベースの数に比例 | • データのコピーのために使用されるデータベース領域に比例した待機時間。 • 通常、使用される領域の GB あたり 1 分未満 |
N/A – データベースを Hyperscale エラスティック プールに個別に追加する必要があります。 単一データベース リソースのスケーリングに記録されているデータベースごとの待機時間のスケーリング。 |
Premium、Business Critical エラスティック プールから | • データのコピーのために使用されるデータベース領域に比例した待機時間。 • 通常、使用される領域の GB あたり 1 分未満 |
• データのコピーのために使用されるデータベース領域に比例した待機時間。 • 通常、使用される領域の GB あたり 1 分未満 |
N/A – データベースを Hyperscale エラスティック プールに個別に追加する必要があります。 単一データベース リソースのスケーリングに記録されているデータベースごとの待機時間のスケーリング。 |
Hyperscale エラスティック プールで | 該当なし | 該当なし | • 使用される領域とは関係ない一定時間の待機時間 • 通常は 2 分未満 |
注意
- サービス レベルを変更する場合、または Hyperscale ではないエラスティック プールのコンピューティングをスケーリングする場合は、そのプール内のすべてのデータベース全体で使用される領域の合計を、推定値の計算に使用する必要があります。 Hyperscale エラスティック プールのスケーリング待機時間は、使用される領域に依存しません。
- Standard および General Purpose エラスティック プールでは、エラスティック プールで Premium ファイル共有 (PFS) ストレージが使用されている場合、エラスティック プールとの間、またはエラスティック プール間でデータベースを移動するための待ち時間は、データベース サイズに比例します。 プールで PFS ストレージが使用されているかどうかを確認するには、プールのデータベースのコンテキストで次のクエリを実行します。 AccountType 列の値が
PremiumFileStorage
またはPremiumFileStorage-ZRS
の場合、プールで PFS ストレージが使用されています。
SELECT s.file_id,
s.type_desc,
s.name,
FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');
注意
- エラスティック プールを Business Critical から General Purpose サービス レベルにスケーリングする場合、ゾーン冗長プロパティは既定で同じままになります。
- General Purpose エラスティック プールのゾーン冗長性変更されたときのスケーリング操作の待機時間は、データベース サイズに比例します。
- Hyperscale 以外の既存のElastic Poolの Hyperscale エディションへの変更はサポートされていません。 詳しくは、「Hyperscale エラスティック プール」を参照してください。 データベースを Hyperscale エラスティック プールに個別に追加する必要があります。
- Hyperscale Elastic Poolのエディションの非 Hyperscale エディションへの変更はサポートされていません。 詳しくは、「Hyperscale エラスティック プール」を参照してください。
ヒント
実行中の操作の監視については、以下をご覧ください: 「SQL REST API を使った操作の管理」、「CLI を使った操作の管理」、「T-SQL を使った操作の管理」および、2 つの PowerShell コマンド (Get-AzSqlElasticPoolActivity、Stop-AzSqlElasticPoolActivity)
サービス レベルを変更またはコンピューティング サイズを再スケーリングする場合の追加の考慮事項
- エラスティック プールの仮想コアまたは eDTU を減らすときは、プールで使われている領域が、ターゲットのサービス レベルとプールのコンピューティングの最大データ サイズ制限より小さい必要があります。
- Elastic Pool の eDTU を増やす際、次の場合に追加のストレージ コストが適用されることがあります。
- プールの最大データ サイズがターゲット プールでサポートされている。および
- プールの最大データ サイズが、ターゲット プールの付属のストレージの量を超えている。
- たとえば、最大データ サイズが 100 GB の 100 eDTU の Standard プールを、50 eDTU の Standard プールにダウンサイズすると、ターゲット プールは 100 GB の最大データ サイズをサポートしますが、付属するストレージ量は 50 GB だけなので、追加ストレージ コストがかかります。 したがって、追加ストレージ量は 100 GB – 50 GB = 50 GB になります。 追加ストレージの価格については、「SQL Database の価格」をご覧ください。 実際に使われる領域の量が付属のストレージの量より少ない場合、最大データ サイズを付属の量に減らすことで、この追加コストを回避できます。
再スケーリング時の課金
使用状況やデータベースがアクティブであったのが 1 時間未満であったことに関係なく、データベースが存在していた 1 時間単位で、その時間に使用された最上位のサービス階層とコンピューティング サイズで課金は行われます。 たとえば、Single Database を作成し、それを 5 分後に削除した場合、請求書にはデータベース時間として 1 時間の請求が表示されます。
エラスティック プールのストレージ サイズの変更
エラスティック プールのストレージ サイズ (最大データ サイズ) は、Azure portal、PowerShell、Azure CLI、または REST API を使って指定できます。 エラスティック プールの最大データ サイズを増やす場合、指定する値がプールのサービス目標の最大データ サイズ制限を超えることはできません。 最大データ サイズを小さくする場合、指定する新しい値は、プール内のすべてのデータベースに割り当てられる領域の合計以上である必要があります。
重要
場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。
仮想コアベースの購入モデル
- General Purpose または Business Critical レベルのエラスティック プールのストレージ サイズ (最大データ サイズ) は、「仮想コア購入モデルを使用したエラスティック プールに対するリソース制限」で指定されている最大データ サイズ制限まで指定できます。 エラスティック プールの最大データ サイズは、1 GB の倍数で増減できます。
- エラスティック プールのストレージの価格は、指定された最大データ サイズに、サービス レベルのストレージ ユニット価格を掛けたものになります。 ストレージの価格について詳しくは、「SQL Database の価格」をご覧ください。
重要
場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。
DTU ベースの購入モデル
- エラスティック プールの eDTU 価格には、追加コストなしで一定量のストレージが含まれます。 付属する量を超える追加のデータ ストレージは、プロビジョニングされる eDTU に対応する最大データ サイズ制限まで、追加コストでプロビジョニングできます。 付属するストレージ量と最大データ サイズ制限については、DTU 購入モデルを使用したエラスティック プールのリソース制限に関する記事を参照してください。
- エラスティック プールの追加ストレージの料金は、追加ストレージ量にサービス レベルの追加ストレージ単価を掛けて計算します。 追加ストレージの価格について詳しくは、「SQL Database の価格」をご覧ください。
- Standard または Premium レベルのエラスティック プールの最大データ サイズに対して有効な値は、次の値のいずれかになります: 50 GB、100 GB、150 GB、200 GB、250 GB、300 GB、400 GB、500 GB、750 GB、800 GB、1024 GB、1200 GB、1280 GB、1536 GB、1600 GB、1792 GB、2000 GB、2048 GB、2304 GB、2500 GB、2560 GB、2816 GB、3000 GB、3072 GB、3328 GB、3584 GB、3840 GB、4096 GB。 指定する最大データ サイズは、プロビジョニングされる eDTU に対して指定される最大データ サイズ制限を超えることはできません。
重要
場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。
スケーリングの変更を監視または取り消す
サービス レベルの変更またはコンピューティングの再スケーリング操作を監視し、また取り消すことができます。
SQL Elastic Pool の [概要] ページで、[通知] に移動し、進行中の操作があることを示すタイルを選択します。
結果の [デプロイが進行中] ページで、[キャンセル] を選択します。
アクセス許可
Azure portal、PowerShell、Azure CLI、または REST API を使って Elastic Pool をスケーリングするには、Azure RBAC のアクセス許可 (特に共同作成者、SQL DB 投稿者ロール、または SQL Server 共同作成者 Azure RBAC の役割) が必要です。 詳細については、Azure RBAC: 組み込みのロールに関するページをご覧ください。
関連するコンテンツ
全体的なリソースの制限については、SQL Database の仮想コアペースのリソース制限 - エラスティック プールおよび SQL Database の DTU ベースのリソース制限 - エラスティック プールに関するページを参照してください。