最大 100 TB のハイパースケール サービス レベル (プレビュー)Hyperscale service tier (preview) for up to 100 TB

Azure SQL Database は、インフラストラクチャに障害が発生した場合でも 99.99% の可用性を確保するために、クラウド環境に合わせて調整された SQL Server データベース エンジン アーキテクチャに基づいています。Azure SQL Database is based on SQL Server Database Engine architecture that is adjusted for the cloud environment in order to ensure 99.99% availability even in the cases of infrastructure failures. Azure SQL Database で使用されているアーキテクチャ モデルは 3 つあります。There are three architectural models that are used in Azure SQL Database:

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

Azure SQL Database の Hyperscale サービス レベルは、仮想コアベースの購入モデルにおける最新のサービス レベルです。The Hyperscale service tier in Azure SQL Database is the newest service tier in the vCore-based purchasing model. このサービス レベルは、拡張性の高いストレージおよびコンピューティング パフォーマンス レベルであり、Azure のアーキテクチャを利用して、General Purpose および Business Critical サービス レベルの制限を大きく超えて、Azure SQL Database 用のストレージおよびコンピューティング リソースをスケールアウトします。This service tier is a highly scalable storage and compute performance tier that leverages the Azure architecture to scale out the storage and compute resources for an Azure SQL Database substantially beyond the limits available for the General Purpose and Business Critical service tiers.

重要

ハイパースケール サービス レベルは現在パブリック プレビュー段階であり、一部の Azure リージョンのみで使用できます。Hyperscale service tier is currently in public preview and available in limited Azure regions. 完全なリージョンの一覧については、ハイパースケール サービス レベル対応リージョンをご覧ください。For the full region list, see Hyperscale service tier available regions. ハイパースケール データベースで本番用のワークロードを実行することは、現時点ではお勧めしません。We don't recommend running any production workload in Hyperscale databases yet. ハイパースケール データベースを他のサービス レベルに更新することはできません。You can't update a Hyperscale database to other service tiers. テスト用として、現在のデータベースのコピーを作成し、そのコピーをハイパースケール サービス レベルに更新することをお勧めします。For test purpose, we recommend you make a copy of your current database, and update the copy to Hyperscale service tier.

注意

仮想コアベースの購入モデルでの General Purpose サービス レベルと Business Critical サービス レベルの詳細については、General Purpose サービス レベルと Business Critical サービス レベルの記事を参照してください。For details on the General Purpose and Business Critical service tiers in the vCore-based purchasing model, see General Purpose and Business Critical service tiers. 仮想コアベースの購入モデルと DTU ベースの購入モデルとの比較については、Azure SQL Database の購入モデルとリソースに関する記事をご覧ください。For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see Azure SQL Database purchasing models and resources.

重要

ハイパースケール サービス レベルは現在パブリック プレビュー段階です。Hyperscale service tier is currently in public preview. ハイパースケール データベースで本番用のワークロードを実行することは、現時点ではお勧めしません。We don't recommend running any production workload in Hyperscale databases yet. ハイパースケール データベースを他のサービス レベルに更新することはできません。You can't update a Hyperscale database to other service tiers. テスト用として、現在のデータベースのコピーを作成し、そのコピーをハイパースケール サービス レベルに更新することをお勧めします。For test purpose, we recommend you make a copy of your current database, and update the copy to Hyperscale service tier.

ハイパースケールの機能とはWhat are the Hyperscale capabilities

