仮想コア購入モデル - Azure SQL Managed Instance

適用対象:Azure SQL Managed Instance

この記事では、Azure SQL Managed Instance 用の仮想コア購入モデルをレビュー認します。

概要

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

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

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

Azure SQL Managed Instance で使用される仮想コア (vCore) 購入モデルには、次のような利点があります。

• ワークロードのコンピューティング要件とメモリ要件をより満たすようにハードウェアの構成を制御します。
• Azure ハイブリッド特典 (AHB) および予約インスタンス (RI) に対する料金割引。
• コンピューティングを強化するハードウェア詳細における透明性の向上。オンプレミスのデプロイからの移行計画を容易にします。
• スケーリング粒度が向上し、複数のコンピューティング サイズを利用できます。

コンピューティング

SQL Managed Instance コンピューティングでは、ワークロード アクティビティとは無関係に、継続的にプロビジョニングされる特定の量のコンピューティング リソースを提供し、時間あたりの固定価格でプロビジョニングされたコンピューティング使用量に対して請求します。

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

General Purpose サービス レベルのインスタンスの場合、使用していないインスタンスを停止することで、コンピューティングとライセンス コストを節約できます。 詳細については、「インスタンスの停止と開始」を参照してください。

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

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

• General Purpose サービス レベルでは、tempdb によってローカル SSD が使用され、このストレージ コストは、仮想コアの価格に含まれます。
• Business Critical サービス レベルでは、tempdb によって、データ ファイルやログ ファイルとローカル SSD が共有され、tempdb のストレージ コストは、仮想コアの価格に含まれます。
• SQL Managed Instance での最大ストレージ サイズは、32 GB の倍数で指定する必要があります。

SQL Managed Instance の消費されている合計インスタンス ストレージ サイズを監視するには、storage_space_used_mbメトリックを使用します。 T-SQL を使用して、データベース内の個々のデータ ファイルとログ ファイルの現在割り当てられ、使用されているストレージ サイズを監視するには、sys.database_files ビューと FILEPROPERTY(... , 'SpaceUsed') 関数を使用します。

バックアップ ストレージ

データベース バックアップ用のストレージは、SQL Managed Instance の機能をサポートするために割り当てられます。 このストレージは、データファイルとログファイルのストレージとは別に、別途請求されます。

• ポイントインタイム リストア (PITR): ストレージの使用量は、データベースの変化率とバックアップ用に構成された保有期間に応じて異なります。 保有期間は、データベースごとに、SQL Managed Instance の場合は 1 日から 35 日の間で個別に構成できます。 構成済みの最大データ サイズに等しいバックアップ ストレージ容量が、追加料金なしで提供されます。
• 長期保有 (LTR): 最大 10 年間の完全バックアップとなる長期保有を構成することができます。 選択した構成によって、LTR バックアップに使用されるストレージ容量が決まります。

サービス階層

サービス レベルでは一般に、ストレージ アーキテクチャ、容量と I/O の制限、および可用性とディザスター リカバリーに関連するビジネス継続性のオプションが定義されています。

Azure SQL Managed Instance にはサービス レベルが 2 つあります。

• 汎用。 アップグレードされた Next-gen General Purpose サービス レベル (プレビュー) の使用を選択できます。
• ビジネス上、必要不可欠です。

サービス レベル間の詳細な比較については、リソースの制限で確認できますが、簡単な概要については次の表を使用してください。

General Purpose

General Purpose サービス レベルのアーキテクチャ モデルは、コンピューティングとストレージの分離に基づきます。 このアーキテクチャ モデルでは、データベース ファイルが透過的にレプリケートされ、基盤となるインフラストラクチャで障害が発生した場合にデータ損失が発生しないことが保証されている Azure Blob Storage の高可用性と信頼性に依存しています。

次の図は、計算レイヤーとストレージ レイヤーが分離されている Standard アーキテクチャ モデルの 4 ノードを示しています。

General Purpose サービス レベルのアーキテクチャ モデルには、2 つのレイヤーがあります。

