Azure SQL Database のサーバーレス コンピューティング レベル

  • [アーティクル]

適用対象:Azure SQL Database

サーバーレスは、ワークロードの需要に基づいてコンピューティングが自動的にスケーリングされ、1 秒あたりのコンピューティング使用量に対して請求される、Azure SQL Database の単一データベース用のコンピューティング レベルです。 またサーバーレス コンピューティング レベルでは、アイドル期間にデータベースを自動的に一時停止します。このときはストレージのみに課金され、再びアクティブになると自動的にデータベースが再開されます。 サーバーレス コンピューティング レベルは、汎用サービス レベルとハイパースケール サービス レベルで利用できます。

Note

自動一時停止と自動再開は、現在、General Purpose サービス レベルでのみサポートされています。

概要

コンピューティングの自動スケール範囲と自動一時停止の遅延は、サーバーレス コンピューティング レベルの重要なパラメーターです。 これらのパラメーターの構成によって、データベース パフォーマンス エクスペリエンスとコンピューティング コストが決まります。

Diagram indicating when serverless billing would stop incurring compute charges due to inactivity.

パフォーマンスの構成

  • 最小仮想コアと最大仮想コアは、データベースに使用可能なコンピューティング容量の範囲を定義する構成可能なパラメーターです。 メモリと IO の上限は、指定された仮想コアの範囲に比例します。 
  • 自動一時停止遅延は、自動的に一時停止するためにデータベースで必要な非アクティブ期間を定義する構成可能なパラメーターです。 次のサインインまたはその他のアクティビティが発生すると、データベースは自動的に再開されます。 または、自動一時停止を無効にすることもできます。

コスト

  • サーバーレス データベースのコストは、コンピューティング コストとストレージ コストの合計です。
  • コンピューティングの使用量が構成された最小制限と最大制限の間にある場合、コンピューティング コストは仮想コアとメモリの使用に基づきます。
  • コンピューティングの使用量が構成された最小制限を下回っている場合、コンピューティング コストは、構成された最小仮想コア数と最小メモリに基づきます。
  • データベースが一時停止すると、コンピューティング コストはゼロになり、ストレージ コストのみが発生します。
  • ストレージ コストは、プロビジョニングされたコンピューティング レベルと同じ方法で決定されます。

より詳細なコストについては、課金に関する項目を参照してください。

シナリオ

サーバーレスは、アイドル使用期間後のコンピューティング ウォームアップにおいてある程度の遅延を許容できる一時的な予測できない使用パターンの単一データベースに対して価格とパフォーマンスが最適化されています。 これに対し、プロビジョニング済みコンピューティング レベルは、コンピューティング ウォームアップの遅延を許容できない平均的に使用量が多いエラスティック プール内の単一データベースまたは複数のデータベースに対して価格とパフォーマンスが最適化されています。

サーバーレス コンピューティングに適したシナリオ

  • 間欠的で予測できない使用パターンの単一データベースで、長期にわたってアクティブではない期間と平均コンピューティング使用率が低い期間が散在している場合。
  • 頻繁に再スケールされるプロビジョニング済みコンピューティング レベル内の単一データベースと、コンピューティングの再スケールをサービスに委任することを好むお客様。
  • Azure SQL データベースへのデプロイ前にコンピューティング サイズを見積もることが困難か不可能な、使用履歴のない新しい単一データベース。

プロビジョニング済みコンピューティングに最適なシナリオ

  • より定期的で予測できる使用パターンを持ち、長期にわたって平均コンピューティング使用率が高い単一データベース。
  • 頻繁なメモリ トリミング、または一時停止状態からの再開遅延によるパフォーマンスのトレードオフを許容できないデータベース。
  • 価格とパフォーマンスの最適化向上のためにエラスティック プールに統合できる、間欠的な予測できない使用パターンを持つ複数のデータベース。

コンピューティング レベルの比較

次の表は、サーバーレス コンピューティング レベルとプロビジョニング済みコンピューティング レベル間の違いをまとめたものです。

