ハイパースケール サービス レベル

適用対象: Azure SQL Database

Azure SQL Database は、インフラストラクチャに障害が発生した場合でも高可用性を確保するために、クラウド環境に合わせて調整された SQL Server データベース エンジン アーキテクチャに基づいています。 Azure SQL Database で使用されているアーキテクチャ モデルは 3 つあります。

  • General Purpose/Standard
  • Business Critical/Premium
  • ハイパースケール

Azure SQL Database の Hyperscale サービス レベルは、仮想コアベースの購入モデルにおける最新のサービス レベルです。 このサービス レベルは、拡張性の高いストレージおよびコンピューティング パフォーマンス レベルであり、Azure のアーキテクチャを利用して、General Purpose および Business Critical サービス レベルの制限を大きく超えて、Azure SQL Database 用のストレージおよびコンピューティング リソースをスケールアウトします。

Note

  • 仮想コアベースの購入モデルでの General Purpose サービス レベルと Business Critical サービス レベルの詳細については、General Purpose サービス レベルと Business Critical サービス レベルの記事を参照してください。 仮想コアベースの購入モデルと DTU ベースの購入モデルとの比較については、Azure SQL Database の購入モデルとリソースに関する記事をご覧ください。
  • Hyperscale サービス レベルは現在、Azure SQL Database でのみ使用でき、Azure SQL Managed Instance では使用できません。

ハイパースケールの機能とは

Azure SQL Database の Hyperscale サービス レベルでは、次の追加機能が提供されます。

  • 最大 100 TB のデータベース サイズのサポート。
  • サイズに関係なく、コンピューティング リソースに対する IO の影響もない、高速データベース バックアップ (Azure BLOB Storage に格納されたファイル スナップショットに基づく)
  • 数時間あるいは数日かからずに数分間で行われる迅速なデータベース復元 (ファイル スナップショットに基づく) (データ操作の規模ではない)。
  • データ ボリュームに関係なく、高いトランザクション ログ スループットと速いトランザクション コミット時間による、全体的に高いパフォーマンス。
  • 迅速なスケールアウト - 読み取りワークロードのオフロード用と、ホット スタンバイ用に、1 つ以上の読み取り専用レプリカをプロビジョニングできます。
  • 迅速なスケールアップ - 大きいワークロードに対応する必要があるときはコンピューティング リソースを一定の時間でスケールアップでき、必要がなくなったらコンピューティング リソースをスケールダウンして戻すことができます。

Hyperscale サービス レベルでは、クラウド データベースにおいて従来見られた実質的な制限の多くが取り除かれます。 他のほとんどのデータベースは 1 つのノードで使用可能なリソースによって制限されますが、Hyperscale サービス レベルのデータベースにはそのような制限はありません。 ストレージ アーキテクチャの柔軟性が高く、必要に応じてストレージが拡張されます。 実際、Hyperscale データベースの作成時には最大サイズは定義されません。 Hyperscale データベースは必要に応じて拡大し、使用している容量に対してのみ課金されます。 読み取り集中型ワークロードでは、Hyperscale サービス レベルにより、読み取りワークロードのオフロード用に必要に応じて追加のレプリカがプロビジョニングされ、迅速なスケールアウトが提供されます。

さらに、データベース バックアップの作成に必要な時間や、スケールアップまたはスケールダウンに必要な時間は、データベース内のデータの量に関連しなくなっています。 Hyperscale データベースはほぼ瞬時にバックアップできます。 また、数十テラバイトのデータベースを、数分でスケールアップまたはスケールダウンできます。 この機能により、初期構成の選択によって縛り付けられることを心配する必要はなくなります。

ハイパースケール サービス レベルのコンピューティング サイズについて詳しくは、「サービス レベルの特性」をご覧ください。

Hyperscale サービス レベルを検討する必要があるユーザー

Hyperscale サービス レベルは、より高いパフォーマンスと可用性、高速のバックアップと復元、高速ストレージとコンピューティングのスケーラビリティを必要とするすべてのお客様を対象としています。 これには、アプリケーションを最新化するためにクラウドに移行中のお客様、および Azure SQL Database の他のサービス レベルを既に使用しているお客様が含まれます。 Hyperscale サービス レベルでは、純粋な OLTP から純粋な分析まで、幅広いデータベース ワークロードがサポートされています。 OLTP およびハイブリッド トランザクションおよび分析処理 (HTAP) ワークロード用に最適化されています。

