Hyperscale の分散機能のアーキテクチャ

  • [アーティクル]

適用対象:Azure SQL Database

Hyperscale サービス レベルでは、拡張性の高い別のストレージとコンピューティング レベルを備えたアーキテクチャが利用されます。 この記事では、お客様がほぼ瞬時のバックアップと非常にスケーラブルなトランザクション ログのメリットを活用しながら、Hyperscale データベースをすばやくスケーリングできるようにするコンポーネントについて説明します。

ヒント

SQL Database Hyperscale の簡略化された価格は近日公開予定です。 詳細については、Hyperscale の価格に関するブログを参照してください。

Hyperscale のアーキテクチャの概要

従来のデータベース エンジンでは、データ管理機能が 1 つのプロセスに一元化されています。今日の運用環境でディストリビューション データベースと呼ばれているものでも、モノリシックなデータ エンジンの複数のコピーが使用されています。

Hyperscale データベースのアプローチは異なります。 Hyperscale では、さまざまなデータ エンジンのセマンティクスが枝分かれしているクエリ処理エンジンと、データの長期的なストレージと持続性を提供するコンポーネントが分かれています。 これにより、ストレージ容量をスムーズに必要なだけスケールアウトできます。 最初にサポートされるストレージの制限は 100 TB です。

Hyperscale コンポーネント間のすべてのネットワーク通信では、冗長性が組み込まれた Azure ネットワーク インフラストラクチャが使用されます。

高可用性セカンダリ レプリカと名前付きレプリカは、オンデマンドで追加できるオプションの計算ノードです。 どちらも同じストレージ コンポーネントを共有しているので、新しいレプリカを起動するためにデータのコピーは必要ありません。 同じ Azure リージョンまたは別の Azure リージョンに、オンデマンドで geo セカンダリ レプリカを追加できます。 データ保護と冗長性のために、geo セカンダリ レプリカには、プライマリ レプリカで使用されるものとは別のストレージ コンポーネントが備わっています。

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

Diagram showing Hyperscale's compute tier.

Hyperscale データベースには、コンピューティング ノード、ページ サーバー、ログ サービス、Azure Storage の各コンポーネントの種類が含まれています。

Compute

コンピューティング ノードは、リレーショナル エンジンが存在する場所です。 コンピューティング ノードでは、言語、クエリ、トランザクションの処理が行われます。 Hyperscale データベースとユーザーのすべてのやり取りは、コンピューティング ノードを通して行われます。 コンピューティング ノードは、サーバーレスまたはプロビジョニング コンピューティングを使うように構成できます。

計算ノードには、弾性バッファー プール拡張機能 (RBPEX データ キャッシュ) と呼ばれる SSD ベースのキャッシュがあります。 RBPEX データ キャッシュは、リモート ページ サーバーからデータをフェッチする必要性を最小限に抑えるインテリジェントな低遅延の短いデータ キャッシュです。

Hyperscale データベースには、読み取り/書き込みワークロードとトランザクションが処理されるプライマリ コンピューティング ノードが 1 つあります。 最大 4 つの高可用性セカンダリ計算ノードをオンデマンドで追加できます。 それらはフェールオーバー用のホット スタンバイ ノードとして機能し、必要に応じて、読み取りワークロードをオフロードするための読み取り専用計算ノードとして使用できます。 名前付きレプリカは、さまざまな追加 OLTP 読み取りスケールアウト シナリオを可能にし、Hybrid Transactional and Analytical Processing (HTAP) ワークロードのサポートを強化するように設計されているセカンダリ計算ノードです。 geo セカンダリ計算ノードをディザスター リカバリー用に追加し、別の Azure リージョンの読み取りワークロードをオフロードするための読み取り専用計算ノードとして使用することができます。

サーバーレスの場合、プライマリ レプリカと任意の高可用性レプリカまたは名前付きレプリカが、使用状況に応じて、それぞれ独立して自動スケーリングされます。 プライマリ レプリカと任意の名前付きレプリカのコンピューティングの自動スケーリング範囲は、独立して構成されます。 高可用性レプリカの自動スケーリング範囲は、関連付けられたプライマリ レプリカまたは名前付きレプリカで指定された自動スケーリング構成から継承されます。

ハイパースケール コンピューティング ノード上で実行されるデータベース エンジンは、他の Azure SQL Database サービス レベルと同じです。 ユーザーがハイパースケール コンピューティング ノード上のデータベース エンジンを操作する場合、サポートされる外部からのアクセスとエンジンの動作は、既知の制限事項を除き、他のサービス レベルと同じです。

ページ サーバー

ページ サーバーは、スケールアウトされたストレージ エンジンを表すシステムです。 各ページ サーバーは、データベース内のページのサブセットを受け持ちます。 各ページ サーバーにも、冗長性と可用性のために保持されるレプリカがあります。

ページ サーバーの役割は、必要に応じてコンピューティング ノードにデータベース ページを提供し、トランザクションでデータが更新されたらページを更新することです。 ページ サーバーは、ログ サービスからのトランザクション ログ レコードを再生することによって最新の状態に維持されます。

また、パフォーマンスを強化するために、ページ サーバーによっては SSD ベースのキャッシュへの対応も維持されます。 持続性のため、データ ページの長期的なストレージが Azure Storage に保持されます。

ログ サービス

ログ サービスは、プライマリ コンピューティング レプリカから、データ変更に対応するトランザクション ログ レコードを受け取ります。 その後、ページ サーバーはログ サービスからログ レコードを受け取り、それぞれのデータ スライスに変更を適用します。 さらに、コンピューティング セカンダリ レプリカはログ サービスからログ レコードを受け取り、バッファー プールまたはローカル RBPEX キャッシュに既に存在するページへの変更のみを再生します。 プライマリ コンピューティング レプリカからのすべてのデータ変更は、ログ サービスを介して、すべてのセカンダリ コンピューティング レプリカとページ サーバーに伝達されます。

最後に、トランザクション ログ レコードは、実質的に無制限のストレージ リポジトリである Azure Storage の長期ストレージにプッシュされます。 このメカニズムにより、頻繁にログを切り捨てる必要がなくなります。 ログ バックアップの欠落、セカンダリ レプリカへの低速なデータ レプリケーションなど、ログが増加する一般的な理由は、Hyperscale には適用されません。 ログ サービスは、ログ レコードへのアクセスを高速化するためのローカル メモリと SSD キャッシュを備えています。

Azure Storage

Azure Storage には、データベース内のすべてのデータ ファイルが格納されています。 ページ サーバーは Azure Storage 内のデータ ファイルを最新の状態に保ちます。 このストレージはバックアップのためにも使われ、ストレージ冗長性の選択に基づいてリージョン間でレプリケートされる場合があります。

バックアップはデータ ファイルのストレージ スナップショットを使用して実行されます。 スナップショットを使用した復元操作は、データ サイズに関係なく高速です。 データベースは、バックアップ保有期間内の任意の時点に復元できます。

Hyperscale では、ストレージの冗長性を構成できます。 Hyperscale データベースを作成する場合、以下の種類の Azure Standard Storage から選択できます。

  • ローカル冗長ストレージ (LRS)
  • ゾーン冗長ストレージ (ZRS)
  • 読み取りアクセス geo 冗長ストレージ (RA-GRS)
  • 読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS)

ゾーン冗長ストレージ オプションは、可用性ゾーンがある Azure リージョンで使用できます。

選択したストレージ冗長オプションは、データベースの有効期間中、データ ストレージの冗長性とバックアップ ストレージの冗長性の両方に使われます。

関連するコンテンツ