MENU

Azure SQL Database HyperscaleサーバーレスからGeneral Purposeへ安全にダウングレードする方法と注意点

Azure

Azure SQL Database の Hyperscale サーバーレスは柔軟でスケーラブルですが、「やっぱりコストを抑えたい」「機能要件的に General Purpose で十分だった」と後から気付くことも少なくありません。本記事では、Hyperscale サーバーレスにしてしまったデータベースを、どこまで・どうやって他のサービス レベルへ戻せるのかを、公式ドキュメントの要点と実務的なノウハウを交えて整理します。

Azure SQL Database Hyperscale サーバーレスからのダウングレード戦略まとめ

目次

Hyperscale サーバーレスから別ティアへ戻せるかの「結論」

最初に結論を整理しておきます。

  • 既存の Azure SQL Database を Hyperscale に移行してから 45 日以内であれば、Azure が提供する「逆移行 (Reverse migration) 機能」で General Purpose へ戻せる（サーバーレス／プロビジョンドのどちらも選択可）。
  • 45 日を過ぎている、または最初から Hyperscale で作成したデータベースの場合、ポータルや CLI で別ティアへ直接変更することはできない。
  • その場合に取り得る代表的な方法は、BACPAC などを使った「新規 DB へのデータ移行」のみ（あるいは Azure Data Factory / bcp / DMS など別のデータ移行手段）。

ざっくり言えば、「移行して 45 日以内」だけが Azure 標準機能での“ダウングレード”が許される特別期間であり、それを過ぎたら通常のデータ移行プロジェクトとして扱う必要があります。

ケース別：Hyperscale サーバーレスからの移行パターン早見表

現在の状況別ティアへの移行可否主な方法ダウンタイムポイント
General Purpose などから Hyperscale に変換
かつ変換から 45 日以内		可
Hyperscale → General Purpose		Azure の逆移行機能（ポータル / CLI / PowerShell / T-SQL）最終カットオーバー時に
数分程度の停止が発生（目安）		サイズ依存の「データ移動」扱い。
通常の SLO 変更より時間がかかる。
General Purpose から Hyperscale へ変換後
45 日を超過		直接の逆移行は不可BACPAC / Data Factory / bcp / DMS などで
新規 General Purpose にデータ移行		切替時に停止が必要。
方式により停止時間の短縮は可能。		事実上「通常の移行プロジェクト」。
テスト環境で所要時間の事前計測を推奨。
最初から Hyperscale（サーバーレス含む）で新規作成直接の逆移行は不可同上：BACPAC や各種データ移行ツールで
別ティアへ移行		同上仕様上、他ティアへの直接移行対象外。
設計段階から要検討。
Hyperscale サーバーレスのまま
vCore や最大サイズのみ調整したい		可
Hyperscale 内でのスケール変更		通常のスケール設定変更数秒〜数分の接続エラー・遅延の可能性本記事で言う「ダウングレード」とは別枠。
コスト調整目的ならまずここを検討。

Hyperscale サーバーレスと General Purpose の位置付けを整理する

まずは前提として、Azure SQL Database のサービス モデルを簡単におさらいします。

  • Hyperscale：分離ストレージ アーキテクチャにより、数 TB〜数十 TB 規模のデータや高いスループットを前提としたサービス ティア。
  • General Purpose：多くの業務システムで「ちょうどよい」性能・コストバランスを持つ標準的なティア。
  • Business Critical：超低レイテンシや高い I/O 性能、SLA を求めるシナリオ向け。

Hyperscale と General Purpose は「同じ vCore ベースモデルの別ティア」であり、Hyperscale サーバーレスはあくまで Hyperscale の コンピュート モデル（課金形態）の選択肢です。逆移行の可否は、「Hyperscale かどうか」「いつ変換したか」で決まり、サーバーレスであるかどうか自体は条件を大きく変えません。

45 日以内だけ使える「逆移行 (Reverse migration)」の仕組み