Azure SQL Database の Hyperscale サービス レベルでは、次の追加機能が提供されます。The Hyperscale service tier in Azure SQL Database provides the following additional capabilities:

  • 最大 100 TB のデータベース サイズのサポートSupport for up to 100 TB of database size
  • サイズに関係なく、コンピューティングに対する IO の影響もなく、ほぼ瞬間的に行われるデータベース バックアップ (Azure BLOB Storage に格納されたファイル スナップショットに基づく)Nearly instantaneous database backups (based on file snapshots stored in Azure Blob storage) regardless of size with no IO impact on Compute
  • 数時間あるいは数日かからずに数分間で行われる迅速なデータベース復元 (ファイル スナップショットに基づく) (データ操作の規模ではない)Fast database restores (based on file snapshots) in minutes rather than hours or days (not a size of data operation)
  • データ ボリュームに関係なく、高いログ スループットと速いトランザクション コミット時間による、全体的に高いパフォーマンスHigher overall performance due to higher log throughput and faster transaction commit times regardless of data volumes
  • 迅速なスケールアウト - 読み取りワークロードのオフロード用と、ホット スタンバイ用に、1 つ以上の読み取り専用ノードをプロビジョニングできます。Rapid scale out - you can provision one or more read-only nodes for offloading your read workload and for use as hot-standbys
  • 迅速なスケールアップ - 大きいワークロードに対応する必要があるときはコンピューティング リソースを一定の時間でスケールアップでき、必要がなくなったらコンピューティング リソースをスケールダウンして戻すことができます。Rapid Scale up - you can, in constant time, scale up your compute resources to accommodate heavy workloads as and when needed, and then scale the compute resources back down when not needed.

Hyperscale サービス レベルでは、クラウド データベースにおいて従来見られた実質的な制限の多くが取り除かれます。The Hyperscale service tier removes many of the practical limits traditionally seen in cloud databases. 他のほとんどのデータベースは 1 つのノードで使用可能なリソースによって制限されますが、Hyperscale サービス レベルのデータベースにはそのような制限はありません。Where most other databases are limited by the resources available in a single node, databases in the Hyperscale service tier have no such limits. ストレージ アーキテクチャの柔軟性が高く、必要に応じてストレージが拡張されます。With its flexible storage architecture, storage grows as needed. 実際、Hyperscale データベースの作成時には最大サイズは定義されません。In fact, Hyperscale databases aren’t created with a defined max size. Hyperscale データベースは必要に応じて拡大し、使用している容量に対してのみ課金されます。A Hyperscale database grows as needed - and you are billed only for the capacity you use. 読み取り集中型ワークロードでは、Hyperscale サービス レベルは、読み取りワークロードのオフロード用に必要に応じて追加の読み取りレプリカをプロビジョニングし、迅速なスケールアウトを提供します。For read-intensive workloads, the Hyperscale service tier provides rapid scale-out by provisioning additional read replicas as needed for offloading read workloads.

さらに、データベース バックアップの作成に必要な時間や、スケールアップまたはスケールダウンに必要な時間は、データベース内のデータの量に関連しなくなっています。Additionally, the time required to create database backups or to scale up or down is no longer tied to the volume of data in the database. Hyperscale データベースはほぼ瞬時にバックアップできます。Hyperscale databases can be backed up virtually instantaneously. また、数十テラバイトのデータベースを、数分でスケールアップまたはスケールダウンできます。You can also scale a database in the tens of terabytes up or down in minutes. この機能により、初期構成の選択によって縛り付けられることを心配する必要はなくなります。This capability frees you from concerns about being boxed in by your initial configuration choices.

ハイパースケール サービス レベルのコンピューティング サイズについて詳しくは、「サービス レベルの特性」をご覧ください。For more information about the compute sizes for the Hyperscale service tier, see Service tier characteristics.

Hyperscale サービス レベルを検討する必要があるユーザーWho should consider the Hyperscale service tier

Hyperscale サービス レベルの対象として主に意図されているのは、オンプレミスに大規模なデータベースを持っていて、クラウドに移行することによってアプリケーションを最新化することを考えているお客様、または既にクラウドを利用していて、データベースの最大サイズ (1 から 4 TB) によって制限されているお客様です。The Hyperscale service tier is primarily intended for customers who have large databases either on-premises and want to modernize their applications by moving to the cloud or for customers who are already in the cloud and are limited by the maximum database size restrictions (1-4 TB). また、ストレージとコンピューティングに対して高いパフォーマンスと高いスケーラビリティを必要としているお客様も対象になります。It is also intended for customers who seek high performance and high scalability for storage and compute.