重要

エラスティック プールでは、Hyperscale サービス レベルはサポートされていません。

ハイパースケールの価格モデル

ハイパースケール サービス レベルは仮想コア モデルのみで提供されています。 新しいアーキテクチャに合わせて、価格モデルは General Purpose または Business Critical サービス モデルとは少し異なります。

  • コンピューティング:

    ハイパースケール コンピューティング ユニットの料金はレプリカ単位です。 高可用性および名前付きレプリカには、Azure ハイブリッド特典の価格が自動的に適用されます。 ユーザーは、可用性とスケーラビリティの要件に応じて、高可用性セカンダリ レプリカの合計数を 0 から 4 までの間で調整し、最大 30 個の名前付きレプリカを作成して、さまざまな読み取りスケールアウト ワークロードをサポートすることができます。

  • ストレージ:

    ハイパースケールのデータベースを構成するときに、最大データ サイズを指定する必要はありません。 Hyperscale レベルでは、実際の割り当てに基づいてデータベースのストレージに対して課金されます。 ストレージは、10 GB から 100 TB までの間 (必要に応じて 10 GB 単位で増分) で自動的に割り当てられます。

ハイパースケールの価格について詳しくは、「Azure SQL Database の価格」をご覧ください。

リソースの制限の比較

次の表で説明するように、仮想コアベースのサービス レベルは、データベースの可用性とストレージの種類、パフォーマンス、最大ストレージ サイズに基づいて区別されます。

汎用 Hyperscale Business Critical
最適な用途 予算重視のバランスの取れたコンピューティングおよびストレージ オプションを提供します。 ほとんどのビジネス ワークロード。 最大 100 TB のストレージ サイズの自動スケーリング、垂直および水平方向への高速コンピューティング スケーリング、データベースの高速復元。 トランザクション レートが高く IO 待ち時間が低い OLTP アプリケーション。 同期的に更新された複数のレプリカを使用して、最高の耐障害性と高速フェールオーバーを提供します。
コンピューティング サイズ 1 - 80 の仮想コア 1 ~ 80 仮想コア1 1 - 80 の仮想コア
ストレージの種類 Premium リモート ストレージ (インスタンスあたり) ローカル SSD キャッシュを使用して切り離したストレージ (インスタンスあたり) 超高速ローカル SSD ストレージ (インスタンスあたり)
ストレージ サイズ 1 5 GB – 4 TB 最大 100 TB 5 GB – 4 TB
IOPS 仮想コアあたり 500 IOPS (最大 7,000 IOPS) Hyperscale は、複数のレベルのキャッシュが存在する複数レベル アーキテクチャです。 有効な IOPS はワークロードによって異なります。 5,000 IOPS (最大 200,000 IOPS)
可用性 1 レプリカ、読み取りスケールアウトなし、ゾーン冗長 HA、ローカル キャッシュなし。 複数のレプリカ、最大 4 読み取りスケールアウト、ゾーン冗長 HA、部分的ローカル キャッシュ 3 レプリカ、1 読み取りスケールアウト、ゾーン冗長 HA、完全ローカル ストレージ
バックアップ geo 冗長、ゾーン冗長、またはローカル冗長のバックアップ ストレージの選択、1 から 35 日の保持期間 (既定値は 7 日) geo 冗長、ゾーン冗長、またはローカル冗長のバックアップ ストレージの選択、1 から 35 日の保持期間 (既定値は 7 日) geo 冗長、ゾーン冗長、またはローカル冗長のバックアップ ストレージの選択、1 から 35 日の保持期間 (既定値は 7 日)

1 エラスティック プールはハイパースケール サービス レベルではサポートされていません。

注意

Hyperscale データベースの 1 日から 35 日までの短期バックアップ保持期間がプレビュー段階になりました。

分散機能アーキテクチャ

Hyperscale では、クエリ処理エンジンと、データの長期的なストレージと持続性を提供するコンポーネントが分かれています。 このアーキテクチャにより、ストレージ容量を必要なだけスムーズにスケーリングする機能 (初期ターゲットは 100 TB) と、コンピューティング リソースを迅速にスケーリングする機能が提供されます。

次は、機能するハイパースケール アーキテクチャの図です。

