仮想コア購入モデルの概要 - Azure SQL Database および Azure SQL Managed Instance

  • [アーティクル]

適用対象: Azure SQL Database Azure SQL Managed Instance

この記事では、Azure SQL Database と Azure SQL Managed Instanceの両方で使用される仮想コア購入モデルの概要を説明します。 各製品の仮想コア モデルの詳細については、Azure SQL Database と Azure SQL Managed Instance を確認してください。

概要

仮想コア (vCore) は論理 CPU を表し、ハードウェアの物理特性 (コア数、メモリ、ストレージ サイズなど) を選択できるオプションを提供します。 仮想コア ベースの購入モデルでは、個々のリソース使用量において柔軟性、管理性、透明性が実現されており、オンプレミスのワークロード要件をクラウドに容易に移行する方法を提供しています。 このモデルでは、価格を最適化し、ワークロードの必要性に基づいて、コンピューティング、メモリ、ストレージのリソースを選択できます。

仮想コアベースの購入モデルでは、次のものの選択と使用量によってコストが異なります。

  • サービス レベル
  • ハードウェア構成
  • コンピューティング リソース (仮想コアの数とメモリの量)
  • 予約済みのデータベース ストレージ
  • 実際のバックアップ ストレージ

重要

Azure SQL Database では、コンピューティング リソース (CPU およびメモリ)、I/O、データとログのストレージは、データベースまたはエラスティック プールごとに課金されます。 バックアップ ストレージはデータベースごとに課金されます。

仮想コア購入モデルでは、データベースの CPU、メモリ、ストレージ リソースの割り当て、ハードウェア構成、スケーリングの粒度の向上、およびAzure ハイブリッド特典 (AHB) と予約インスタンス (RI) による価格割引の透明性が提供されます。

Azure SQL Database の場合、仮想コア購入モデルは、DTU モデルよりも高いコンピューティング、メモリ、I/O、ストレージの制限が設けられています。

サービス階層

2 つの仮想コア サービス レベルは、Azure SQL Database と Azure SQL Managed Instance の両方で使用できます。

  • General Purpose は、一般的なパフォーマンスと可用性の要件を持つほとんどのワークロード向けに設計された、予算を抑えたレベルです。
  • Business Critical レベルは、厳しい可用性要件を持つパフォーマンスに依存するワークロード用に設計されています。

Hyperscale サービス レベルは、Azure SQL Database 内の単一データベースでも使用できます。 このサービス レベルは、ほとんどのビジネス ワークロード向けに設計されており、拡張性の高いストレージ、読み取りスケールアウト、データベースの高速復元機能を備えています。

リソース制限

リソース制限の詳細については、以下を参照してください。

コンピューティング コスト

仮想コアベース購入モデルには、Azure SQL Database Managed Instance と Azure SQL Managed Instance の両方にプロビジョニングされたコンピューティング レベルと、Azure SQL Database 用のサーバーレス コンピューティング レベルがあります。

プロビジョニングされたコンピューティング レベルでは、ワークロード アクティビティとは別に、アプリケーションに対して継続的にプロビジョニングされたコンピューティング容量の合計がコンピューティング コストに反映されます。 仮想コアとメモリの要件に基づいてビジネス ニーズに最適なリソース割り当てを選択し、ワークロードの必要に応じてリソースをスケールアップまたはスケールダウンします。

Azure SQL データベースのサーバーレス コンピューティング レベルでは、コンピューティング リソースはワークロード容量に基づいて自動スケーリングされ、1 秒あたりのコンピューティング使用量に対して課金されます。

3 つの追加レプリカが Business Critical サービス レベルに自動的に割り当てられるので、価格は General Purpose サービス レベルの約 2.7 倍です。 同様に、Business Critical サービス レベルでは GB あたりのストレージ価格も高く、ローカル SSD ストレージの高い IO 上限と低待機時間が反映されています。

データとログのストレージ

次の要因は、データ ファイルとログ ファイルに使用されるストレージの量に影響し、General Purpose レベルと Business Critical レベルに適用されます。

  • 各コンピューティング サイズは、構成可能な最大データ サイズをサポートし、既定値は 32 GB です。
  • 最大データ サイズを構成すると、ログ ファイルに対して請求可能なストレージの 30% が自動的に追加されます。
  • General Purpose サービス レベルでは、tempdb によってローカル SSD が使用され、このストレージ コストは、仮想コアの価格に含まれます。
  • Business Critical サービス レベルでは、tempdb によって、データ ファイルやログ ファイルとローカル SSD が共有され、tempdb のストレージ コストは、仮想コアの価格に含まれます。
  • General Purpose レベルと Business Critical レベルでは、データベース、エラスティック プール、またはマネージド インスタンス用に構成された最大ストレージ サイズに対して課金されます。
  • SQL Database では、1 GB からサポートされているストレージ サイズの最大値まで、1 GB単位で任意の最大データサイズを選択できます。 SQL Managed Instanceの場合、サポートされているストレージ サイズの最大値まで、32 GB の倍数のデータ サイズを選択します。

SQL Database で現在割り当てられ、使用されているデータ ストレージのサイズを監視するには、allocated_data_storage と ストレージの Azure Monitor メトリックをそれぞれ使用します。

SQL Database Managed Instance と SQL Managed Instance の両方で、T-SQL を使用してデータベース内の個々のデータ ファイルとログ ファイルの現在の割り当ておよび使用されているストレージ サイズを監視するには、sys.database_files ビューと FILEPROPERTY(... , 'SpaceUsed') 関数を使用します。

ヒント

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。

バックアップ ストレージ

データベース バックアップ用のストレージは、SQL Database と SQL Managed Instance のポイントインタイム リストア (PITR) および長期保有 (LTR) 機能をサポートするために割り当てられます。 このストレージは、データファイルとログファイルのストレージとは別に、別途請求されます。

  • PITR: General Purpose レベルと Business Critical レベルでは、個々のデータベース バックアップは、Azure ストレージに自動的にコピーされます。 ストレージ サイズは、新しいバックアップが作成されるにつれて、動的に増大します。 ストレージは、完全バックアップ、差分バックアップ、およびトランザクション ログ バックアップで使われます。 ストレージの使用量は、データベースの変化率とバックアップに構成された保有期間に応じて異なります。 保有期間は、データベースごとに、SQL Database の場合は 1 日から 35 日、SQL Managed Instance の場合は 0 日から 35 日の間で個別に構成できます。 構成済みの最大データ サイズに等しいバックアップ ストレージ容量が、追加料金なしで提供されます。
  • LTR: 最大 10 年間の完全バックアップとなる長期保存を構成することもできます。 LTR ポリシーを設定した場合、これらのバックアップは、Azure Blob ストレージに自動的に格納されますが、バックアップがコピーされる頻度は制御できます。 さまざまなコンプライアンス要件を満たすために、毎週、毎月、毎年のバックアップに対して異なるリテンション期間を選択することができます。 選択した構成によって、LTR バックアップに使用されるストレージ容量が決まります。 詳細については、「Long-term backup retention」(長期バックアップ リテンション) をご覧ください。

次のステップ

作業を開始するには、次のトピックをご覧ください。

General Purpose サービス レベルと Business Critical サービス レベルで使用できる特定のコンピューティングとストレージ サイズの詳細については、以下を参照してください。