Hyperscale サービス レベルはすべての SQL Server ワークロードをサポートしますが、主に OLTP 用に最適化されています。The Hyperscale service tier supports all SQL Server workloads, but it is primarily optimized for OLTP. Hyperscale サービス レベルは、ハイブリッド ワークロードと分析 (データ マート) ワークロードもサポートしています。The Hyperscale service tier also supports hybrid and analytical (data mart) workloads.

重要

エラスティック プールでは、Hyperscale サービス レベルはサポートされていません。Elastic pools do not support the Hyperscale service tier.

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

ハイパースケール サービス レベルは仮想コア モデルのみで提供されています。Hyperscale service tier is only available in vCore model. 新しいアーキテクチャに合わせて、価格モデルは General Purpose または Business Critical サービス モデルとは少し異なります。To align with the new architecture, the pricing model is slightly different from General Purpose or Business Critical service tiers:

  • コンピューティング:Compute:

    ハイパースケール コンピューティング ユニットの料金はレプリカ単位です。The Hyperscale compute unit price is per replica. Azure ハイブリッド特典の価格が読み取りスケール レプリカに自動的に適用されます。The Azure Hybrid Benefit price is applied to read scale replicas automatically. パブリック プレビューでは、ハイパースケール データベースごとに既定で 2 つのレプリカを作成します。In public preview, we create two replicas per Hyperscale database by default.

  • ストレージ:Storage:

    ハイパースケールのデータベースを構成するときに、最大データ サイズを指定する必要はありません。You don't need to specify the max data size when configuring a Hyperscale database. ハイパースケール レベルでは、実際の使用量に基づき、データベース用のストレージに料金が発生します。In the hyperscale tier, you are charged for storage for your database based on actual usage. ストレージは、5 GB から 100 TB までの範囲で、動的に 1 GB 単位で割り当てられます。Storage is dynamically allocated between 5 GB and 100 TB, in 1 GB increments.

ハイパースケールの価格について詳しくは、「Azure SQL Database の価格」をご覧ください。For more information about Hyperscale pricing, see Azure SQL Database Pricing

分散機能アーキテクチャDistributed functions architecture

1 つの場所/プロセスにすべてのデータ管理機能を集中させる従来のデータベース エンジンとは異なり (今日の運用環境で分散データベースと呼ばれているものでも、モノリシックなデータ エンジンの複数のコピーを使用しています)、Hyperscale データベースでは、さまざまなデータ エンジンのセマンティクスが分岐しているクエリ処理エンジンと、データの長期的なストレージと持続性を提供するコンポーネントが分かれています。Unlike traditional database engines that have centralized all of the data management functions in one location/process (even so called distributed databases in production today have multiple copies of a monolithic data engine), a Hyperscale database separates the query processing engine, where the semantics of various data engines diverge, from the components that provide long-term storage and durability for the data. これにより、ストレージ容量をスムーズに必要な限りスケールアウトできます (初期ターゲットは 100 TB)。In this way, the storage capacity can be smoothly scaled out as far as needed (initial target is 100 TB). 読み取り専用レプリカは同じコンピューティング コンポーネントを共有しているので、新しい読み取り可能レプリカを起動するためにデータのコピーは必要ありません。Read-only replicas share the same compute components so no data copy is required to spin up a new readable replica. プレビュー段階では 1 つの読み取り専用レプリカのみがサポートされます。During preview, only 1 read-only replica is supported.

次の図では、Hyperscale データベースでのノードのさまざまな種類を示します。The following diagram illustrates the different types of nodes in a Hyperscale database:

アーキテクチャ

Hyperscale データベースには、次の種類のノードが含まれます。A Hyperscale database contains the following different types of nodes:

コンピューティング ノードCompute node

