Azure SQL Database Hyperscale

解決する課題

数TB〜128TB級の大容量データベースを1インスタンスで扱いたい
データ量が増えてもバックアップ/復元を高速に保ちたい
読み取り負荷をレプリカで手軽にスケールしたい
ストレージと計算を独立して伸縮させ、過剰プロビジョニングを避けたい

主要概念と用語

計算ノード（プライマリレプリカ）: クエリを処理する SQL Server エンジン。書き込みを受け付ける
セカンダリレプリカ（HA / 名前付き / geo）: 読み取りスケール・フェイルオーバー先。名前付きレプリカは最大30まで追加可能
ページサーバー: データベースのページ（データ本体）を分散保持・キャッシュするスケールアウト層
ログサービス: トランザクションログを一元的に受け取り、ページサーバーとレプリカへ配布する書き込みの要
Azure Standard ストレージ: 長期のページ保持とバックアップを担う耐久ストレージ層
プロビジョニング済み / サーバーレス: 固定 vCore か、負荷に応じ自動スケール（一時停止対応）の課金モデル

仕様・制限・クォータ

データベース最大サイズは最大128TB。ストレージはオンデマンドで自動拡張（事前確保不要）
バックアップはストレージスナップショットベースでほぼ瞬時、復元もサイズに依存せず高速
名前付きレプリカは最大30。プライマリと各名前付きレプリカには、必要に応じて HA レプリカを構成できる
単一データベースおよびエラスティックプールで利用可能。vCore 購入モデル専用（DTU モデル非対応）
バックアップ保有は短期（PITR、最大35日）＋長期保有（LTR）。Hyperscale はデータベースのコピー/シュリンクなど一部操作に固有の制約あり

内部の仕組み

Hyperscale は、従来の単一ファイル型データベースを多層アーキテクチャに再構成しています。計算ノードはローカルSSD（RBPEX：Resilient Buffer Pool Extension）を高速キャッシュとして使い、データ本体はページサーバー群に分散保持されます。書き込みはログサービスが一元受信し、そこから各ページサーバーと読み取りレプリカへ反映されます。バックアップはストレージのスナップショットで取得するため、データ量が増えても所要時間がほぼ一定です。サーバーレスは需要に応じて vCore を自動増減し、アイドル時は一時停止できます。

書き込みは単一のプライマリ計算ノードからログサービスへ送られ、ページサーバーと各計算レプリカへ配布されます。データページは耐久ストレージに保持されるため、計算ノードの追加やサイズ変更でデータ全体をコピーする必要がありません。

標準的な汎用/ビジネスクリティカルとの違い

汎用/ビジネスクリティカルは1つのデータベースファイルを前提とするのに対し、Hyperscale はログサービス＋ページサーバーでストレージを分離・分散。だから100TB級でもバックアップと拡張が速く、読み取りレプリカを増やしやすい。

設計パターン / ベストプラクティス

読み取り中心の負荷は名前付きレプリカを用途別に追加し、ApplicationIntent=ReadOnly で振り分ける
高可用性が必要ならHA セカンダリレプリカを構成（ゾーン冗長対応）
変動が大きいワークロードはサーバーレスで自動スケール＋自動一時停止
DR/低遅延の地理分散読み取りはgeo レプリカ（アクティブ geo レプリケーション）

運用・監視・トラブルシュート

Query Performance Insight / Query Store でクエリ単位のボトルネックを可視化
ログ生成レートやレプリカの遅延、計算リソースを Azure Monitor で監視
フェイルオーバーはマネージドで自動。接続はサーバー名経由（読み取りは読み取り専用エンドポイントへ）
大容量でも**ポイントインタイム復元（PITR）**が高速に行える

コスト

課金は「計算（vCore）」「使用したストレージ」「バックアップストレージ」「追加レプリカ」の合算です。

課金要素	課金の考え方	最適化のヒント
計算（プロビジョニング済み）	選んだ vCore × 時間（固定）	定常負荷の本番に。予約容量で割引
計算（サーバーレス）	使用 vCore を秒単位（自動一時停止可）	間欠/開発検証ワークロードに有効
ストレージ	実際に使用した容量に対して従量	事前確保不要。使った分だけ支払い
バックアップストレージ	スナップショット使用量＋LTR保有分	保有期間を要件に合わせて短縮
追加レプリカ	レプリカごとの vCore 課金	読み取り需要に応じて増減

セキュリティ

保存データは TDE（透過的データ暗号化） で暗号化。鍵は Key Vault（BYOK / マネージドHSM） で管理可能
Microsoft Entra 認証で接続を一元化し、SQL 認証のパスワード管理を排除
プライベートエンドポイント / VNet 配置とファイアウォール規則でネットワークを最小公開に
アプリの資格情報はマネージド ID で取得し、接続文字列へのハードコードを避ける

アンチパターン

管理者アカウントの SQL 認証パスワードを接続文字列やコードに直書きするのは NG。Microsoft Entra 認証＋マネージド ID を使えば、キーの管理・漏洩リスクを排除できます。

観点	Azure SQL Database Hyperscale	Amazon Aurora
位置づけ	Azure SQL の高スケールサービスレベル	AWS のクラウドネイティブRDB
互換エンジン	SQL Server（T-SQL）	MySQL / PostgreSQL 互換
ストレージ構造	ログサービス＋ページサーバーで分離	計算とストレージを分離（6コピー）
最大容量	最大128TB	最大128TB級
読み取りレプリカ	最大30（HA/名前付き/geo）	最大15
自動スケール課金	サーバーレス（vCore自動増減）	Aurora Serverless v2（ACU）
多リージョン	アクティブ geo レプリケーション	Aurora Global Database

ハンズオン / CLI例

# リソースグループと論理サーバーを作成
az group create --name demo-rg --location japaneast

az sql server create \
  --resource-group demo-rg \
  --name demo-sqlsrv-0603 \
  --admin-user sqladmin \
  --admin-password 'P@ssw0rd-Change-Me!'

# Hyperscale データベースを作成（Gen5 / 2 vCore / HA レプリカ1）
az sql db create \
  --resource-group demo-rg \
  --server demo-sqlsrv-0603 \
  --name appdb \
  --edition Hyperscale \
  --family Gen5 \
  --capacity 2 \
  --ha-replicas 1

# 読み取りスケール用に HA レプリカ数を変更
az sql db update \
  --resource-group demo-rg \
  --server demo-sqlsrv-0603 \
  --name appdb \
  --ha-replicas 2