Azure SQL Database入門 オンプレSQLサーバーからの移行手順と料金・設計の基礎知識

「オンプレのSQL Serverをそろそろクラウドに移行したいけど、Azure SQL Databaseって実際どうなの？」

オンプレミスでSQL Serverを運用してきたエンジニアにとって、クラウドデータベースへの移行は気になるテーマです。パッチ適用、バックアップ、冗長構成の運用負荷から解放されたい一方で、「料金体系がわかりにくい」「パフォーマンスは大丈夫か」といった不安もあるでしょう。

この記事では、Azure SQL Databaseの基本的な仕組みから、オンプレSQL Serverとの違い、料金モデル、移行時に押さえておくべきポイントまで、現場目線で解説します。

Azure SQL Databaseとは？オンプレSQL Serverとの違い

Azure SQL Databaseは、MicrosoftがフルマネージドサービスとしてAzure上で提供するリレーショナルデータベースです。エンジンはSQL Serverと同じですが、インフラ管理の大部分をAzure側が担います。

オンプレのSQL Serverとの最大の違いは「何を自分で管理するか」です。

オンプレでAlways On可用性グループやログ配布を苦労して組んだ経験がある方なら、Azure SQL Databaseの「何もしなくても冗長化されている」という点だけでも移行する価値を感じるはずです。

デプロイモデルの選び方

Azure上でSQL Serverを使う方法は大きく3つあります。ここを間違えると移行コストが跳ね上がるので、最初に整理しておきます。

1. Azure SQL Database（単一データベース）

最もマネージド度が高い選択肢です。1データベース単位でリソースを割り当てます。新規開発やマイクロサービスのバックエンドに適しています。

SQL Server固有の機能（SQL Agent、CLR統合、クロスデータベースクエリなど）の一部は使えません。移行前に互換性チェックが必要です。

2. Azure SQL Managed Instance

SQL Serverとほぼ100%の互換性を持つマネージドサービスです。SQL Agentやクロスデータベースクエリもそのまま使えます。

オンプレからの「リフト＆シフト」移行に最適ですが、単一データベースより料金が高くなります。

3. Azure Virtual Machines上のSQL Server

Azure VM（仮想マシン）にSQL Serverをインストールする方式です。完全な管理権限がありますが、パッチ適用やバックアップは自分で管理します。

オンプレと同じ運用スキルがそのまま使えますが、マネージドサービスのメリットは薄くなります。

迷ったら「まずSQL Databaseで互換性チェック → 引っかかったらManaged Instance → それでもダメならVM」の順に検討するのが実務での定石です。

Azure SQL Databaseの作成手順

ここからは、Azure SQL Database（単一データベース）をAzureポータルとAzure CLIの両方で作成する手順を解説します。

1. Azureポータルでの作成

Azureポータル（portal.azure.com）にサインインし、以下の手順で進めます。

・「リソースの作成」→ 検索欄に「SQL Database」と入力 → 「SQL Database」を選択
・「作成」をクリック
・サブスクリプションとリソースグループを選択（なければ新規作成）
・データベース名を入力（例: myapp-db）
・サーバーを新規作成: サーバー名、管理者ログイン、パスワード、リージョン（東日本: Japan East）を設定
・「コンピューティングとストレージ」で購入モデルを選択（後述）
・「ネットワーク」タブで接続方法を選択
・「確認および作成」→「作成」

作成完了まで数分かかります。オンプレでSQL Serverのインストールに半日かけていた時代を思うと、驚くほど速いです。

2. Azure CLIでの作成

コマンドラインで作成する場合は以下のとおりです。

# リソースグループの作成
az group create --name myapp-rg --location japaneast

# SQL Serverの作成
az sql server create \
  --name myapp-sqlserver \
  --resource-group myapp-rg \
  --location japaneast \
  --admin-user sqladmin \
  --admin-password 'YourPassword123!'

# データベースの作成（汎用目的・2 vCore）
az sql db create \
  --resource-group myapp-rg \
  --server myapp-sqlserver \
  --name myapp-db \
  --service-objective GP_Gen5_2

# 自分のIPアドレスからの接続を許可
az sql server firewall-rule create \
  --resource-group myapp-rg \
  --server myapp-sqlserver \
  --name AllowMyIP \
  --start-ip-address 203.0.113.10 \
  --end-ip-address 203.0.113.10

`–service-objective GP_Gen5_2` は「汎用目的（General Purpose）、Gen5ハードウェア、2 vCore」を意味します。本番環境ではワークロードに合わせて調整してください。

3. 接続テスト

作成後、SQL Server Management Studio（SSMS）やAzure Data Studioから接続できます。

・サーバー名: `myapp-sqlserver.database.windows.net`
・認証: SQL Server認証（作成時に設定した管理者ログイン）
・暗号化: TLS接続が強制（オンプレと違い、暗号化はデフォルト有効）

オンプレでは `localhost\SQLEXPRESS` のようなインスタンス名で接続していましたが、Azure SQL Databaseでは `サーバー名.database.windows.net` 形式になります。SSMSの接続画面で入力する場所は同じなので、違和感なく使えるはずです。