コンピューティング ノードにはリレーショナル エンジンが存在するので、すべての言語要素、クエリ処理などがここで発生します。The compute node is where the relational engine lives, so all the language elements, query processing, and so on, occur. Hyperscale データベースとユーザーのすべてのやり取りは、これらのコンピューティング ノードを通して行われます。All user interactions with a Hyperscale database happen through these compute nodes. データのページをフェッチするために必要なネットワーク ラウンドトリップの数を最小限に抑えるため、コンピューティング ノードは SSD ベースのキャッシュ (前の図の RBPEX - 弾性バッファー プール拡張機能) を備えています。Compute nodes have SSD-based caches (labeled RBPEX - Resilient Buffer Pool Extension in the preceding diagram) to minimize the number of network round trips required to fetch a page of data. プライマリ コンピューティング ノードが 1 つあり、すべての読み書きワークロードとトランザクションがそこで処理されます。There is one primary compute node where all the read-write workloads and transactions are processed. 1 つ以上のセカンダリ コンピューティング ノードがあり、フェールオーバーのためのホット スタンバイ ノードとして、また (この機能が必要な場合は) 読み取りワークロードをオフロードするための読み取り専用コンピューティング ノードとして機能します。There are one or more secondary compute nodes that act as hot standby nodes for failover purposes, as well as act as read-only compute nodes for offloading read workloads (if this functionality is desired).

ページ サーバー ノードPage server node

ページ サーバーは、スケールアウトされたストレージ エンジンを表すシステムです。Page servers are systems representing a scaled-out storage engine. 各ページ サーバーは、データベース内のページのサブセットを受け持ちます。Each page server is responsible for a subset of the pages in the database. 通常、各ページ サーバーでは 1 テラバイトのデータが制御されます。Nominally, each page server controls 1 terabyte of data. 複数のページ サーバーでデータが共有されることはありません (冗長性と可用性のために保持されているレプリカの外部)。No data is shared on more than one page server (outside of replicas that are kept for redundancy and availability). ページ サーバーの役割は、必要に応じてコンピューティング ノードにデータベース ページを提供し、トランザクションでデータが更新されたらページを更新することです。The job of a page server is to serve database pages out to the compute nodes on demand, and to keep the pages updated as transactions update data. ページ サーバーは、ログ サービスからのログ レコードを再生することによって最新の状態に維持されます。Page servers are kept up-to-date by playing log records from the log service. また、ページ サーバーはパフォーマンスを強化するために SSD ベースのキャッシュも備えています。Page servers also maintain SSD-based caches to enhance performance. 信頼性向上のため、データ ページの長期的なストレージが Azure Storage に保持されます。Long-term storage of data pages is kept in Azure Storage for additional reliability.

ログ サービス ノードLog service node

ログ サービス ノードは、プライマリ コンピューティング ノードからログ レコードを受け取り、持続性キャッシュにそれを保持し、他のコンピューティング ノード (キャッシュを更新できるように) および関連するページ サーバーにログ レコードを転送して、それらの場所でデータを更新できるようにします。The log service node accepts log records from the primary compute node, persists them in a durable cache, and forwards the log records to the rest of the compute nodes (so they can update their caches) as well as the relevant page server(s), so that the data can be updated there. このようにして、プライマリ コンピューティング ノードからのすべてのデータ変更が、ログ サービスを介して、すべてのセカンダリ コンピューティング ノードとページ サーバーに伝達されます。In this way, all data changes from the primary compute node are propagated through the log service to all the secondary compute nodes and page servers. 最後に、ログ レコードは、無期限のストレージ リポジトリである Azure Storage の長期ストレージにプッシュされます。Finally, the log record(s) are pushed out to long-term storage in Azure Storage, which is an infinite storage repository. このメカニズムにより、頻繁にログを切り捨てる必要がなくなります。This mechanism removes the necessity for frequent log truncation. また、ログ サービスはアクセスを高速化するためのローカル キャッシュも備えています。The log service also has local cache to speed up access.

Azure Storage ノードAzure storage node

Azure Storage ノードは、ページ サーバーからのデータの最終的な送り先です。The Azure storage node is the final destination of data from page servers. このストレージは、バックアップ目的だけでなく、Azure リージョン間のレプリケーションにも使用されます。This storage is used for backup purposes as well as for replication between Azure regions. バックアップは、データ ファイルのスナップショットで構成されます。Backups consist of snapshots of data files. 復元操作はこれらのスナップショットから行われるため高速であり、任意の時点にデータを復元できます。Restore operation are fast from these snapshots and data can be restored to any point in time.

バックアップと復元Backup and restore