サーバーレス コンピューティング プロビジョニング済みコンピューティング
データベースの使用パターン 長期にわたって平均コンピューティング使用率が低い、間欠的で予測できない使用状況。 長期間にわたって平均コンピューティング使用率が高い、より定期的な使用パターン、またはエラスティック プールを使用する複数のデータベース。
パフォーマンス管理作業 低 高
コンピューティングのスケーリング 自動 マニュアル
コンピューティングの応答性 非アクティブな期間の後は低い 即時
請求の最小単位 1 秒あたり 1 時間あたり

購入モデルとサービス レベル

次の表は、購入モデル、サービス レベル、ハードウェアに基づいたサーバーレス サポートについてまとめたものです。

カテゴリ サポートされています サポートされていません
購入モデル 仮想コア DTU
サービス レベル 汎用
Hyperscale		 Business Critical
ハードウェア Standard シリーズ (Gen5) その他すべてのハードウェア

自動スケール

スケーリング応答性

サーバーレス データベースは、リソースの需要を満たすために十分な容量を備え、最大仮想コア値によって設定される制限内で要求されたどのようなコンピューティング量に対しても中断することのないコンピューター上で実行されます。 場合によっては、コンピューターが数分以内にリソースの需要を満たすことができない場合、自動的に負荷分散が行われることがあります。 たとえば、リソースの需要が 4 個の仮想コアであるが、利用できる仮想コアが2 個のみの場合は、4 個の仮想コアが提供される前の負荷分散に数分かかる可能性があります。 データベースは、接続が切断されるときの操作の最後の短時間を除き、負荷分散の間オンライン状態を維持します。

メモリ管理

General Purpose と Hyperscale の両方のサービス レベルで、サーバーレス データベースのメモリは、プロビジョニング済みコンピューティング データベースの場合よりも頻繁に再利用されます。 この動作は、サーバーレスでのコストを管理するために重要で、パフォーマンスに影響を及ぼすことがあります。

キャッシュの再利用

プロビジョニング済みコンピューティング データベースとは異なり、CPU またはアクティブなキャッシュの使用率が低いとき、SQL キャッシュからのメモリはサーバーレス データベースから回収されます。

  • 最近使用したキャッシュ エントリの合計サイズが一定期間しきい値を下回ると、アクティブなキャッシュの使用率が低いと見なされます。
  • キャッシュの回収がトリガーされると、ターゲットのキャッシュ サイズは段階的に減少して前のサイズよりも少なくなります。回収は、使用率が低い状態が続く場合にのみ続行されます。
  • キャッシュの回収が発生している場合、削除するキャッシュ エントリの選択ポリシーは、メモリ負荷が高いときのプロビジョニングされたコンピューティング データベースの選択ポリシーと同じです。
  • キャッシュ サイズは、最小仮想コアで定義されている最小メモリ制限よりも小さくなることはありません。

サーバーレス コンピューティング データベースとプロビジョニング済みコンピューティング データベースの両方で、使用可能なメモリがすべて使用されている場合、キャッシュ エントリを削除できます。

CPU 使用率が低い場合、使用パターンによってはアクティブなキャッシュの使用率が高いままになり、メモリの再利用が妨げられる可能性があります。 また、以前のユーザー アクティビティに定期的なバックグラウンド プロセスが応答するために、ユーザー アクティビティが停止した後、メモリが再利用される前に、その他の遅延時間が発生する可能性があります。 たとえば、削除操作とクエリ ストアのクリーンアップ タスクによって、削除対象としてマークされるゴースト レコードが生成されますが、それらはゴースト クリーンアップ プロセスが実行されるまで、物理的には削除されません。 ゴースト クリーンアップでは、キャッシュへのデータ ページの読み取りが行われる場合があります。

キャッシュのハイドレーション

データがディスクからフェッチされると、SQL メモリ キャッシュは、プロビジョニング済みデータベースと同じ方法および速度で拡大します。 データベースがビジー状態の場合、キャッシュは、使用可能なメモリがある間は制約なしで拡大できます。

ディスク キャッシュ管理