逆移行は、Azure SQL Database が提供する公式機能で、既存データベースを Hyperscale に変換してから 45 日以内であれば、Hyperscale から General Purpose に“巻き戻し”できる仕組みです。

逆移行ができる条件チェックリスト

以下の条件をすべて満たす必要があります。

  • もともと 別ティア (例: General Purpose) で作成した DB を Hyperscale に変換したものであること（最初から Hyperscale で作成した DB は対象外）。
  • Hyperscale への変換から 45 日以内であること。
  • 移行先は General Purpose ティアのみ（その後で Business Critical や DTU モデルに変更することは可能）。
  • 移行先 General Purpose の vCore は 2 vCores 以上（逆移行完了後に 1 vCore へスケールダウンは可）。
  • Elastic pool 間の直接逆移行は不可。Hyperscale 単体 DB → General Purpose 単体 DBにのみ対応。
  • Hyperscale Elastic pool に所属している場合は、事前にプールから外して単体 DB にしておく必要がある。
  • Geo レプリケーションが有効な DB、Named Replicas を持つ DB は対象外（事前に無効化が必要）。
  • DB の割り当てサイズが、移行先 General Purpose ティアの上限に収まっていること。

これらは逆移行開始前に Azure 側でチェックされるため、満たしていない場合は操作が即座に失敗します。

逆移行の所要時間とダウンタイムのイメージ

逆移行は、通常の「サービス レベルの変更」とは異なり、内部的にはアーキテクチャの異なるストレージへの“サイズ依存のデータコピー（Size-of-data operation）”として扱われます。

  • 所要時間は主に以下で決まる：
    • データベースサイズ（GB / TB）
    • 逆移行中の書き込み負荷（トランザクション ログの生成速度）
    • 移行先 General Purpose で割り当てる vCore 数
  • 処理中、Hyperscale 側のトランザクション ログ書き込みはスロットリングされる場合があり、更新負荷が高いシステムでは一時的な性能劣化が発生し得ます。
  • 最終カットオーバー時には、数分程度の停止（接続エラー）が発生するのが一般的とされています。

そのため、実務上は次のような運用が現実的です。

  • 夜間・バッチ後など書き込みが少ない時間帯に実施する。
  • 移行先 General Purpose の vCore 数を一時的に多めに確保し、処理時間を短縮する（完了後にスケールダウン）。
  • アプリケーションの接続リトライ・タイムアウト値を一時的に緩めておく。

逆移行の実行ステップ（概要）

Azure ポータルから行う場合

  1. Azure ポータルで対象の Hyperscale DB を開く。
  2. 左メニューの [Compute + storage] を開く。
  3. [Service tier] ドロップダウンから General Purpose を選択。
  4. 必要に応じて [Change configuration] で HW 構成を選択し、vCore 数を調整。
  5. サーバーレスにしたい場合は、Compute model として Serverless を選択。
  6. [Apply] を押下し、[Overview] 画面の通知や [Ongoing operations] で進行状況をモニタリング。

Azure CLI の例

CLI を使って逆移行する場合のイメージは次の通りです。

resourceGroupName="myResourceGroup"
serverName="myserver"
databaseName="myHyperscaleDb"
serviceObjective="GP_Gen5_2"   # 例: General Purpose の 2 vCore
computeModel="Serverless"      # or "Provisioned"

az sql db update \
  -g $resourceGroupName \
  -s $serverName \
  -n $databaseName \
  --edition GeneralPurpose \
  --service-objective $serviceObjective \
  --compute-model $computeModel

進行状況は次のように確認できます。

az sql db op list \
  -g $resourceGroupName \
  -s $serverName \
  -n $databaseName

T-SQL の例

T-SQL でも同様に、ALTER DATABASE ... MODIFY で逆移行をトリガーできます。

ALTER DATABASE [myHyperscaleDb]
  MODIFY (EDITION = 'GeneralPurpose',
          SERVICE_OBJECTIVE = 'GP_Gen5_2',
          MAXSIZE = 200 GB);
GO

この操作も内部的には「サイズ依存のデータ移行」であり、完了までに時間がかかる点はポータル／CLI と同様です。