バックアップはファイル スナップショット ベースなので、ほぼ瞬時に実行されます。Backups are file-snapshot base and hence they are nearly instantaneous. ストレージとコンピューティングの分離により、バックアップ/復元操作をストレージ層に移すことができるので、プライマリ コンピューティング ノードの処理の負荷が軽減されます。Storage and compute separation enable pushing down the backup/restore operation to the storage layer to reduce the processing burden on the primary compute node. その結果、大規模なデータベースのバックアップでも、プライマリ コンピューティング ノードのパフォーマンスには影響ありません。As a result, the backup of a large database does not impact the performance of the primary compute node. 同様に、復元はファイル スナップショットのコピーによって行われ、データ操作のサイズではありません。Similarly, restores are done by copying the file snapshot and as such are not a size of data operation. 同じストレージ アカウント内の復元の場合、復元操作は高速です。For restores within the same storage account, the restore operation is fast.

スケールとパフォーマンスの利点Scale and performance advantages

追加の読み取り専用コンピューティング ノードを迅速に起動/停止できるので、Hyperscale アーキテクチャでは、読み取りのスケーリング機能が優れ、より多くの書き込み要求に対応できるようにプライマリ コンピューティング ノードを解放することもできます。With the ability to rapidly spin up/down additional read-only compute nodes, the Hyperscale architecture allows significant read scale capabilities and can also free up the primary compute node for serving more write requests. また、Hyperscale アーキテクチャの共有ストレージ アーキテクチャのため、コンピューティング ノードをすばやくスケールアップ/スケールダウンできます。Also, the compute nodes can be scaled up/down rapidly due to the shared-storage architecture of the Hyperscale architecture.

ハイパースケール データベースの作成Create a HyperScale database

ハイパースケール データベースは、Azure portalT-SQLPowershell、または CLI を使用して作成できます。A HyperScale database can be created using the Azure portal, T-SQL, Powershell or CLI. ハイパースケール データベースは、仮想コアベースの購入モデルのみを使用して入手できます。HyperScale databases are available only using the vCore-based purchasing model.

次の T-SQL コマンドによって、ハイパースケール データベースが作成されます。The following T-SQL command creates a Hyperscale database. CREATE DATABASE ステートメントにエディションとサービス目標の両方を指定する必要があります。You must specify both the edition and service objective in the CREATE DATABASE statement.

-- Create a HyperScale Database
CREATE DATABASE [HyperScaleDB1] (EDITION = 'HyperScale', SERVICE_OBJECTIVE = 'HS_Gen4_4');
GO

既存の Azure SQL Database のハイパースケール サービス レベルへの移行Migrate an existing Azure SQL Database to the Hyperscale service tier

既存の Azure SQL Database をハイパースケールに移行するには、Azure portalT-SQLPowershell、または CLI を使用します。You can move your existing Azure SQL databases to Hyperscale using the Azure portal, T-SQL, Powershell or CLI. パブリック プレビューでは一方向にしか移行できません。In public preview, this is a one-way migration. ハイパースケールから他のサービス レベルにデータベースを移行することはできません。You can’t move databases from Hyperscale to another service tier. 運用データベースのコピーを作成して、概念実証 (POC) のためにハイパースケールに移行することをお勧めします。We recommend you make a copy of your production databases and migrate to Hyperscale for proof of concepts (POCs).

次の T-SQL コマンドによってデータベースがハイパースケール サービス レベルに移行されます。The following T-SQL command moves a database into the Hyperscale service tier. ALTER DATABASE ステートメントにエディションとサービス目標の両方を指定する必要があります。You must specify both the edition and service objective in the ALTER DATABASE statement.

-- Alter a database to make it a HyperScale Database
ALTER DATABASE [DB2] MODIFY (EDITION = 'HyperScale', SERVICE_OBJECTIVE = 'HS_Gen4_4');
GO

重要

ハイパースケール以外のデータベースをハイパースケールに変更する前に、Transparent Database Encryption (TDE) をオフにする必要があります。Transparent Database Encryption (TDE) should be turned off before altering a non-Hyperscale database to HyperScale.

ハイパースケール データベースの読み取りスケールへの接続Connect to a read-scale replica of a Hyperscale database