サーバーレス コンピューティング レベルとプロビジョニング済みコンピューティング レベルの両方の Hyperscale サービス レベルで、各コンピューティング レプリカは弾性バッファー プール拡張機能 (RBPEX) キャッシュを使用します。これにより、データ ページがローカル SSD に格納され、IO パフォーマンスが向上します。 ただし、Hyperscale のサーバーレス コンピューティング レベルでは、ワークロードの需要の増減に応じて、各コンピューティング レプリカの RBPEX キャッシュが自動的に拡大縮小します。 RBPEX キャッシュが拡大できる最大サイズは、データベース用に構成された最大メモリの 3 倍です。 サーバーレスでの最大メモリと RBPEX 自動スケーリングの制限の詳細については、サーバーレス Hyperscale リソースの制限に関するセクションを参照してください。

自動一時停止と自動再開

現在、サーバーレスの自動一時停止と自動再開は、General Purpose レベルでのみサポートされています。

自動一時停止

自動一時停止遅延の期間を通して次のすべての条件が満たされた場合、自動一時停止がトリガーされます。

  • セッション数 = 0
  • CPU = 0 (ユーザー リソース　プールで実行されているユーザー ワークロードの場合)

必要な場合に自動一時停止を無効にするオプションが用意されています。

次の機能では自動一時停止はサポートされていませんが、自動スケーリングはサポートされています。 次の機能のいずれかが使用されている場合、自動一時停止を無効にする必要があります。データベースは、データベースの非アクティブ期間に関係なくオンラインのままとなります。

データベースをオンラインにする必要がある一部のサービス更新プログラムのデプロイ中は、自動一時停止は一時的に回避されます。 このような場合、サービス更新プログラムが完了すると、自動一時停止は再び許可されます。

自動一時停止のトラブルシューティング

自動一時停止が有効であり、自動一時停止をブロックする機能が使用されていないにもかかわらず、遅延期間が経過してもデータベースが自動一時停止しない場合は、アプリケーションまたはユーザー セッションが自動一時停止を妨げている可能性があります。

データベースに現在接続されているアプリケーションまたはユーザー セッションがあるかどうかを確認するには、任意のクライアント ツールを使用してデータベースに接続し、次のクエリを実行します。

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
          (
          wg.name like 'UserPrimaryGroup.DB%'
          AND
          TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
          )
      OR
      wg.name = 'DACGroup'
      );

ヒント

クエリを実行した後、必ずデータベースから切断してください。 そうしないと、クエリで使用されているオープン セッションによって自動一時停止が妨げられます。

  • 結果セットが空でない場合は、自動一時停止を現在妨げているセッションがあることを示しています。
  • 結果セットが空の場合でも、自動一時停止遅延期間中の早い時点で、セッションが短時間開かれていた可能性はあります。 遅延期間中にアクティビティが発生したかどうかを確認するには、Azure SQL 監査を使用して、関連する期間の監査データを確認できます。

重要

開いているセッションの存在は、ユーザーのリソース プール内で CPU の同時使用があるかどうかに関係なく、サーバーレス データベースが予期したとおりに自動一時停止しない場合の最も一般的な理由です。

自動再開

次の条件のいずれかに該当した場合は常に、自動再開がトリガーされます。

機能 自動再開トリガー
認証と権限承認 サインイン
脅威の検出 データベース レベルまたはサーバー レベルでの脅威検出の設定の有効化/無効化。
データベース レベルまたはサーバー レベルでの脅威検出の設定の変更。
データの検出と分類 機密ラベルの追加、変更、削除、表示
監査 監査レコードの表示。
監査ポリシーの更新または表示。
データ マスク データ マスク ルールの追加、変更、削除、表示
透過的なデータ暗号化 透過的データ暗号化の状態またはステータスの表示
脆弱性評価 アドホック スキャンと定期的なスキャン (有効な場合)
クエリ (パフォーマンス) データ ストア クエリ ストアの設定の変更または表示
パフォーマンスに関する推奨事項 パフォーマンスに関する推奨事項の表示または適用
自動チューニング 自動インデックス作成などの自動チューニングの推奨事項の適用と検証
データベースのコピー コピーとしてのデータベースの作成。
BACPAC ファイルへのエクスポート。
SQL データ同期 構成可能なスケジュールまたは手動で実行される、ハブとメンバー データベースの間の同期
特定のデータベース メタデータの変更 新しいデータベース タグの追加。
最大仮想コア数、最小仮想コア数、または自動一時停止遅延の変更。
SQL Server Management Studio (SSMS) 18.1 以前の SSMS バージョンを使用し、サーバー内のデータベースに対して新しいクエリ ウィンドウを開くと、同じサーバー内の自動一時停止されたデータベースが再開されます。 この動作は、18.1 以降の SSMS バージョンを使用している場合は発生しません。
  • 監視、管理、または上記のいずれかの操作を実行するその他のソリューションでは、自動再開がトリガーされます。
  • データベースをオンラインにする必要がある一部のサービス更新プログラムのデプロイ中にも、自動再開がトリガーされます。