逆移行できない場合：BACPAC などを使った手動移行

次のいずれかに該当する場合、逆移行機能は使えません。

  • Hyperscale への変換から 45 日を超過している。
  • データベースが最初から Hyperscale（サーバーレス含む）で作成されている。
  • Geo レプリケーション／Named replica／Elastic pool などの条件を満たせない。

この場合、マイクロソフトのドキュメントでも、「BACPAC ファイルのエクスポート／インポート、もしくはその他のデータ移行技術が唯一の方法」と明記されています。

Hyperscale からの BACPAC エクスポートの注意点

Hyperscale の場合、以下の制約があります。

  • Hyperscale DB の BACPAC エクスポート／インポートは、
    • Azure ポータル
    • Azure CLI (az sql db export / import)
    • PowerShell (New-AzSqlDatabaseExport / Import)
    • REST API
    からはサポートされていません。
  • 代わりに、SSMS または SqlPackage (DacFx) からのエクスポート／インポートが必要です。
  • Hyperscale の BACPAC エクスポートは おおむね 150 GB 程度までが現実的 とされ、それ以上では時間が非常に長くなったり失敗しやすくなったりします。

さらに、一般的な BACPAC エクスポートには次のような制約がある点にも注意が必要です。

  • Azure Blob Storage にエクスポートする場合、1 ファイルの上限は 200 GB。
  • エクスポートが 20 時間を超えると失敗する場合がある。
  • Export 先マシンのローカルディスク容量に左右され、必要に応じて SqlPackage をローカル実行する必要がある。
  • BACPAC はバックアップ用途ではなく、「スキーマ + データ」の移行用フォーマットである。

BACPAC 方式のメリットとデメリット

メリットデメリット / リスク
単一ファイルでスキーマとデータをまとめて移行できる。 オンプレミス SQL Server などへの移行にも流用できる。 移行先が General Purpose / Business Critical / SQL Server など柔軟。DB サイズが大きいと現実的ではない（時間・失敗リスク）。 エクスポート／インポート中は書き込み停止が望ましく、ダウンタイムが長くなりがち。 サーバー ログイン、ジョブ、監査設定、Firewall 設定などは別途再構成が必要。 新しいデータ型（例: VECTOR 型など）が BACPAC 非対応でエラーになるケースもある。

BACPAC を使った標準的な移行手順

逆移行が使えない場合の、典型的な手順は次の通りです。

  1. 事前確認
    • DB の互換性レベル、機能依存（In-Memory OLTP / 一部の暗号化 / 新しいデータ型など）を確認。
    • テーブルに適切なクラスター化インデックスがあるか確認（ないとエクスポート時間が極端に長くなり失敗しやすい）。
  2. Hyperscale DB から BACPAC エクスポート
    • SSMS の「エクスポート データ層アプリケーション」ウィザードを利用する、または
    • SqlPackage コマンドを使用する（例）：
    SqlPackage /a:Export /tf:MyDb.bacpac ^ /scs:"Server=tcp:myserver.database.windows.net;Database=MyDb;User ID=xxx;Password=***;"
  3. 移行先で新規 General Purpose DB を作成
    • ターゲットは General Purpose（サーバーレス／プロビジョンドは要件に応じて選択）。
    • Max size や vCore 数は、データサイズと性能要件に合わせて余裕を持たせる。
  4. BACPAC をインポート
    • SSMS や SqlPackage を用いて、BACPAC から新規 DB にインポート。
    • インポート完了後、行数チェックや一部ビジネスロジックの検証を実施。
  5. 各種設定の再構成
    • ログインとユーザーのマッピング（sp_help_revlogin 等の活用）。
    • Firewall、接続ポリシー、TLS 設定。
    • 監査、アラート、Azure Monitor / Log Analytics 連携。
    • 自動ジョブ（Azure Automation / Elastic Jobs / Logic Apps 等）。
  6. アプリ切替と最終差分反映
    • 本番停止を行い、最終差分データを取り込み（必要なら差分同期用のスクリプトや CDC を活用）。
    • アプリケーションの接続文字列を新 DB に切り替え、動作確認。
  7. 旧 Hyperscale DB のクリーンアップ
    • バックアップ／監査要件を満たしていることを確認したうえで削除。
    • 合わせて不要となったリソース（Monitoring / Automation など）も整理。