料金モデルの仕組み

Azure SQL Databaseの料金は、オンプレのライセンス体系とまったく違います。ここを理解しないまま移行すると「思ったより高い」という事態に陥ります。

購入モデル: DTUとvCore

Azure SQL Databaseには2つの購入モデルがあります。

DTUモデル（Database Transaction Unit）
CPU・メモリ・IOPSをバンドルした単位です。「Basic」「Standard」「Premium」の3ティアから選びます。シンプルですが、細かいチューニングはできません。小規模なデータベースや開発環境に適しています。

vCoreモデル
CPU（vCore数）、メモリ、ストレージを個別に選択できます。オンプレでCPUコア数とメモリ容量を指定してサーバーを調達していた感覚に近いです。本番環境にはこちらを推奨します。

※ 価格は従量課金（Pay-As-You-Go）の目安です。リザーブドキャパシティ（1年/3年前払い）で最大55%割引になります。

Azure Hybrid Benefitで既存ライセンスを活用

オンプレでSQL Serverのソフトウェアアシュアランス（SA）付きライセンスを持っている場合、Azure Hybrid Benefitを適用できます。vCoreモデルの料金が最大55%割引になるため、移行時には必ず確認してください。

社内のライセンス管理部門に「SA付きか」を確認するだけで、年間数十万円のコスト差が出ることもあります。

移行の実務Tips

1. 互換性チェックは最初にやる

移行前に「Data Migration Assistant（DMA）」を使って互換性を確認します。オンプレのSQL Serverに対してDMAを実行すると、Azure SQL Databaseで使えない機能（CLR統合、Service Broker、分散トランザクションなど）を一覧で検出してくれます。

# Azure Database Migration Service（DMS）を使う場合
# Azure CLIでDMSインスタンスを作成
az dms create \
  --resource-group myapp-rg \
  --name myapp-dms \
  --location japaneast \
  --sku-name GeneralPurpose_4vCores

互換性の問題が多い場合は、SQL DatabaseではなくManaged Instanceを選択肢に入れてください。

2. ファイアウォールとネットワーク設計

オンプレではSQL Serverが社内ネットワーク上にあり、アクセス制御はWindowsファイアウォールやActive Directoryで行っていたと思います。

Azure SQL Databaseでは以下の3層でアクセスを制御します。

・サーバーレベルファイアウォール: 許可するIPアドレス範囲を指定
・仮想ネットワークサービスエンドポイント: Azure VNet内からのアクセスのみ許可
・プライベートエンドポイント: パブリックインターネットを経由せずVNet経由で接続

本番環境では、プライベートエンドポイントの利用を強く推奨します。パブリックエンドポイントを開放したままにすると、ブルートフォース攻撃のリスクがあります。

3. パフォーマンスの監視と調整

オンプレではSQL Server Profilerやパフォーマンスモニターで監視していたと思います。Azure SQL Databaseでは以下のツールが使えます。

・Query Performance Insight: Azureポータルから直接、重いクエリを特定できる
・Intelligent Insights: AIベースのパフォーマンス分析（自動チューニング機能付き）
・Azure Monitor: メトリクスとアラートの設定

特に「自動チューニング」は、インデックスの自動作成・削除を行ってくれる機能です。オンプレでDBAが手動で実行していたインデックスメンテナンスの一部を自動化できます。

よくあるトラブルと対処法

「接続できない」の90%はファイアウォール設定

SSMSから「Login failed」ではなく「Cannot connect to server」が出る場合、ほぼ確実にファイアウォールの設定漏れです。Azureポータルの「ファイアウォールと仮想ネットワーク」から自分のIPを追加してください。

「Azureサービスからのアクセスを許可」を有効にすると、Azure内の他サービス（App Service、Azure Functionsなど）からも接続できます。ただし本番環境では、VNetサービスエンドポイントに切り替えるべきです。

DTU上限に達してクエリが遅延する

DTUモデルを使っている場合、割り当てDUを超えるとスロットリング（意図的な性能制限）が発生します。Azureポータルの「メトリクス」でDTU使用率のグラフを確認し、常時80%を超えているならティアの引き上げを検討してください。

バックアップの復元方法がオンプレと違う

Azure SQL Databaseのバックアップは自動で取得されますが、.bakファイルとして直接ダウンロードすることはできません。復元は「ポイントインタイムリストア」で行います。

Azureポータルでデータベースを選択 →「復元」→ 復元先の日時を指定 → 新しいデータベースとして復元されます。

オンプレの「RESTORE DATABASE … FROM DISK」に慣れていると戸惑いますが、任意の時点に秒単位で復元できるのは、手動バックアップより確実です。

本記事のまとめ

オンプレのSQL Server運用で培ったスキルは、Azure SQL Databaseでもそのまま活きます。T-SQLはほぼ同じですし、SSMSでの操作感も変わりません。変わるのは「インフラ管理から解放される」という部分です。

まずはDTU Basicの開発環境を1つ作ってみて、手元のクエリを実行してみるのが、最も確実な第一歩です。