接続

サーバーレス データベースが一時停止されている場合、最初のサインイン アクティビティによってデータベースが再開され、データベースが利用できないことを示すエラー コード 40613 が返されます。 データベースが再開され後、サインインを再試行して接続を確立する必要があります。 推奨される接続再試行ロジックを備えたデータベース クライアントを変更する必要はありません。 接続の再試行ロジックの推奨パターンについては、以下を確認してください。

Latency

サーバーレス データベースの自動再開および自動一時停止の待機時間は、通常、自動再開までには約 1 分、自動停止までには、遅延期間の期限が切れてから 1 分から 10 分かかります。

お客様が管理する透過的なデータ暗号化 (BYOK)

キーの削除または失効

お客様が管理する透過的なデータ暗号化 (BYOK) を使用していて、キーの削除または失効が発生したときにサーバーレス データベースが自動一時停止されている場合、データベースは自動一時停止状態のままになります。 この場合、データベースが次に再開された後、約 10 分以内にデータベースにアクセスできなくなります。 データベースがアクセス不可になった後、復旧プロセスは、プロビジョニングされたコンピューティング データベースの場合と同じです。 キーの削除または失効が発生したときにサーバーレス データベースがオンラインになっている場合も、プロビジョニングされたコンピューティング データベースと同じように約 10 分以内にデータベースにアクセスできなくなります。

キーの交換

カスタマー マネージド Transparent Data Encryption (BYOK) を使っていて、サーバーレス データベースが自動一時停止される場合、自動キー ローテーションは、データベースが自動再開されるまで延期されます。

新しいサーバーレス データベースを作成する

サーバーレス コンピューティング レベルでの新しいデータベースの作成または既存のデータベースの移動は、プロビジョニング済みコンピューティング レベルでの新規データベースの作成と同じパターンに従い、次の 2 つのステップが含まれます。

  1. サービス目標を指定します。 サービス目標では、サービス レベル、ハードウェア構成、および最大仮想コア数が規定されます。 サービス目標オプションについては、サーバーレス リソースの制限に関するページを参照してください。

  2. 必要に応じて、最小仮想コア数と自動一時停止遅延を指定して、既定値を変更します。 これらのパラメーターに対して使用可能な値を次の表に示します。

    パラメーター 値の選択肢 規定値
    最小仮想コア数 構成された最大仮想コアによって異なります。リソースの制限に関するページを参照してください。 0.5 仮想コア
    自動一時停止の遅延 最小:60 分 (1 時間)
    最大値:10,080 分 (7 日)
    増分: 10 分
    自動一時停止の無効化: -1    		 約 60 分

次の例では、サーバーレス コンピューティング レベルで新しいデータベースを作成します。

Azure Portal の使用

「クイック スタート:Azure portal を使用して Azure SQL Database で単一データベースを作成する」をご覧ください。

PowerShell の使用

次の PowerShell の例を使用して、新しいサーバーレス General Purpose データベースを作成します。

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720

Azure CLI の使用