BACPAC が難しいサイズの場合の代替案

数百 GB〜数 TB の Hyperscale からの脱出では、BACPAC 単体では現実的でないことが多くなります。その場合は、次のような選択肢を組み合わせることが多いです。

  • Azure Data Factory / Synapse Pipeline でテーブル単位にコピー（並列化しつつダウンタイムを抑制）。
  • bcp / Bulk Copy によるテキスト／ネイティブ形式のエクスポート＆インポート。
  • Azure Database Migration Service (DMS) を利用したオンライン／オフライン移行。
  • 巨大テーブルだけ個別手段で移し、残りを BACPAC で移行する「ハイブリッド構成」。

いずれの方法も、「最初に読み取り専用で検証 → 最後に短時間の停止で差分を反映」という 2 段階移行にすることで、ダウンタイムを短縮できます。

所要時間とシームレス性をどう評価するか

逆移行（45 日以内）の場合

逆移行は Azure サービス側で完結するとはいえ、「一瞬で切り替わるマジック」ではなく、次のような性質を持つことを前提に計画を組む必要があります。

  • バックグラウンドで Hyperscale → General Purpose へのデータコピーが走る。
  • その間、Hyperscale DB は基本的に利用可能だが、更新性能の低下やレイテンシ増大が起こり得る。
  • 最後のカットオーバー時点で、数分程度の停止が発生する。

実運用では、以下のような工夫が考えられます。

  • バッチ処理が少ない曜日・時間帯に実行。
  • 移行中に行うオンライン メンテナンス（インデックス再構築 etc.）は避ける。
  • アプリ側で再試行ロジック（Connection Retry / Circuit Breaker）を有効にしておく。

BACPAC・手動移行の場合

BACPAC では、スキーマ＋データを丸ごとコピーする必要があり、以下の要素が時間と成功率を左右します。

  • データベース サイズ（単純にサイズが大きいほど長時間化）。
  • 使用しているデータ型・インデックス設計（非クラスタ化テーブルだとテーブルスキャンで時間がかかる）。
  • 利用するマシンの CPU / メモリ / ディスク I/O 性能。
  • ネットワーク帯域（オンプレへのエクスポートの場合）。

「BACPAC は 1 回で終わらせよう」とせず、以下のような方針を取ると安全です。

  • まずは代表的な数十 GB のテスト DB で フルサイクル（エクスポート → インポート → 検証）を試す。
  • 本番と同等サイズのテストコピーが作れるなら、それで所要時間を見積もる。
  • 時間が厳しいようであれば、テーブル単位のコピーや増分同期方式への切り替えを検討する。

設計時に押さえておくべき「逆移行を見据えた」ポイント

試験導入のつもりで Hyperscale に上げる場合

「性能検証のために一旦 Hyperscale サーバーレスに上げてみたい」というケースは多いと思います。この場合、次のようなルールをチームで共有しておくと安全です。

  • Hyperscale へ変換した日付を必ず記録し、45 日以内に戻すかどうか判断する“締切日”をカレンダーに登録しておく。
  • もし本番ワークロードを流す前に「コストが合わない」と分かったら、早めに General Purpose へ逆移行する。
  • 逆移行後も再度 Hyperscale に変換すること自体は可能だが、バックアップ保持ポリシーやコストに影響が出る点に注意。

最初から Hyperscale で作らざるを得ないケース

例えば「初期から 5 TB 超のデータが想定される」「急激な成長が前提」といった場合、最初から Hyperscale を選択するのが自然です。しかし、この選択をすると “後から General Purpose に戻すには必ず手動移行が必要”になることを、関係者全員が理解しておく必要があります。