アーキテクチャ

詳しくは、「Hyperscale の分散機能のアーキテクチャ」をご覧ください。

スケールとパフォーマンスの利点

追加の読み取り専用コンピューティング ノードを迅速に起動/停止できるので、Hyperscale アーキテクチャでは、読み取りのスケーリング機能が優れ、より多くの書き込み要求に対応できるようにプライマリ コンピューティング ノードを解放することもできます。 また、Hyperscale アーキテクチャの共有ストレージ アーキテクチャのため、コンピューティング ノードをすばやくスケールアップ/スケールダウンできます。

Hyperscale データベースを作成して管理する

Hyperscale データベースは、Azure portal、Transact-SQL、PowerShell、Azure CLI を使って、作成および管理できます。 「クイックスタート: Hyperscale データベースを作成する」を参照してください。

操作 詳細 詳細情報
ハイパースケール データベースの作成 ハイパースケール データベースは、仮想コアベースの購入モデルを使用してのみ入手できます。 Hyperscale データベースを作成する例については、「クイックスタート: Azure SQL Database で Hyperscale データベースを作成する」をご覧ください。
既存のデータベースを Hyperscale にアップグレードする Azure SQL Database の既存のデータベースの Hyperscale レベルへの移行は、データ サイズに左右される操作です。 既存のデータベースを Hyperscale に移行する方法を確認してください。
Hyperscale データベースを General Purpose サービス レベルに逆移行する 以前に既存の Azure SQL Database を Hyperscale サービス レベルに移行している場合、元の Hyperscale への移行から 45 日以内であれば、データベースを General Purpose サービス レベルに逆移行できます。

データベースを別のサービス レベル (Business Critical など) に移行する場合は、まず General Purpose サービス レベルに逆移行してから、サービス レベルを変更します。
逆移行に関する制限事項など、Hyperscale から逆移行する方法を確認してください。

Hyperscale でのデータベースの高可用性

他のすべてのサービス レベルと同様に、Hyperscale は、コンピューティング レプリカの可用性に関係なく、コミットされたトランザクションのデータの持続性を保証します。 プライマリ レプリカが使用できなくなったことによるダウンタイムの期間は、フェールオーバーの種類 (計画的か、計画外か)、ゾーン冗長が構成されているかどうか、少なくとも 1 つの高可用性レプリカが存在することに依存します。 計画フェールオーバー (つまりメンテナンス イベント) では、システムによってフェールオーバーの開始前に新しいプライマリ レプリカが作成されるか、または既存の高可用性レプリカがフェールオーバー ターゲットとして使用されます。 計画外のフェールオーバー (つまりプライマリ レプリカでのハードウェア障害) では、システムによって、高可用性レプリカがフェールオーバー ターゲットとして使用されるか (存在する場合)、または使用可能なコンピューティング容量のプールから新しいプライマリ レプリカが作成されます。 後者の場合、新しいプライマリ レプリカの作成に必要な追加の手順により、ダウンタイムの期間が長くなります。

Hyperscale の SLA については、「SLA for Azure SQL Database の SLA」を参照してください。

バックアップと復元

Hyperscale データベースのバックアップと復元操作は、ファイル スナップショットに基づきます。 これにより、これらの操作はほぼ瞬時に実行できます。 Hyperscale アーキテクチャではバックアップと復元にストレージ レイヤーが利用されるため、コンピューティング レプリカに関する処理の負荷とパフォーマンスへの影響が大幅に軽減されます。 詳しくは、「Hyperscale のバックアップとストレージの冗長性」をご覧ください。

Hyperscale データベースのディザスター リカバリー

ディザスター リカバリー操作の一環として、またはドリル、再配置などの他の理由で、Azure SQL Database の Hyperscale データベースを、現在ホストされているリージョン以外のリージョンに復元する必要がある場合、主な方法として、データベースの geo リストアを実行します。 geo リストアは、ストレージの冗長性に geo 冗長ストレージ (RA-GRS) が選ばれている場合にのみ使用できます。

詳しくは、「Hyperscale データベースを別のリージョンに復元する」をご覧ください。

既知の制限事項

以下は、Hyperscale サービス レベルの現在の制限事項です。 これらの制限事項ができるだけなくなるように、積極的に取り組んでいます。

