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

適用対象:Azure SQL データベース

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

• General Purpose
• Business Critical
• Hyperscale

Hyperscale サービス レベルは、すべてのワークロードの種類に適しています。 そのクラウド ネイティブなアーキテクチャにより、従来および最新のさまざまなアプリケーションをサポートするための、独立してスケーラブルなコンピューティングとストレージが提供されます。 Hyperscale のコンピューティングとストレージのリソースは、General Purpose と Business Critical のレベルで使用可能なリソースを大幅に超えています。

仮想コアベースの購入モデルでの General Purpose サービス レベルと Business Critical サービス レベルの詳細については、General Purpose サービス レベルと Business Critical サービス レベルの記事を参照してください。 仮想コアベースの購入モデルと DTU ベースの購入モデルとの比較については、Azure SQL Database の vCore ベースと DTU ベースの購入モデルとリソースに関する記事をご覧ください。

Hyperscale サービス レベルは現在、Azure SQL Database でのみ使用でき、Azure SQL Managed Instance では使用できません。

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

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

• 迅速なスケールアップ - 大きいワークロードに対応する必要があるときはコンピューティング リソースを一定の時間でスケールアップでき、必要がなくなったらコンピューティング リソースをスケールダウンして戻すことができます。
• 迅速なスケールアウト - 読み取りワークロードのオフロード用と、ホット スタンバイ用に、1 つ以上の読み取り専用レプリカをプロビジョニングできます。
• サーバーレス コンピューティングでの使用量に基づくコンピューティングの自動スケールアップ、スケールダウンおよび課金。
• Elastic Pool を使用したさまざまなリソース要求がある Hyperscale データベース グループの価格/パフォーマンスの最適化。
• 最大 128 TB のデータベースまたは 100 TB のエラスティック プール サイズをサポートするストレージの自動スケーリング。
• データ ボリュームに関係なく、高いトランザクション ログ スループットと速いトランザクション コミット時間による、全体的に高いパフォーマンス。
• コンピューティング リソースに I/O の影響を与えない、(ファイル スナップショットに基づく) 高速データベース バックアップ。
• 何時間あるいは何日もかけず、数分間で行う (ファイル スナップショットに基づく) 迅速なデータベース復元またはコピー。

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

さらに、データベース バックアップの作成に必要な時間や、スケールアップまたはスケールダウンに必要な時間は、データベース内のデータの量に関連しなくなっています。 Hyperscale データベースはほぼ瞬時にバックアップされます。 プロビジョニングされたコンピューティング レベルで数十テラバイトのデータベースを数分以内にスケールアップまたはスケールダウンしたり、サーバーレスを使ってコンピューティングを自動的にスケーリングしたりすることもできます。 この機能により、初期構成の選択によって縛り付けられることを心配する必要はなくなります。

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

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

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

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

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

• プロビジョニングされるコンピューティング:

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

• サーバーレス コンピューティング:

  サーバーレス コンピューティングの課金は使用量に基づきます。 詳細については、「Azure SQL Database のサーバーレス コンピューティング レベル」を参照してください。

• ストレージ:

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

Hyperscale の価格について詳しくは、「Azure SQL データベースの価格」をご覧ください。

分散機能アーキテクチャ

Hyperscale では、クエリ処理エンジンと、データの長期的なストレージと持続性を提供するコンポーネントが分かれています。 このアーキテクチャを使用すると、必要な限り (最大 128 TB) ストレージ容量をスムーズにスケーリングでき、コンピューティング リソースを迅速にスケーリングできます。

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

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

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

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

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

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

影響を与えるメンテナンス イベントを予測可能にし、ワークロードの中断を減らすことができるメンテナンス期間を選択できます。

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

バッファー プール、回復性があるバッファー プール拡張機能、継続的プライミング

Azure Database Hyperscale では、コンピューティングとストレージの間に明確な分離があります。 ストレージには、1 つのデータベース内のすべてのデータベース ページが含まれており、データベースの拡大に合わせて複数のマシンに割り当てられます。 ただし、計算ノードでは、最近使用されているもののみがキャッシュされます。 コンピューティングで最近使用されたページは、バッファー プール (BP) と呼ばれる構造のメモリ内に保持されます。 また、ローカル SSD (回復性のあるバッファー プール拡張機能 (RBPEX)) にも格納されるため、コンピューティング プロセスが再起動した場合に備えて、データをより高速に取得できます。