このような場合は、

  • 将来の「別プラットフォーム・別リージョンへの移行」まで見据えて、データ移行用のパイプライン（ADF / DMS など）を早期に用意しておく。
  • テーブルごとにデータ量・成長率をモニタリングし、「どこまでなら BACPAC」「どこからは他の手段」といった判断基準を事前に持つ。

Business Critical や DTU モデルへ移りたい場合

Hyperscale から 直接 Business Critical や DTU モデルへ移ることはできません。ドキュメントでも、「まず General Purpose へ逆移行してから別ティアへ変更する」と明示されています。

つまり、次のようなパスになります。

  • （45 日以内）Hyperscale → General Purpose（逆移行）→ Business Critical / DTU
  • （45 日超過 or 初期 Hyperscale）Hyperscale →（BACPAC/ADF 等で）General Purpose 新規 → Business Critical / DTU

特に DTU モデルへの移行を考えている場合は、この二段階の手順とダウンタイムを前提にスケジュールを引く必要があります。

よくある疑問にまとめて回答

Q. 「Hyperscale サーバーレス → General Purpose サーバーレス」はシームレスに切り替わる？

A. アプリケーション視点では「ほぼシームレスだが、短時間の停止と性能劣化は覚悟が必要」です。

  • 逆移行中は基本的に接続可能な時間が長いものの、トランザクション ログのスロットリング等による性能劣化が起こり得ます。
  • 最後のカットオーバー直前後は、数分程度の接続断が起こる可能性があります。

そのため、RPO/RTO 要件が厳しいシステムでは、メンテナンス ウィンドウを確保したうえでの実施が現実的です。

Q. Hyperscale → General Purpose へ逆移行したあと、再び Hyperscale に戻せる？

A. 可能です。ただし、

  • 再度 Hyperscale に変換した時点から、また新しく 45 日の逆移行ウィンドウがカウントされる。
  • バックアップ保持やストレージ課金は「現在のティアと直前のティア」のみが対象となるため、何度も行き来するとバックアップ ポリシーの把握が難しくなる。

運用をシンプルに保つためにも、頻繁な行き来は避けることをおすすめします。

Q. コスト削減が目的なら、まず何から手を付けるべき？

A. 「Hyperscale をやめる」という前に、次の順番で検討するのがよくあるパターンです。

  1. Hyperscale サーバーレス内での最適化
    • 最小 vCore・最大 vCore の見直し。
    • 自動一時停止の有効化 / 一時停止までの時間調整。
    • 不要なテスト DB / 旧バックアップ相当の DB の削除。
  2. Hyperscale (provisioned) → Hyperscale (serverless) への変更
    • 常時稼働ではなくピーク時だけの性能が欲しい場合に有効。
  3. どうしてもコストが合わない場合に限り、General Purpose への移行を検討
    • 45 日以内なら逆移行、そうでなければ BACPAC/ADF 等による手動移行。

まとめ：Hyperscale サーバーレスからの“出口戦略”を持っておこう

本記事のポイントを簡単にまとめると、次の通りです。

  • 既存 DB を Hyperscale に変換してから 45 日以内であれば、Azure 標準の逆移行機能で General Purpose（サーバーレス／プロビジョンド）へ戻せる。
  • 45 日を過ぎた場合、または最初から Hyperscale で作成した場合は、ポータルや CLI の設定変更だけでは他ティアへ出られず、BACPAC や Azure Data Factory 等を使った手動移行が必須になる。
  • 逆移行も手動移行も、即時かつ完全シームレスなスイッチではなく、サイズ依存のデータ移行として捉える必要がある。
  • 設計段階・検証段階から、「万が一 Hyperscale が合わなかった場合の出口」をチームで共有しておくことが、コストとリスクを抑える近道になる。

これから Hyperscale サーバーレスを導入する人も、すでに本番で利用している人も、「45 日ルール」と「BACPAC / データ移行戦略」を意識しておくことで、Azure SQL Database をより安心して活用できるはずです。

Azure
Azure SQL Database サーバーレス BACPAC Hyperscale General Purpose

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次