• ステートレス計算レイヤー。sqlservr.exe プロセスを実行しており、一時的なデータとキャッシュ データのみが含まれています (プラン キャッシュ、バッファー プール、列のストア プールなど)。 このステートレス ノードは、プロセスの初期化、ノードの正常性の制御、および他の場所へのフェールオーバーを必要に応じて実行する Azure Service Fabric によって操作されます。
• ステートフル データ レイヤー。データベース ファイル (.mdf/.ldf) は Azure Blob Storage に保存されています。 Azure Blob Storage では、データベース ファイル内にあるレコードのデータが消失しないことが保証されています。 Azure Storage には、データの可用性と冗長性が組み込まれており、たとえプロセスがクラッシュしても、ログ ファイルのレコードやデータ ファイルのページがすべて確実に維持されます。

データベース エンジンまたはオペレーティング システムがアップグレードされた場合、基となるインフラストラクチャの一部で障害が発生した場合、または sqlservr.exe プロセスで重大な問題が検出された場合、Azure Service Fabric は、ステートレス プロセスを別のステートレス計算ノードに移行します。 フェールオーバー時間を最小限に抑えるために、プライマリ ノードのフェールオーバーが発生した場合に新しい計算サービスの実行を待機している一連のスペア ノードがあります。 Azure Storage レイヤーのデータは影響を受けず、データおよびログ ファイルは、新しく初期化されたプロセスにアタッチされます。 このプロセスでは、既定で 99.99% の可用性が保証されます。 移行時間や、新しいノードの起動にコールド キャッシュを使用することが原因で、処理中の大きなワークロードのパフォーマンスが影響を受ける可能性があります。

このサービス レベルを選択する場合

General Purpose サービス レベルは、ほとんどの一般的なワークロード向けに設計されている Azure SQL Managed Instance の既定のサービス レベルです。 既定の SLA が設定された、ストレージの待機時間が 5 から 10 ミリ秒のフル マネージド データベース エンジンが必要な場合は、General Purpose レベルをお勧めします。

Next-gen General Purpose

Next-gen General Purpose サービス レベルは、次の主要な特性を提供する既存の General Purpose サービス レベルのアーキテクチャ アップグレードです。

• General Purpose サービス レベルと同じ基準コストを提供しながら、パフォーマンス要件がより高い事業向けに設計されています
• General Purpose サービス レベルに対するパフォーマンス、スケーラビリティ、およびリソースの柔軟性に対する大幅なアップグレード
• ページ BLOB の代わりにマネージド ディスクを使用します。この結果、ストレージ パフォーマンス メトリックが大幅に向上します
• 予約ストレージ 1 GB ごとに 3 つの無料 IOPS
• インスタンスあたり最大 500 個のデータベースをサポートし、最大ストレージ サイズは 32 TB

Next-gen General Purpose サービス レベルは既存の General Purpose サービス レベルへのアップグレードであるため、インスタンスが使用するサービス レベルに関係なく、課金ステートメントには General Purpose サービス レベルが反映されます。

アーキテクチャ モデル

Next-gen General Purpose サービス レベルは、アップグレードされたリモート ストレージ レイヤを使用して、ページ BLOB ではなくマネージド ディスクにインスタンス データとログ ファイルを格納する既存の General Purpose サービス レベルへのアップグレードです。 つまり、Next-gen General Purpose サービス レベルのアップグレードでは、ストレージの待機時間、IOPS、処理能力が既存の General Purpose サービス レベルよりも高速になり、ストレージの制限、仮想コアの数、データベースの最大数が増えます。 さらに、パフォーマンス クォータはインスタンス全体で共有されるため、パフォーマンスを向上させるために個々のファイルのサイズを変更する必要がなくなりました。 Next-gen General Purpose サービス レベルの基準コストは General Purpose サービス レベルと同じですが、スライダーを使用して IO パフォーマンスを向上させることができます。この操作は、別枠で課金されます。

Next-gen General Purpose サービス レベルは、予約ストレージ 1 GB ごとに 3 個の無料 IOPS を提供することで、コストを削減するのに役立ちます。 ストレージの価格には、最小 IOPS が含まれます。 最小値を超えた場合は、次のように課金されます。1 IOPS = ストレージ価格 (リージョン別) ÷ 3。

次に例を示します。