クラウド システムでは、コンピューティングは必要に応じて異なるマシンに移動できます。 コンピューティング レイヤーには複数のレプリカを含めることができます。 1 つはプライマリであり、すべての更新を受け取り、その他はセカンダリ レプリカです。 プライマリに障害が発生した場合、高可用性セカンダリ レプリカの 1 つは、フェールオーバーと呼ばれるプロセスですぐにプライマリに昇格できます。 セカンダリ レプリカの BP と RBPEX は、プライマリ ワークロード用に最適化されたキャッシュを持っていない可能性があります。

継続的プライミングは、すべてのコンピューティング レプリカの中で、最近使用されたページに関する情報を収集するプロセスです。 この情報は集計され、高可用性セカンダリ レプリカでは、一般的な顧客ワークロードに対応する最近使用されたページのリストが使用されます。 これにより、BP と RBPEX の両方に、最近使用されたページが継続的に埋め込まれるので、顧客のワークロードの変化に対応できます。

継続的プライミングがないと、BP と RBPEX の両方が新しい高可用性レプリカに継承されず、ユーザー ワークロード中にのみ再構築されます。 継続的プライミングは時間を節約し、キャッシュが再び完全にハイドレートされるまでの待ち時間がないため、パフォーマンスの不整合を防ぎます。 継続的プライミングにより、新しい高可用性セカンダリ レプリカは、BP と RBPEX のプライミングをすぐに開始します。 これにより、フェールオーバーが発生した場合の一貫したパフォーマンスの維持に役立ちます。

継続的プライミングは、高可用性セカンダリ レプリカとプライマリの両方向に機能します。高可用性セカンダリ レプリカでは、プライマリ レプリカで使用されているページをキャッシュし、プライマリでは、セカンダリ レプリカのワークロードを含むページをキャッシュします。

バックアップと復元

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

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

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

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

リソースの制限の比較

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

¹ SQL Database Hyperscale の簡略化された価格は、2023 年 12 月に導入されました。 詳細については、Hyperscale の価格に関するブログを参照してください。

² 2023 年 12 月の時点では、Azure ハイブリッド特典は新しい Hyperscale データベースや Dev/Test サブスクリプションに利用できません。 プロビジョニングされたコンピューティングを使用する既存の Hyperscale 単一データベースは、2026 年 12 月まで引き続き Azure ハイブリッド特典を使用してコンピューティング コストを節約できます。 詳細については、「Hyperscale 価格のブログ」を確認してください。

コンピューティング リソース

¹ “sys.dm_user_db_resource_governance“の動的管理ビューでは、Intel® SP-8160(Skylake)プロセッサを使用するデータベースのハードウェア世代は Gen6、Intel® 8272CL(Cascade Lake)を使用するデータベースのハードウェア世代は Gen7、Intel Xeon® Platinum 8370C(Ice Lake)または AMD® EPYC® 7763v(Milan)を使用するデータベースのハードウェア世代は Gen8 として表示されます。 特定のコンピューティング サイズとハードウェア構成では、リソースの制限は、CPU の種類に関係なく同じです。 詳細については、単一データベースおよびエラスティック プールのリソース制限に関するページをご覧ください。

サーバーレスは、Standard シリーズ (Gen5) のハードウェアでのみサポートされます。

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

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

圧縮

データベースとファイルの縮小操作は現在、Azure SQL データベース Hyperscale のプレビュー段階です。 プレビューの詳細については、「Azure SQL データベース Hyperscale の縮小」をご覧ください。

既知の制限事項

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

関連するコンテンツ

• Hyperscale に関してよく寄せられる質問
• Azure SQL Database の仮想コアと DTU ベースの購入モデルを比較
• Azure SQL Database でのリソース管理
• 仮想コア購入モデルを使用した単一データベースに対するリソース制限
• 機能の比較:Azure SQL Database と Azure SQL Managed Instance
• Hyperscale の分散機能のアーキテクチャ
• Hyperscale データベースを管理する方法