問題 説明
短期のバックアップ保持期間 Hyperscale データベースの 1 日から 35 日までの短期バックアップ保持期間がプレビュー段階になりました。 Hyperscale 以外のデータベースを Hyperscale データベースとして復元することも、Hyperscale データベースを Hyperscale 以外のデータベースとして復元することもできません。

他の Azure SQL Database サービス レベルからハイパースケールに移行されたデータベースの場合、移行前のバックアップは、長期的なリテンション 期間ポリシーを含む、ソース データベースのバックアップ保持期間の間保持されます。 データベースのバックアップ保持期間中の移行前バックアップの復元は、コマンド ラインでサポートされています。 これらのバックアップは、Hyperscape 以外のサービス レベルに復元できます。
長期のバックアップ リテンション期間 Hyperscale データベースの長期バックアップ保持期間がプレビュー段階になりました。
サービス レベルの Hyperscale から General Purpose レベルへの変更は、限られたシナリオで直接サポートされます Hyperscale から逆移行により、既存の Azure SQL Database を Hyperscale サービス レベルに最近移行したお客様は、Hyperscale でニーズを満たせなかった場合、General Purpose サービス レベルに移行することができます。 逆移行はサービス レベルの変更によって開始されますが、基本的には異なるアーキテクチャ間でデータのサイズが移動されます。 Hyperscale サービス レベルで作成されたデータベースは、逆移行の対象になりません。 逆移行の制限事項について学習します。

逆移行の対象にならないデータベースの場合、Hyperscale から Hyperscale 以外のサービス レベルに移行する唯一の方法は、BACPAC ファイルまたはその他のデータ移動テクノロジ (一括コピー、Azure Data Factory、Azure Databricks、SSIS など) を使用してエクスポートおよびインポートすることです。Azure portal、PowerShell (New-AzSqlDatabaseExportNew-AzSqlDatabaseImport)、Azure CLI (az sql db exportaz sql db import)、REST API から BACPAC のエクスポートとインポートを行うことはサポートされていません。 比較的小さい Hyperscale データベース (最大 200 GB) の BACPAC インポートと BACPAC エクスポートは、SSMS と SqlPackage バージョン 18.4 以降を使用することでサポートされます。 大きなデータベースでは、BACPAC エクスポートと BACPAC インポートに時間がかかり、さまざまな理由で失敗する可能性があります。
エラスティック プール エラスティック プールは、現在、Hyperscale ではサポートされていません。
インメモリ OLTP オブジェクトを使用したデータベースの移行 Hyperscale では、メモリ最適化テーブルの型、テーブル変数、ネイティブ コンパイルされたモジュールなど、インメモリ OLTP オブジェクトのサブセットがサポートされています。 ただし、どのようなインメモリ OLTP オブジェクトでも移行されているデータベースに存在すると、Premium および Business Critical サービス レベルから Hyperscale に移行できません。 このようなデータベースを Hyperscale に移行するには、すべてのインメモリ OLTP オブジェクトとその依存関係を削除する必要があります。 データベースを移行した後は、これらのオブジェクトを再作成できます。 永続的と非永続的なメモリ最適化テーブルは Hyperscale では現在サポートされておらず、ディスク テーブルに変更する必要があります。
データベースの圧縮 DBCC SHRINKDATABASE、DBCC SHRINKFILE、またはデータベース レベルで AUTO_SHRINK を ON に設定することは、Hyperscale データベースでは現在サポートされていません。
データベースの整合性チェック DBCC CHECKDB は現在、Hyperscale データベースではサポートされていません。 DBCC CHECKTABLE ('TableName') WITH TABLOCK と DBCC CHECKFILEGROUP WITH TABLOCK を回避策として使用できます。 Azure SQL Database におけるデータ整合性管理の詳細については、「Azure SQL Database でのデータ整合性」を参照してください。
エラスティック ジョブ Hyperscale データベースをジョブ データベースとして使用することはサポートされていません。 ただし、エラスティック ジョブでは、Azure SQL Database の他のデータベースと同じ方法で、Hyperscale データベースを対象にすることができます。
データ同期 Hyperscale データベースをハブまたは同期メタデータ データベースとして使用する機能はサポートされていません。 ただし、Hyperscale データベースは、データ同期トポロジ内のメンバー データベースになることができます。

次のステップ

Azure SQL Database での Hyperscale について詳しくは、次の記事をご覧ください。