ハイパースケール データベースでは、クライアントによって提供された接続文字列の ApplicationIntent 引数により、接続が書き込みレプリカと読み取り専用セカンダリ レプリカのどちらにルーティングされるかが指定されます。In HyperScale databases, the ApplicationIntent argument in the connection string provided by the client dictates whether the connection is routed to the write replica or to a read-only secondary replica. ApplicationIntentREADONLY に設定され、データベースにセカンダリ レプリカがない場合、接続はプライマリ レプリカにルーティングされ、既定で ReadWrite の動作になります。If the ApplicationIntent set to READONLY and the database does not have a secondary replica, connection will be routed to the primary replica and defaults to ReadWrite behavior.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

対応リージョンAvailable regions

ハイパースケール サービス レベルは現在パブリック プレビュー段階であり、次の Azure リージョンで使用できます。EastUS1、EastUS2、WestUS2、CentralUS、NorthCentralUS、WestEurope、NorthEurope、UKWest、AustraliaEast、AustraliaSouthEast、SouthEastAsia、JapanEast、KoreaCentralHyperscale service tier is currently in public preview and available in following Azure regions: EastUS1, EastUS2, WestUS2, CentralUS, NorthCentralUS, WestEurope, NorthEurope, UKWest, AustraliaEast, AustraliaSouthEast, SouthEastAsia, JapanEast, KoreaCentral

既知の制限事項Known limitations

問題Issue 説明Description
[バックアップの管理] ウィンドウに、ハイパースケール データベースが表示されません。"SQL server" でフィルター処理すると表示されます。The Manage Backups pane for a logical server does not show Hyperscale databases will be filtered from SQL server-> ハイパースケールは別の方法でバックアップを管理しています。そのため、長期的な保有期間と特定の時点のバックアップなどの保有設定が適用されず、無効になります。Hyperscale has a separate method for managing backups, and as such the Long Term Retention and Point in Time backup Retention settings do not apply / are invalidated. したがって、ハイパースケールのデータベースは、[バックアップの管理] ウィンドウに表示されません。Accordingly, Hyperscale databases do not appear in the Manage Backup pane.
ポイントインタイム リストアPoint-in-time restore データベースがハイパースケール サービス レベルに移行された後で、移行よりも前の特定の時点への復元はサポートされません。Once a database is migrated into the Hyperscale service tier, restore to a point-in-tIme prior to the migration is not supported.
データベース ファイルが移行時にアクティブなワークロードのために大きくなり、ファイル境界が 1 TB を超えると、移行が失敗するIf a database file grows during migration due to an active workload and crosses the 1 TB per file boundary, the migration fails 軽減策:Mitigations:
- 可能であれば、更新ワークロードが実行されていないときに、データベースを移行します。- If possible, migrate the database when there is no update workload running.
- 移行を再試行します。移行時に 1 TB の境界を越えない限り、成功します。- Re-try the migration, it will succeed as long as the 1 TB boundary is not crossed during the migration.
マネージド インスタンスが現在サポートされないManaged Instance is not currently supported 現在、サポートされていませんNot currently supported
ハイパースケールへの移行は現在一方向Migration to Hyperscale is currently a one-way operation データベースがハイパースケールにいったん移行されると、ハイパースケール以外のサービス レベルに直接移行することはできません。Once a database is migrated to Hyperscale, it cannot be migrated directly to a non-Hyperscale service tier. 現時点では、ハイパースケールからハイパースケール以外にデータベースを移行するには、BACPAC ファイルを使用してエクスポート/インポートするしかありません。At present, the only way to migrate a database from Hyperscale to non-Hyperscale is to export/import using a BACPAC file.
メモリ内オブジェクトを含むデータベースの移行が現在サポートされないMigration of databases with in-memory objects is not currently supported データベースがハイパースケール サービス レベルに移行される前に、メモリ内オブジェクトは削除され、メモリ内ではないオブジェクトとして再作成されます。In-Memory objects must be dropped and recreated as non-In-Memory objects before migrating a database to the Hyperscale service tier.

次の手順Next steps