次の Azure CLI の例を使用して、新しいサーバーレス General Purpose データベースを作成します。

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e GeneralPurpose --compute-model Serverless -f Gen5 `
  --min-capacity 0.5 -c 2 --auto-pause-delay 720

Transact-SQL (T-SQL) の使用

T-SQL を使用して新しいサーバーレス データベースを作成した場合、仮想コアの最小値と自動一時停止の遅延に対して既定値が適用されます。 これらは、後で Azure ポータルから、または他の管理 API (PowerShell、Azure CLI、REST API) を使用して変更できます。

詳細については、「CREATE DATABASE」を参照してください。

次の T-SQL の例を使用して、新しい General Purpose サーバーレス データベースを作成します。

CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;

コンピューティング レベル間でデータベースを移行する

プロビジョニング済みコンピューティング レベルからサーバーレス コンピューティング レベルにデータベースを移行し、もう一度戻すことができます。

注意

General Purpose レベルのデータベースを Hyperscale レベルにアップグレードすることもできます。 詳細については、「Hyperscale データベースの管理」を参照してください。

コンピューティング レベル間でデータベースを移行するとき、PowerShell と Azure CLI を使用する場合は、コンピューティング モデル パラメーターを Serverless または Provisioned として指定し、T-SQL を使用する場合は SERVICE_OBJECTIVE のコンピューティング サイズを指定します。 リソース制限を確認して適切なコンピューティング サイズを特定します。

このセクションの例では、プロビジョニング済みデータベースをサーバーレスに移行する方法を示します。 これらの例では最大仮想コア数を 4 に設定していますが、必要に応じてサービスの目標を変更してください。

PowerShell の使用

次の PowerShell の例を使用して、プロビジョニング済みコンピューティングの General Purpose データベースをサーバーレス コンピューティング レベルに移行します。

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440

Azure CLI の使用

次の Azure CLI の例を使用して、プロビジョニング済みコンピューティングの General Purpose データベースをサーバーレス コンピューティング レベルに移行します。

az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
  --edition GeneralPurpose --compute-model Serverless --family Gen5 `
  --min-capacity 1 --capacity 4 --auto-pause-delay 1440

Transact-SQL (T-SQL) の使用

T-SQL を使用してコンピューティング レベル間でデータベースを移動する場合、最小仮想コアと自動一時停止の遅延に既定値が適用されます。 これらは、後で Azure ポータルから、または他の管理 API (PowerShell、Azure CLI、REST API) を使用して変更できます。 詳細については、[ALTER DATABASE](/sql/t-sql/statements/alter-database-transact-sql-file-and-filegroup-options) に関する記事をご覧ください。

次の T-SQL の例を使用して、プロビジョニング済みコンピューティングの General Purpose データベースをサーバーレス コンピューティング レベルに移行します。

ALTER DATABASE testdb 
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;

サーバーレス構成を変更する

PowerShell の使用

最大または最小仮想コア数、および自動一時停止の延期期間を変更するには、Set-AzSqlDatabase を使用します。 MaxVcore、MinVcore、AutoPauseDelayInMinutes の各引数を使用します。 現在、サーバーレスでの自動一時停止は Hyperscale レベルではサポートされていないため、自動一時停止の延期期間の引数は General Purpose レベルにのみ適用されます。

Azure CLI の使用

最大または最小仮想コア数、および自動一時停止の延期期間を変更するには、az sql db update を使用します。 capacity、min-capacity、auto-pause-delay の各引数を使用します。 現在、サーバーレスでの自動一時停止は Hyperscale レベルではサポートされていないため、自動一時停止の延期期間の引数は General Purpose レベルにのみ適用されます。

モニター

使用済みおよび請求対象のリソース

サーバーレス データベースのリソースには、アプリ パッケージ、SQL インスタンス、ユーザー リソース プール エンティティが含まれます。

アプリ パッケージ

アプリ パッケージは、データベースがサーバーレスまたはプロビジョニング済みのどちらのコンピューティング レベルであるかに関係なく、データベースに対する最も外側のリソース管理境界です。 アプリ パッケージには SQL インスタンスと、フルテキスト検索などの外部サービスが含まれており、そのすべてによって SQL Database のデータベースによって使用されるすべてのユーザーおよびシステム リソースのスコープが決まります。 一般に、アプリ パッケージでの全体的なリソース使用量より、SQL インスタンスの方が優位です。

ユーザー リソース プール

ユーザー リソース プールは、データベースがサーバーレスまたはプロビジョニング済みのどちらのコンピューティング レベルであるかに関係なく、データベースに対する内側のリソース管理境界です。 ユーザー リソース プールは、DDL (CREATE および ALTER) および DML (INSERT、UPDATE、DELETE、MERGE、および SELECT) クエリによって生成されるユーザー ワークロードの CPU と IO をスコープします。 これらのクエリは、一般に、アプリ パッケージでの使用量の最も大きな割合を表します。

メトリック

