Azure SQL Database を長く運用していると、「DTU ベースから vCore ベースに切り替えたいが、本当に戻せるのか」「Hyperscale まで上げてしまうと片道切符なのではないか」と不安になりがちです。本記事では、北ヨーロッパリージョンを前提に、DTU ⇄ vCore の課金モデル切り替えと注意点を、実務でそのまま使えるレベルまで深掘りして解説します。
Azure SQL Database の DTU ⇄ vCore 切り替え完全ガイド（北ヨーロッパ対応）
結論：Hyperscale を除けば DTU ⇄ vCore は往復可能
まず一番気になる「DTU から vCore に切り替えたあと、満足できなければ DTU に戻せるのか？」という点から整理します。
- DTU → vCore（汎用 General Purpose / Business Critical） への移行はサポートされています。
- vCore → DTU への逆方向の移行も、ポータルやスクリプトから通常のスケール変更と同じ要領で実行できます。
- この仕様は 北ヨーロッパ（North Europe）リージョンでも同じ です。
公式ドキュメントでは、DTU ベースから vCore ベースへの移行は「Basic / Standard / Premium 間のスケール変更と同程度の時間と、最後に短時間のダウンタイムで完了し、移行後もいつでも DTU に戻せる（Hyperscale を除く）」と明記されています。
Hyperscale だけは別扱い（ただし最近は条件付きで戻せる）
かつては「Hyperscale に上げたら DTU や通常の vCore には戻せない」と言われることが多く、実質片道切符でした。しかし、現在の仕様では次のように整理できます。
| ケース | 戻せるかどうか | 補足 |
|---|---|---|
| 既存 DTU / vCore DB を Hyperscale に 変換 した場合 | 条件付きで戻せる | 変換から 45 日以内なら General Purpose（vCore）へ reverse migration 可能。 その後、Business Critical や DTU ベースのサービス層 へ変更することもサポートされています。 |
| Hyperscale で 新規作成 した DB | サービス層変更では戻せない | General Purpose / Business Critical / DTU などへ直接は移行不可。 export/import（bacpac や各種データ移行ツール）による「別 DB への移行」が必要。 |
つまり、「既存 DB をお試しで Hyperscale に上げる」だけなら、45 日以内であれば General Purpose → DTU まで含めて戻せる一方、Hyperscale 新規作成の DB はガチの片道、と理解しておくのが安全です。
DTU ベースと vCore ベースの違いをざっくりおさらい
切り替えを検討するときは、そもそも DTU と vCore の考え方の違いを押さえておくと、サイジングやコスト予測が楽になります。
| 項目 | DTU ベース（Basic / Standard / Premium） | vCore ベース（General Purpose / Business Critical / Hyperscale） |
|---|---|---|
| 課金の軸 | DTU（CPU・メモリ・IO を束ねた指標）とストレージ容量をまとめて課金。単純で分かりやすい。 | vCore 数・メモリ量・ストレージ容量・ストレージ種別を独立して選択。より柔軟で透明性が高い。 |
| スケールの自由度 | DTU を上げると CPU/メモリ/IO が一緒に増える。細かな調整は苦手。 | vCore 数とストレージを独立してスケール可能。IO やメモリ要件に応じて調整しやすい。 |
| コスト最適化 | 設定がシンプルで月額を読みやすい。低負荷な検証環境などに向く。 | Azure ハイブリッド特典、予約容量、サーバーレスなど多彩な割引・節約オプションを活用可能。 |
| 適したワークロード | それほど大きくないワークロードや、リソース変動が小さい業務アプリ。 「細かいことは気にせず、毎月一定額で動いてくれればよい」ケース。 | 大規模〜中規模で、CPU / IO 要件がはっきりしているシステム。 既存オンプレの vCPU ベース設計をそのままクラウドに持ち込みたいケース。 |
| Elastic Pool | eDTU ベースの Elastic Pool を利用可能。 | vCore ベースの Elastic Pool を利用可能。プールあたりの DB 数・上限は DTU のときと異なるので注意。 |
現行の Azure の位置付けとしては、「新規は vCore 推奨。DTU は既存ワークロードやシンプルな用途向け」となっていますが、機能としては依然どちらも利用可能です。
DTU ⇄ vCore の「戻せる／戻せない」を整理
ここまでの内容を、実際の移行パターンごとに整理します。
| 移行パターン | 戻せるか | 補足・注意点 |
|---|---|---|
| DTU → vCore（General Purpose / Business Critical） | ◯ いつでも DTU に戻せる | ポータル／CLI／PowerShell／T‑SQL でのサービス層変更として実行。短いダウンタイムあり。 |
| vCore（GP / BC） → DTU | ◯ いつでも戻せる | Compute + storage 画面などから DTU ベースの層を選択して適用するだけ。 |
| DTU / vCore → Hyperscale へ変換 | △ 条件付きで戻せる | 変換から 45 日以内・その他の制約を満たす場合のみ、General Purpose へ reverse migration 可能。 その後 Business Critical / DTU へ変更できる。 |
| Hyperscale で新規作成 → 他 tier へ | ✕ サービス層変更では不可 | バックアップ・bacpac・データ移行ツールなどで、別 DB として作り直す必要あり。 実質「片道」と考えた方が安全。 |
質問にあった「Basic / Standard / Premium の DTU ベースから vCore ベース（汎用など）に切り替えたあと、北ヨーロッパで DTU に戻せるか？」という点は、Hyperscale にさえしていなければ、いつでも戻せると考えて問題ありません。
注意点チェックリスト（DTU ⇄ vCore 切り替え前に見るべきポイント）
| 観点 | 確認ポイント |
|---|---|
| 性能の目安（換算） | ざっくりとした目安として、Basic / Standard の 100 DTU ≒ General Purpose 1 vCore、Premium の 125 DTU ≒ Business Critical 1 vCore と考えられます。 ただしハードウェア世代や IO、レイテンシによって体感性能は大きく変わるため、負荷テストを前提にすることが重要です。 |
| ストレージ / サイズ | vCore ではサービス層ごとに、最大サイズや IO 制限が異なります。 現在の DB サイズ、ログ増加速度、ピーク時の IOPS・スループットを確認し、ターゲット層の上限内に収まるかを事前にチェックしましょう。 |
| ハードウェア世代 | vCore モデルでは、standard-series (Gen5) や Premium シリーズなど複数のハードウェアがあり、リージョンごとに利用可否が異なります。 北ヨーロッパでは standard-series (Gen5) は利用可能ですが、より新しい世代やメモリ最適などは別途確認が必要です。 |
| 可用性 / レプリカ | アクティブ geo レプリケーション や フェールオーバー グループ を使っている場合、更新順序 に注意が必要です。 一般に、アップグレード時はセカンダリ → プライマリ、ダウングレード時はプライマリ → セカンダリ の順に変更します。 |
| コスト構造 | vCore モデルでは、vCore 数 × 単価 + ストレージ（容量・冗長化・種類）で課金されます。 Azure ハイブリッド特典（SQL Server ライセンス持ち込み）や 予約容量 の有無、バックアップストレージの課金体系も含めて再見積もりしましょう。 |
| クォータ | サブスクリプションとリージョンごとに、vCore 上限（クォータ） が設定されています。大量の DB を一度に vCore 化する場合や、高 vCore 数を前提とする場合、事前にサポートチケットで増枠申請しておくと安全です。 |
| 機能差 | General Purpose はリモートストレージ中心、Business Critical はローカル SSD ベースで低レイテンシ・高 IO を提供するなど、同じ vCore 数でもレイテンシと HA の仕組みが大きく異なります。 トランザクション遅延・ RPO / RTO・高可用性要件に応じて層を選択しましょう。 |
| ダウンタイム対策 | いずれの移行も最終カットオーバー時に数秒〜数分程度のダウンタイムが発生します。 事前にメンテナンス時間を確保し、接続リトライ・トランジェントフォールト対策・アプリ側タイムアウト値の見直しを行っておきましょう。 |
DTU ⇄ vCore サイジングの考え方
ざっくり版：DTU ⇄ vCore の早見表
実際の性能はワークロード次第ですが、検討の起点として次のような早見表を置いておくとイメージしやすくなります。
| 現行 DTU 層の例 | DTU 数 | 目安となる vCore モデル | コメント |
|---|---|---|---|
| Standard S0 / S1 / S2 | 10 / 20 / 50 DTU | General Purpose 2 vCore（サーバーレスなど） | 1 vCore 未満相当だが、vCore 側の最小単位が 2 vCore なので余裕を見て 2 vCore から開始。 |
| Standard S3 | 100 DTU | General Purpose 1〜2 vCore | CPU バウンドなら 2 vCore、IO バウンドなら 1 vCore でも十分なケースもあるため、必ず検証環境で負荷テストを行う。 |
| Premium P1 | 125 DTU | Business Critical 1〜2 vCore | IO 性能を重視するため、Business Critical を優先して検証するのが無難。 |
| Premium P4 / P6 以上 | 500〜1000 DTU 以上 | Business Critical 8 vCore 以上 | Memory / IO 要件を満たすように、まずはやや多めの vCore で開始し、実測を見ながら削る方が安全。 |
公式ドキュメントにもある通り、「DTU ÷ 100 ≒ vCore」や「Premium の 125 DTU ≒ 1 vCore」はあくまで概算であり、CPU バウンドか IO バウンドか、メモリの要求量などで最適値は変わります。
精度を上げるなら DMV ベースの T‑SQL を活用
さらに精度を上げたい場合、公式が示す DMV を使った T‑SQL スクリプトで、「現在の DTU DB に割り当てられている論理 CPU 数とメモリ量」から、標準シリーズや FSv2 シリーズなど各ハードウェア構成における推奨 vCore 数を計算することができます。
実務的には、次の 3 ステップで考えるのが扱いやすいです。
- DTU DB のピーク / 平均 CPU 使用率、DTU 使用率、IO 待機時間などを 1〜2 週間ほど収集。
- DMV ベースの T‑SQL で「CPU・メモリ観点の推奨 vCore 数」を算出。
- 推奨値をベースに、1 ランク上の vCore 数で検証用 DB を作成し、本番相当のワークロードでテスト。
この方法なら、いきなり「感覚」で vCore 数を決めてしまうリスクを大きく減らせます。
北ヨーロッパリージョン特有のポイント
今回の前提リージョンである North Europe（北ヨーロッパ） では、Azure SQL Database の vCore モデル向けハードウェアとして standard-series (Gen5) が全世界の公開リージョン同様に利用可能です。
一方で、以下のような点はリージョンごとに提供状況が異なるため、設計時に確認しておくと安心です。
- Premium シリーズ（高性能 CPU / 高メモリ構成）が使えるかどうか
- ゾーン冗長（ZRS）ストレージや可用性ゾーンを活用した Business Critical の構成可否
- Hyperscale の提供有無と、利用可能な最大サイズ
公式の「Azure SQL Database のリージョン別機能一覧」では、vCore モデルのハードウェアごとに利用可能なリージョンがまとめられているので、本番構成を決める前に North Europe の行を必ずチェックしておきましょう。
実務向け：DTU ⇄ vCore 切り替えおすすめステップ
ステップ 1：現状把握
いきなりサービス層を切り替えるのではなく、まずは現状のワークロードを定量的に把握します。
- ピーク時 / 平常時の CPU 使用率、DTU 使用率
- データ / ログファイルのサイズ、日次増分、トランザクション数
- 主要クエリのレスポンス時間、タイムアウトやデッドロックの有無
- geo レプリケーションやフェールオーバーグループの構成
これらの値を取っておくと、切り替え後の性能比較や、コストに見合うかどうかの判断がしやすくなります。
ステップ 2：目標層の当たりをつける
先ほどの概算換算とワークロード特性から、以下を暫定的に決めます。
- サービス層：General Purpose か Business Critical か
- vCore 数：現行 DTU を基準に概算
- ストレージ：必要容量 + 成長分 + 余裕（例：1〜2 年分）
- バックアップ保持期間と、その分のバックアップストレージコスト
同時に、「コストを優先するなら General Purpose で IO をチューニング」「性能を優先するなら Business Critical を優先」といった方針も決めておきましょう。
ステップ 3：検証用コピーで本番相当テスト
本番 DB をいきなり切り替えるのではなく、次のいずれかで 検証用 DB を作成します。
- ポイントインタイムリストア（PITR）で別名 DB を作成
- 同一リージョン内で DB コピーを作成
- 必要に応じてマスク済みデータをロードして性能テスト環境を構築
検証用 DB に対して、性能テストツールや実際のアプリケーションを使って以下を確認します。
- 主要画面・バッチ処理のレスポンス時間
- ピーク時の CPU / IO / メモリ使用率
- ログの増加速度、トランザクションログ使用率
- 月間コスト見積もり（Azure Portal のコスト分析など）
ステップ 4：本番切り替え計画の策定
検証結果を踏まえて本番切り替えの具体的な計画を作ります。
- メンテナンス時間帯（業務影響が少ない時間）を決める
- フェールオーバー構成がある場合は、セカンダリ → プライマリの順で切り替える手順を明文化
- アプリケーション側の接続リトライやタイムアウト設定の変更（例：タイムアウトを一時的に長めに設定）
- ロールバック時の手順（DTU へ戻すときの具体的なコマンドやオペレーション）
ステップ 5：本番切り替えの実施
当日は次のような流れで作業すると安定します。
- アプリケーションのリリースフリーズ（書き込み負荷をできるだけ減らす）
- 想定外トラブルに備えた直近のバックアップ状況を確認
- Azure ポータルまたはスクリプトでサービス層と購入モデルを切り替え
- DB の状態・接続数・エラー有無を確認
- アプリケーションを順次復旧し、主要機能の疎通テストを実施
ステップ 6：監視と微調整
切り替え後 1〜2 週間は、次の指標を重点的にモニタリングします。
- CPU 使用率・IO 使用率・待機時間（特定の wait type が増えていないか）
- クエリの実行時間・プラン変更の有無
- 実際の請求額（見積もりとの差）
必要に応じて vCore 数を増減させたり、ストレージ種別を変更したりして、性能とコストのバランスがよいポイントに落とし込んでいきます。
ステップ 7：ロールバック計画の維持
もし期待した性能やコストメリットが得られなければ、DTU ベースに戻す選択肢を常に持っておきましょう。
- 戻し先の DTU 層（例：Standard S3 / Premium P1 など）をあらかじめ決めておく
- vCore → DTU の切り替え手順を、DTU → vCore と同じ粒度で手順書化しておく
- Hyperscale を検証に使った場合は、45 日の reverse migration 期限をカレンダーなどで管理しておく
具体的な操作イメージ（ポータル / CLI / PowerShell / T‑SQL）
Azure ポータルでの切り替え
DTU → vCore、vCore → DTU のいずれも、ポータルでは次のような操作になります。
- 対象の SQL Database リソースを開く
- [設定] → [Compute + storage] を選択
- [Service tier] のドロップダウンから、DTU or vCore、さらに General Purpose / Business Critical / Hyperscale などを選択
- vCore モデルの場合は、ハードウェア（standard-series など）と vCore 数、ストレージを指定
- [Apply] を押して変更を適用
この操作はサービス層のスケール変更と同じ扱いなので、切り替え中は接続が一時的に切れることがあります。
Azure CLI の例
Azure CLI を使う場合、DTU → vCore のイメージは次のようになります（パラメータ名は簡略化）。
az sql db update \
--resource-group MyRG \
--server my-sql-server \
--name mydb \
--edition GeneralPurpose \
--family Gen5 \
--capacity 4 \
--compute-model Provisioned
同様に、vCore → DTU に戻したい場合は、Standard や Premium のサービス目標（S3 / P1 など）を指定します。
az sql db update \
--resource-group MyRG \
--server my-sql-server \
--name mydb \
--edition Standard \
--service-objective S3
PowerShell（Set-AzSqlDatabase）の例
PowerShell では Set-AzSqlDatabase コマンドレットで、購入モデルとサービス層をまとめて変更します。
$params = @{
ResourceGroupName = "MyRG"
ServerName = "my-sql-server"
DatabaseName = "mydb"
Edition = "GeneralPurpose" # or "BusinessCritical" / "Standard" / "Premium"
RequestedServiceObjectiveName = "GP_Gen5_4" # vCore 側のサイズ
}
Set-AzSqlDatabase @params
DTU に戻す場合は Edition を "Standard" や "Premium" に変え、RequestedServiceObjectiveName に "S3" や "P1" などの目標値を指定します。
T‑SQL でのサービス層変更
アプリケーションや自動化ジョブから直接 T‑SQL を発行して切り替えたい場合は、次のように ALTER DATABASE ... MODIFY を使用します。
-- DTU → vCore (General Purpose) の例
ALTER DATABASE [mydb]
MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_4');
GO
-- vCore → DTU (Standard S3) の例
ALTER DATABASE [mydb]
MODIFY (EDITION = 'Standard', SERVICE_OBJECTIVE = 'S3');
GO
いずれも、実行タイミングを誤るとユーザー影響が出るため、メンテナンス時間帯にだけ実行されるようジョブやパイプラインを設計しておきましょう。
ダウンタイムとアプリ側への影響を最小化するコツ
DTU ⇄ vCore の切り替えは、DB 単体では数分で終わることが多いものの、その間にアプリケーションが大量のエラーを返すとユーザー体験が大きく損なわれます。ここでは、アプリ側でできる対策をまとめます。
- 接続リトライ（Connection Resiliency）の有効化
.NET / Java / Node.js などのクライアントでは、トランジェントエラー時に指数バックオフ付きで再試行する仕組みを備えています。切り替えのような短時間の停止には特に有効です。 - コマンドタイムアウトの見直し
デフォルトの 30 秒では足りない長時間クエリがある場合、特に切り替え後の初回実行時にタイムアウトが多発することがあります。一時的にタイムアウト値を引き上げてリリースし、安定後に再調整すると安全です。 - 接続プールのウォームアップ
再起動直後やサービス層変更直後は、接続プールが空の状態から構築されるため、最初のアクセスが遅く感じられることがあります。切り替え後に「内部用ウォームアップリクエスト」を数十回投げるなどして、プールを温めてからユーザーを戻すと UX が向上します。 - エラーメッセージのユーザーフレンドリー化
一時的な DB エラーに対して「ただちにシステム管理者へ連絡してください」といった重いメッセージを出すのではなく、「現在メンテナンス中の可能性があります。しばらく待ってから再度お試しください」など、ユーザーが無用に不安にならない文言に変えておくとよいでしょう。
コスト面でよくある落とし穴
vCore モデルは非常に柔軟な一方で、設計を誤ると「DTU のときより高くついた」という事態になりがちです。ここでは代表的な落とし穴と対策を挙げます。
- vCore を盛りすぎてしまう問題
「DTU ÷ 100 ≒ vCore」の目安を過度に安全寄りに見積もってしまい、必要以上に vCore を割り当ててしまうケースです。まずはやや控えめな構成で検証し、必要に応じてスケールアップする「小さく生んで大きく育てる」戦略の方がトータルコストは抑えやすくなります。 - Azure ハイブリッド特典を使い忘れる
既に Software Assurance 付きの SQL Server ライセンスを持っているのに、ハイブリッド特典を有効化しないと、vCore 単価を大きく損します。オンプレ資産がある場合は必ず確認しましょう。 - 予約容量（Reserved Capacity）を後回しにする
「まずは様子見でオンデマンド課金にしておこう」と考えるのは自然ですが、1 年以上継続利用がほぼ確実な本番 DB については、早めに 1 年 or 3 年の予約を検討した方が中長期のコストは確実に下がります。 - バックアップストレージの見落とし
長期保持（例えば 10 年）を有効にしている場合、バックアップストレージ費用がじわじわ効いてきます。保持期間と復旧要件を見直し、本当に必要な期間だけ保持するように設計しましょう。
よくある落とし穴と回避策（まとめ）
- 「とりあえず Hyperscale に上げてから考える」は危険
Reverse migration で戻せるケースは増えたものの、45 日制限や新規作成 DB への制約など条件はかなり細かいです。まずは Business Critical や General Purpose でのスケールアップ・チューニングをやり切ってから検討する方が安全です。 - DTU 換算の「数字」だけを信じる
DTU と vCore の数値比較はあくまで CPU 観点であり、IO パターンや同時実行度、クエリパターンによって実効性能は大きく変わります。必ず本番相当のワークロードで負荷テストを行い、CPU・IO・メモリ・待機時間を総合的に見て判断しましょう。 - クォータ不足で作業当日に詰む
大量の DB を一斉に vCore 化するとき、「想定より早く vCore 上限に達して一部だけ移行できない」といったトラブルが起こりがちです。事前に Azure ポータルやサポートでクォータ状況を確認し、必要なら増枠申請しておきましょう。 - フェールオーバー構成を考慮しない
geo レプリケーションやフェールオーバーグループを組んでいる場合、プライマリとセカンダリで層を揃えること、変更順序を守ることが重要です。これを誤ると、一時的に構成が不整合になり、フェールオーバーできなくなるリスクがあります。 - アプリ側のトランジェントエラー対策が不十分
切り替え時の短いダウンタイムで大量のエラーが発生し、「DB の問題」ではなく「アプリのリトライ不足」が原因となるケースも多くあります。接続リトライ・指数バックオフ・タイムアウトの適切な設定は、DTU ⇄ vCore 移行に限らずクラウド DB 運用の必須項目です。
まとめ：Hyperscale を意識しつつ、DTU ⇄ vCore を戦略的に使い分ける
最後に、本記事のポイントを整理します。
- Hyperscale を除けば、DTU ⇄ vCore は北ヨーロッパでも基本的に往復可能です。性能やコストが期待外れなら、いつでも DTU に戻すという選択肢を残しておけます。
- DTU と vCore の性能は「100 DTU ≒ 1 vCore」程度でしか比較できないため、概算 → 検証環境での負荷テスト → 本番という三段階で慎重に移行するのが安全です。
- フェールオーバー構成、vCore クォータ、Hyperscale の制約、ダウンタイム対策などを事前にチェックしておけば、計画的に切り替えとロールバックを行えるようになります。
「DTU から vCore に変えたいが、戻れなくなったらどうしよう」と躊躇している場合でも、Hyperscale を慎重に扱いさえすれば、リスクは十分コントロール可能です。本記事を参考に、まずは小さな DB や検証環境から DTU ⇄ vCore 切り替えを試し、組織としてのベストプラクティスを固めていくことをおすすめします。
コメント