• ストレージの 1 GB のコストが 0.115 の場合、1 IOPS = 0.115/3 = 1 IOPS あたり 0.038。
• 1,024 GB のインスタンスでは、IOPS 3072 個が無料で付きます。 追加コストを支払って VM の上限まで IOPS を増やすことを選択できます。

このサービス レベルを選択する場合

会社が予算指向であっても、General Purpose サービス レベルのパフォーマンス メトリックと制限が適切でない場合は、このサービス レベルを選択します。

General Purpose レベルではなく、Next-gen General Purpose サービス レベルを選択した方がよい主な理由は次のとおりです。

• 同じ基準コストに対しパフォーマンスが向上
• 待機時間、処理能力、IOPS が向上
• より大きなストレージ容量
• コンピューティングにおけるより高い柔軟性
• 1 つのインスタンスに対して 100 を超えるデータベースが必要です
• 16 TB を超える予約ストレージが必要です

Business Critical

Business Critical サービス レベル モデルは、データベース エンジン プロセスのクラスターに基づいています。 このアーキテクチャ モデルは、メンテナンス作業中でもワークロードに対するパフォーマンスの影響を最小限にする常に使用可能なデータベース エンジン ノードのクォーラムに依存しています。 Azure では、基盤となるオペレーティング システム、ドライバー、および SQL Server データベース エンジンに対して、アップグレードとパッチ適用が透過的に実行されます。これにより、エンド ユーザーのダウンタイムは最小限に抑えられます。

Business Critical モデルでは、コンピューティングとストレージが各ノードで統合されます。 高可用性は、4 つのノード クラスターの各ノード上のデータベース エンジン プロセス間でデータをレプリケーションし、ローカルに接続された SSD をデータ ストレージとして各ノードで使用することで達成されます。

SQL Server データベース エンジン プロセスと、基礎となる .mdf/.ldf ファイルは、両方とも同じノード上に配置されます。このノードには、SSD ストレージが接続されているため、ワークロードに対する待ち時間が短くなります。 高可用性は、SQL Server Always On 可用性グループと同様のテクノロジを使用して実装されます。

すべてのインスタンスは、インスタンス上のすべてのデータベースのコピーを含むデータベース エンジン ノードのクラスターであり、顧客のワークロードにアクセスできるプライマリ データベースと、データのコピーを含む 3 つのセカンダリ データベースがあり、フェールオーバーの準備ができています。 プライマリ ノードは、変更内容を絶えずセカンダリ ノードにプッシュしています。これは、何らかの原因でプライマリ ノードで障害が発生した場合でも、セカンダリ レプリカでデータを確実に使用できるようにするためです。

フェールオーバーは、SQL Server データベース エンジンで処理されます。つまり、あるセカンダリ レプリカがプライマリ ノードになると、クラスター内のノード数を十分に確保するために、新しいセカンダリ レプリカが作成されます。 ワークロードは、新しいプライマリ ノードに自動的にリダイレクトされます。

さらに、Business Critical クラスターには、プライマリ レプリカのワークロードのパフォーマンスに影響を与えない読み取り専用クエリ (レポートなど) を実行するために使用される無料の読み取り専用レプリカを提供する、読み取りスケールアウト機能が組み込まれています。

このサービス レベルを選択する場合

Business Critical サービス レベルの対象となるアプリケーションは、基盤となる SSD ストレージからの応答の待機時間が短い (平均 1 から 2 ms)、基盤となるインフラストラクチャに障害が発生した場合により迅速に復旧するという要件があるか、レポート、分析、および読み取り専用のクエリをプライマリ データベースの無料で読み取り可能なセカンダリ レプリカにオフロードする必要があります。

General Purpose レベルではなく、Business Critical サービス レベルを選択すべき主な理由は、次のとおりです。