次の表には、アプリ パッケージのリソース使用量とサーバーレス データベース (geo レプリカを含む) のユーザー リソース プールを監視するためのメトリックが含まれています。

エンティティ メトリック 説明 Units
アプリ パッケージ app_cpu_percent アプリに許可されている最大仮想コア数に対する、アプリによって使用された仮想コア数の割合。 サーバーレス Hyperscale の場合、すべてのプライマリ レプリカ、名前付きレプリカ、geo レプリカに対して、このメトリックが公開されています。 パーセント
アプリ パッケージ app_cpu_billed レポート期間中にアプリに対して請求されるコンピューティングの量。 この期間中に支払われる金額は、このメトリックと仮想コアの単位価格の積です。

このメトリックの値は、1 秒ごとに使用された CPU とメモリの最大値を時間で集計することによって決定されます。 使用された金額が、最小仮想コア数と最小メモリによって設定されるプロビジョニング済みの最低額より少ない場合、プロビジョニング済みの最低額が請求されます。 請求のために CPU とメモリを比較するため、メモリは GB 単位のメモリ量を仮想コアあたり 3 GB で再スケーリングすることによって、仮想コアの単位に正規化されます。 サーバーレス Hyperscale の場合、プライマリ レプリカと名前付きレプリカに対して、このメトリックが公開されています。		 仮想コア秒数
アプリ パッケージ app_cpu_billed_HA_replicas サーバーレス Hyperscale にのみ適用されます。 レポート期間中に HA レプリカのすべてのアプリに対して請求されるコンピューティングの合計。 この合計のスコープは、プライマリ レプリカに属する HA レプリカ、または特定の名前付きレプリカに属する HA レプリカのいずれかです。 HA レプリカ全体でこの合計を計算する前に、個々の HA レプリカに対して請求されるコンピューティングの量は、プライマリ レプリカまたは名前付きレプリカの場合と同じ方法で決定されます。 サーバーレス Hyperscale の場合、すべてのプライマリ レプリカ、名前付きレプリカ、geo レプリカに対して、このメトリックが公開されています。 レポート期間中に支払われる金額は、このメトリックと仮想コアの単位価格の積です。 仮想コア秒数
アプリ パッケージ app_memory_percent アプリに許可されている最大メモリに対する、アプリによって使用されたメモリの割合。 サーバーレス Hyperscale の場合、すべてのプライマリ レプリカ、名前付きレプリカ、geo レプリカに対して、このメトリックが公開されています。 パーセント
ユーザー リソース プール cpu_percent ユーザー ワークロードに許可されている最大仮想コア数に対する、ユーザー ワークロードによって使用された仮想コア数の割合。 Percentage
ユーザー リソース プール data_IO_percent ユーザー ワークロードに許可されている最大データ IOPS に対する、ユーザー ワークロードによって使用されたデータ IOPS の割合。 Percentage
ユーザー リソース プール log_IO_percent ユーザー ワークロードに許可されている最大ログ MB/秒に対する、ユーザー ワークロードによって使用されたログ MB/秒の割合。 Percentage
ユーザー リソース プール workers_percent ユーザー ワークロードに許可されている最大ワーカー数に対する、ユーザー ワークロードによって使用されたワーカー数の割合。 Percentage
ユーザー リソース プール sessions_percent ユーザー ワークロードに許可されている最大セッション数に対する、ユーザー ワークロードによって使用されたセッション数の割合。 Percentage

一時停止と再開の状態

Azure portal では、データベースの状態は、サーバーに含まれるデータベースの一覧が表示される概要ウィンドウで示されます。 データベースの状態は、データベースの概要ウィンドウにも表示されます。

データベースの一時停止と再開の状態を照会するには、次のコマンドを使用します。

PowerShell の使用

Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

Azure CLI の使用

az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json

リソース制限

リソースの制限については、サーバーレス コンピューティング レベルをご覧ください。

課金

サーバーレス データベースのコンピューティングの請求金額は、各秒に使用された CPU およびメモリの最大量です。 CPU とメモリの使用量が各リソースのプロビジョニング済みの最小量より少ない場合、プロビジョニング済みの量が請求されます。 請求の目的で CPU とメモリを比較するために、メモリは GB の数値を仮想コアあたり 3 GB で再スケーリングすることによって、仮想コアの単位に正規化されます。

  • 請求されるリソース: CPU とメモリ
  • 請求される金額: 仮想コア単位価格 * (最小仮想コア数、使用された仮想コア数、最小メモリ GB * 1/3、使用されたメモリ GB * 1/3) のうち最大の値
  • 請求頻度: 1 秒あたり

仮想コア単位価格は、1 秒あたり、仮想コアあたりのコストです。 Hyperscale の場合、HA レプリカまたは名前付きレプリカの仮想コア単価は、プライマリ レプリカの場合よりも低くなります。

特定のリージョンの特定の単位価格については、Azure SQL Database の価格に関するページをご覧ください。

サーバーレスの General Purpose データベースあるいは Hyperscale プライマリまたは名前付きレプリカに対して請求されるコンピューティングの量は、次のメトリックによって公開されています。

  • メトリック: app_cpu_billed (仮想コア秒数)
  • 定義: (最小仮想コア数、使用された仮想コア数、最小メモリ GB * 1/3、使用されたメモリ GB * 1/3) のうち最大の値
  • レポート頻度: 1 分単位であり、1 分間に集計された 1 秒あたりの測定値に基づきます。

プライマリ レプリカまたは任意の名前付きレプリカに属する Hyperscale HA レプリカに対して請求されるサーバーレスでのコンピューティングの量は、次のメトリックによって公開されています。

  • メトリック: app_cpu_billed_HA_replicas (仮想コア秒数)
  • 定義: 親リソースに属する HA レプリカの (最小仮想コア数、使用された仮想コア数、最小メモリ GB * 1/3、使用されたメモリ GB * 1/3) のうち最大の値の合計。
  • 親リソースとメトリック エンドポイント: プライマリ レプリカと名前付きレプリカはそれぞれ別々に、関連付けられている HA レプリカに対して請求されるコンピューティングを測定するこのメトリックを公開しています。
  • レポート頻度: 1 分単位であり、1 分間に集計された 1 秒あたりの測定値に基づきます。

最小コンピューティング料金

サーバーレス データベースが一時停止された場合、コンピューティング料金は 0 になります。 サーバーレス データベースが一時停止されていない場合、最小コンピューティング料金は、最大に基づく仮想コア以上になります (最少仮想コア、最少メモリ GB * 1/3)。

例 :

  • General Purpose レベルのサーバーレス データベースが一時停止しておらず、3.0 GB の最小メモリに対応して最大仮想コア数に 8、最少仮想コア数に 1 が構成されているとします。 この場合、最小コンピューティング料金は、最大 (1 仮想コア、3.0 GB * 1 仮想コア/3 GB) = 1 仮想コアに基づきます。
  • General Purpose レベルのサーバーレス データベースが一時停止しておらず、2.1 GB の最小メモリに対応して最大仮想コア数に 4、最少仮想コア数に 0.5 が構成されているとします。 この場合、最小コンピューティング料金は、最大 (0.5 仮想コア、2.1 GB * 1 仮想コア/3 GB) = 0.7 仮想コアに基づきます。
  • Hyperscale レベルのサーバーレス データベースに、1 つの HA レプリカを持つプライマリ レプリカと、HA レプリカを持たない 1 つの名前付きレプリカがあるとします。 それぞれのレプリカに、3 GB の最小メモリに対応して最大仮想コア数に 8、最少仮想コア数に 1 が構成されているとします。 この場合、プライマリ レプリカ、HA レプリカ、名前付きレプリカの最小コンピューティング料金はそれぞれ、(仮想コア数 1、3 GB * 仮想コア数 1 /3 GB) = 仮想コア数 1 に基づいています。

サーバーレス用の Azure SQL Database 料金計算ツールを使用すると、構成された最大および最小の仮想コア数に基づいて構成可能な最小メモリを決定できます。 ルールとして、構成された最小仮想コア数が 0.5 仮想コアを超える場合、最小コンピューティング料金は構成されている最小メモリには依存せず、構成された最小仮想コア数のみに基づいて計算されます。

シナリオの例