• 短いI/O 待機時間の要件。ストレージ レイヤーから迅速な応答が必要なワークロード (平均 1 - 2 ミリ秒) では、Business Critical レベルを使用する必要があります。
• レポートと分析クエリを使用したワークロード。これにより、無料の読み取り専用のセカンダリ レプリカにリダイレクトされる可能性があります。
• 障害からのより高い回復性とより早い復旧。 システム障害が発生した場合、プライマリ インスタンス上のデータベースはオフラインになり、セカンダリ レプリカの 1 つがすぐに新しい読み取り/書き込みプライマリ インスタンスになり、クエリを処理する準備が整います。 データベース エンジンでログ ファイルを分析し、トランザクションを再実行し、データをメモリ バッファーに読み込む必要はありません。
• データの破損からの高度な保護。 Business Critical レベルではバックグラウンドでデータベース レプリカが使用されるため、サービスはミラーリングと可用性グループで使用可能な自動ページ修復を利用して、データの破損を軽減します。 データの整合性の問題が原因でレプリカでページを読み取ることができない場合、読み取り不可能なページは、データの損失や顧客のダウンタイムなしで、別のレプリカから新しいコピーが取得され、置き換えられます。 この機能は、マネージド インスタンスに geo セカンダリ レプリカがある場合、General Purpose レベルで使用できます。
• 高可用性 - マルチ可用性ゾーン構成内の Business Critical レベルでは、ゾーン障害に対する回復性と、高可用性 SLA が提供されます。
• 高速 geo リカバリー - フェールオーバー グループが構成されている場合、Business Critical レベルでは、100% のデプロイ時間に対して、5 秒の回復ポイントの目標 (RPO) と 30 秒の回復時間の目標 (RTO) が保証されています。

テンプレートまたはスクリプトでサービス レベルを指定する場合、レベルは名前を使用して提供されます。 次の表が適用されます。

ハードウェア構成

仮想コアモデルのハードウェア構成オプションには、Standardシリーズ(Gen5)、Premiumシリーズ、メモリ最適化Premiumシリーズが含まれます。 ハードウェア構成では、一般に、ワークロードのパフォーマンスに影響を与えるコンピューティングおよびメモリの制限とその他の特性を定義します。

ハードウェア構成の詳細と制限事項について詳しくは、「ハードウェア構成の特性」をご覧ください。

sys.dm_user_db_resource_governance 動的管理ビューでは、Intel® SP-8160 (Skylake) プロセッサを使用するインスタンスのハードウェア世代は Gen6 と表示され、Intel® 8272CL (Cascade Lake) を使用するインスタンスのハードウェア世代は Gen7 と表示されます。 Premium シリーズとメモリ最適化 Premium シリーズのハードウェア世代で使用される Intel® 8370C (Ice Lake) CPU は、Gen8 と表示されます。 Standard シリーズ (Gen5) のすべてのインスタンスに対するリソース制限は、プロセッサの種類 (Broadwell、Skylake、Cascade Lake) に関係なく同じです。

ハードウェア構成を選択

インスタンスの作成時にハードウェア構成を選択することも、既存のインスタンスのハードウェアを変更することもできます。

SQL Managed Instanceの作成時にハードウェア構成を選択するには

詳細については、SQL Managed Instance の作成に関するページを参照してください。

[基本]タブで、[コンピューティングとストレージ]セクションの[データベースの構成]リンクを選択し、使用するハードウェアを選択します:

既存のSQL Managed Instanceのハードウェアを変更するには

Set-AzSqlInstance -Name "managedinstance1" -ResourceGroupName "ResourceGroup01" -ComputeGeneration Gen5

az sql mi update -g mygroup -n myinstance --family Gen5

テンプレートまたはスクリプトでハードウェア パラメーターを指定する場合、ハードウェアはその名前を使用して指定されます。 次の表が適用されます。

SKU 名

ハードウェアの可用性

Standard シリーズ (Gen5) と Premium シリーズ

Standard シリーズ (Gen5) と Premium シリーズのハードウェアは、世界中のすべてのパブリック リージョンで利用できます。

メモリ最適化 Premium シリーズのハードウェアはプレビュー段階であり、利用できるリージョンは限られています。 詳細については、Azure SQL Managed Instance のリソース制限の概要に関する説明を参照してください。

関連するコンテンツ

• Azure portal を使用して SQL Managed Instance を作成する
• Azure SQL マネージド単一インスタンスの価格に関するページ
• Azure SQL マネージド単一インスタンス プールの価格に関するページ
• Azure SQL Managed Instance の仮想コア ベースのリソース制限