最小仮想コア数に 1、最大仮想コア数に 4 が構成されている General Purpose レベルのサーバーレス データベースについて考えてみます。 この構成は、最小メモリは約 3 GB、最大メモリは約 12 GB に相当します。 自動一時停止遅延が 6 時間に設定され、24 時間のうち最初の 2 時間だけデータベースのワークロードがアクティブで、それ以外の時間は非アクティブだとすると、

このデータベースは、最初の 8 時間はコンピューティングとストレージに対して課金されます。 2 時間を過ぎるとデータベースは非アクティブになりますがオンラインなので、その後の 6 時間については、プロビジョニングされた最小コンピューティングに基づいて、コンピューティングに対して引き続き課金されます。 24 時間のうち、データベースが一時停止中の残りの時間については、ストレージのみが課金されます。

正確には、この例のコンピューティングに対する課金は次のように計算されます。

期間 使用された 1 秒あたりの仮想コア数 使用された 1 秒あたりの GB 数 課金対象となるコンピューティング ディメンション 対象期間内で課金対象となる仮想コア秒数
0:00-1:00 4 9 使用された仮想コア数 4 個の仮想コア * 3,600 秒 = 14,400 仮想コア秒
1:00-2:00 1 12 使用されたメモリ 12 GB * 1/3 * 3,600 秒 = 14,400 仮想コア秒
2:00-8:00 0 0 プロビジョニング済み最小メモリ 3 GB * 1/3 * 21,600 秒 = 21,600 仮想コア秒
8:00-24:00 0 0 一時停止中、コンピューティングには課金なし 0 仮想コア秒
24 時間で課金対象となる合計仮想コア秒数 50,400 仮想コア秒

コンピューティングの単位価格は $0.000145/仮想コア/秒とします。 この場合、この 24 時間で課金対象となるコンピューティングは、コンピューティング ユニット価格と課金対象の仮想コア秒数の積になります: $0.000145/仮想コア/秒 * 50,400 仮想コア秒 = 約 $7.31。

Azure ハイブリッド特典と予約容量

Azure ハイブリッド特典 (AHB) と予約容量の割引は、サーバーレス コンピューティング レベルには適用されません。

対応リージョン

最大 40 個の仮想コアのサポートを含む General Purpose レベルおよび Hyperscale レベル向けサーバーレス コンピューティング レベルは、

  • 中国東部
  • 中国北部
  • ドイツ中部
  • ドイツ北東部
  • US Gov アイオワ 米国中部を除く全世界で利用できます。

General Purpose と Hyperscale の可用性ゾーンを備えていない、最大 80 個の仮想コアをサポートするリージョン

現在、General Purpose レベルと Hyperscale レベルのサーバーレスで最大 80 個の仮想コアが、次のリージョンでサポートされています。

  • オーストラリア東部
  • オーストラリア南東部
  • ブラジル南部
  • カナダ中部
  • 米国中部
  • 東アジア
  • 米国東部
  • 米国東部 2
  • フランス中部
  • フランス南部
  • ドイツ中西部
  • インド中部
  • インド南部
  • 東日本
  • 日本西部
  • 米国中北部
  • 北ヨーロッパ
  • ノルウェー東部
  • カタール中部
  • 南アフリカ北部
  • 米国中南部
  • スイス北部
  • 英国南部
  • 英国西部
  • 西ヨーロッパ
  • 米国中西部
  • 米国西部
  • 米国西部 2
  • 米国西部 3

General Purpose の可用性ゾーンを備えた最大 80 個の仮想コアをサポートするリージョン

現在、General Purpose レベルのサーバーレスでの可用性ゾーンのサポートを備えた最大 80 個の仮想コアが以下の地域で提供されており、それ以外の多くのリージョンについても計画中です。

  • 米国東部
  • 北ヨーロッパ
  • 西ヨーロッパ
  • 米国西部 2

Hyperscale の可用性ゾーンを備えた最大 80 個の仮想コアをサポートするリージョン

現在、Hyperscale レベルのサーバーレスでの可用性ゾーンのサポートを備えた最大 80 個の仮想コアが提供されており、それ以外の多くのリージョンについても計画中です。

  • 米国中部
  • 米国東部
  • 北ヨーロッパ
  • 西ヨーロッパ
  • 米国西部 2
  • 米国西部 3

関連するコンテンツ