Azure SQL Databaseの導入ガイド｜構築・バックアップ・パフォーマンス最適化

「オンプレミスのSQL Serverの保守が負担になっている」「データベースのバックアップやパッチ適用を自動化したい」――そんな課題を抱えるIT担当者やエンジニアにとって、Azure SQL Databaseは有力な選択肢です。

Azure SQL Databaseは、Microsoft SQL Serverエンジンをベースにした、フルマネージドのリレーショナルデータベースサービスです。パッチ適用、バックアップ、監視、高可用性といったデータベース管理タスクの大部分がAzure側で自動化されるため、開発者はアプリケーションのデータ設計とクエリの最適化に集中できます。

この記事では、Azure SQL Databaseの購入モデルの選び方、データベースの構築手順、バックアップと復元、パフォーマンスチューニング、セキュリティ設定まで、実務で必要な知識を体系的に解説します。

Azure SQL Databaseの基本概念とデプロイオプション

Azure SQL Databaseを導入する前に、デプロイの形態と基本概念を理解しておきましょう。

デプロイオプションの比較

Azure上でSQL Serverを利用する方法は、主に3つあります。

Azure SQL Database（単一データベース）：1つのデータベースを独立して管理するPaaS。最もシンプルで、新規プロジェクトに推奨される
Azure SQL Database（エラスティックプール）：複数のデータベースでコンピューティングリソースを共有するPaaS。SaaSアプリケーションなど、多数の小規模データベースを運用する場合に最適
Azure SQL Managed Instance：SQL Serverとほぼ100%の互換性を持つPaaS。オンプレミスからの移行で、SQL Server Agentやクロスデータベースクエリなどの機能が必要な場合に選択する

この記事では、最も一般的なAzure SQL Database（単一データベース）を中心に解説します。

リソース構造

Azure SQL Databaseは、以下の2階層で構成されます。

論理サーバー：データベースの管理単位。ファイアウォールルール、監査設定、管理者アカウントなど、サーバーレベルの設定を管理する。実体はSQL Serverインスタンスではなく、Azure上の論理的な管理単位
データベース：実際のデータを格納するリソース。論理サーバー内に複数のデータベースを作成できる

購入モデルとサービスレベルの選定

Azure SQL Databaseには2つの購入モデルがあり、ワークロードの特性に応じて選択します。

DTUモデル

DTU（Database Transaction Unit）モデルは、CPU、メモリ、I/Oを束ねた抽象的な単位でリソースを定義するモデルです。

Basic：5 DTU、最大2GBストレージ。開発・テスト環境向け。月額約700円
Standard：10〜3,000 DTU。中小規模の本番環境向け。月額約2,000円〜
Premium：125〜4,000 DTU。高パフォーマンスが必要な本番環境向け。月額約60,000円〜

DTUモデルは、リソースの組み合わせが事前に決まっているためシンプルです。データベースの要件が明確でない初期段階や、小規模なワークロードに適しています。

vCoreモデル

vCore（仮想コア）モデルは、CPU、メモリ、ストレージを個別に設定できるモデルです。

General Purpose：汎用的なワークロード向け。リモートストレージを使用。2〜80 vCore
Business Critical：高I/Oパフォーマンスが必要なワークロード向け。ローカルSSDを使用。読み取り可能なレプリカが1つ無料で付属
Hyperscale：大規模データベース（最大100TB）向け。ストレージの自動拡張、高速バックアップ、読み取りレプリカのスケールアウトに対応

vCoreモデルでは、Azure Hybrid Benefitを利用して、既存のSQL Serverライセンスを持ち込むことで最大55%のコスト削減が可能です。

サーバーレスコンピューティング

vCoreモデルのGeneral Purposeティアでは、サーバーレスコンピューティング層も選択できます。アクセスがない期間はコンピューティングが自動で一時停止し、その間のコンピューティング料金は発生しません。

使用パターンが不規則な開発環境やバッチ処理用データベースに適しています。サーバーレスアーキテクチャの基本も参考にしてください。

データベースの構築手順

Azure CLIを使って、論理サーバーとデータベースを作成します。

論理サーバーとデータベースの作成

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

# 論理サーバーの作成
az sql server create \
  --name sql-myapp-prod \
  --resource-group rg-db-prod \
  --location japaneast \
  --admin-user sqladmin \
  --admin-password "$(openssl rand -base64 32)"

# データベースの作成（vCoreモデル、General Purpose、2vCore）
az sql db create \
  --name db-myapp-prod \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 2 \
  --max-size 32GB \
  --zone-redundant false

管理者パスワードは十分に強力なものを設定し、Azure Key Vaultで安全に管理しましょう。本番環境では、管理者アカウントの代わりにMicrosoft Entra ID認証を使うことを推奨します。

ファイアウォールルールの設定

Azure SQL Databaseは、デフォルトですべてのアクセスをブロックします。必要なIPアドレスからのアクセスのみを許可するファイアウォールルールを設定します。

# 特定のIPアドレスからのアクセスを許可
az sql server firewall-rule create \
  --name AllowOfficeIP \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --start-ip-address 203.0.113.10 \
  --end-ip-address 203.0.113.10

# Azureサービスからのアクセスを許可
az sql server firewall-rule create \
  --name AllowAzureServices \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --start-ip-address 0.0.0.0 \
  --end-ip-address 0.0.0.0

本番環境では、ファイアウォールルールよりもAzure Virtual Networkのサービスエンドポイントやプライベートエンドポイントを使って、ネットワークレベルでアクセスを制限することを推奨します。

バックアップと復元の仕組み

Azure SQL Databaseの大きな利点の一つが、自動バックアップ機能です。手動でのバックアップスクリプト作成やスケジューリングが不要になります。

自動バックアップの仕組み

Azure SQL Databaseは、以下の3種類のバックアップを自動で取得します。

完全バックアップ：毎週1回
差分バックアップ：12〜24時間ごと
トランザクションログバックアップ：5〜10分ごと

これにより、ポイントインタイムリストア（PITR）として、過去の任意の時点（秒単位）にデータベースを復元できます。

バックアップ保持期間の設定

バックアップの保持期間は、以下の2つのレベルで設定できます。

短期保持ポリシー（PITR）：1〜35日間（デフォルト7日）。直近のデータ復元に使用
長期保持ポリシー（LTR）：最大10年間。コンプライアンスや監査のための長期保存に使用

# 短期保持期間を14日に変更
az sql db str-policy set \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --name db-myapp-prod \
  --retention-days 14

# 長期保持ポリシーの設定（週次バックアップを1年間保持）
az sql db ltr-policy set \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --name db-myapp-prod \
  --weekly-retention P52W

ポイントインタイムリストアの実行

# 特定の時点にデータベースを復元
az sql db restore \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --name db-myapp-prod-restored \
  --dest-name db-myapp-prod-restored \
  --time "2026-03-21T10:30:00Z"

復元は常に新しいデータベースとして作成されます。既存のデータベースを上書きすることはできません。復元したデータベースの内容を確認後、必要に応じてアプリケーションの接続先を切り替えます。

パフォーマンスの監視とチューニング

Azure SQL Databaseには、パフォーマンスを可視化し、最適化するための組み込み機能が充実しています。

Query Performance Insight

Azure Portal上で利用できるQuery Performance Insightは、リソースを最も消費しているクエリを特定するための機能です。

CPU消費量の多いクエリ：TOP 5のクエリとその実行頻度を可視化
実行時間の長いクエリ：レスポンスタイムの長いクエリを特定
実行回数の多いクエリ：最も頻繁に実行されているクエリを特定

自動チューニング

Azure SQL Databaseの自動チューニング機能は、以下の3つの最適化を自動で実行します。

インデックスの自動作成：クエリパターンを分析し、パフォーマンスを改善するインデックスを自動で作成する
インデックスの自動削除：使用されていない冗長なインデックスを自動で削除する
プラン修正の強制：パフォーマンスが低下したクエリの実行プランを、以前の良好なプランに自動で戻す

# 自動チューニングの有効化
az sql db update \
  --name db-myapp-prod \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --set tags.autoTuning=enabled

# Azure Portalでの設定が推奨される
# データベース → 自動チューニング → 各オプションをONに設定

インデックス設計のベストプラクティス

自動チューニングに加えて、以下の観点でインデックス設計を見直しましょう。

WHERE句の頻出カラム：フィルタリングに頻繁に使われるカラムにインデックスを作成する
JOIN句のカラム：テーブル結合に使われるカラムにインデックスを作成する
カバリングインデックス：クエリで参照するすべてのカラムを含むインデックスを作成し、テーブルルックアップを回避する
不要なインデックスの削除：書き込み性能を低下させる未使用インデックスを定期的にクリーンアップする

-- 未使用インデックスの特定クエリ
SELECT
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ius.user_seeks,
    ius.user_scans,
    ius.user_lookups,
    ius.user_updates
FROM sys.indexes i
LEFT JOIN sys.dm_db_index_usage_stats ius
    ON i.object_id = ius.object_id AND i.index_id = ius.index_id
WHERE OBJECTPROPERTY(i.object_id, 'IsUserTable') = 1
    AND i.index_id > 0
    AND (ius.user_seeks + ius.user_scans + ius.user_lookups) = 0
ORDER BY ius.user_updates DESC;

セキュリティ設定の強化

データベースには機密性の高いデータが格納されることが多いため、多層的なセキュリティ対策が重要です。

Microsoft Entra ID認証の設定

SQL認証（ユーザー名・パスワード）に加えて、Microsoft Entra ID（旧Azure AD）による認証を設定しましょう。

# Microsoft Entra ID管理者の設定
az sql server ad-admin create \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --display-name "DB Admin Group" \
  --object-id "00000000-0000-0000-0000-000000000000"

本番環境では、SQL認証を無効にしてMicrosoft Entra ID認証のみに制限することも可能です。

Transparent Data Encryption（TDE）

TDEは、データベースの物理ファイルをリアルタイムで暗号化する機能です。Azure SQL Databaseでは、デフォルトで有効になっているため、追加の設定は不要です。暗号化キーはAzureが自動で管理しますが、Azure Key Vaultで独自のキーを管理（BYOK）することも可能です。

監査とAdvanced Threat Protection

# 監査の有効化（ストレージアカウントへのログ保存）
az sql server audit-policy update \
  --resource-group rg-db-prod \
  --name sql-myapp-prod \
  --state Enabled \
  --storage-account stmyappprod001

# Advanced Threat Protectionの有効化
az sql db threat-policy update \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --name db-myapp-prod \
  --state Enabled \
  --email-addresses "security@example.com"

Advanced Threat Protectionは、SQLインジェクション攻撃、異常なアクセスパターン、ブルートフォース攻撃などを検出し、管理者にアラートを送信します。

高可用性とディザスタリカバリ

Azure SQL Databaseは、プランに応じて自動的に高可用性が確保されます。

組み込みの高可用性

General Purpose：リモートストレージのレプリケーションにより、99.99%のSLAを提供。フェイルオーバー時には10〜30秒のダウンタイムが発生する可能性がある
Business Critical：Always On可用性グループに基づく構成で、99.995%のSLAを提供。読み取り可能なセカンダリレプリカが自動で作成される

フェイルオーバーグループの設定

リージョン障害に備えるには、別リージョンへの自動フェイルオーバーグループを構成します。

# セカンダリリージョンに論理サーバーを作成
az sql server create \
  --name sql-myapp-dr \
  --resource-group rg-db-prod \
  --location japanwest \
  --admin-user sqladmin \
  --admin-password "$(openssl rand -base64 32)"

# フェイルオーバーグループの作成
az sql failover-group create \
  --name fg-myapp \
  --resource-group rg-db-prod \
  --server sql-myapp-prod \
  --partner-server sql-myapp-dr \
  --add-db db-myapp-prod \
  --failover-policy Automatic \
  --grace-period 1

フェイルオーバーグループを構成すると、fg-myapp.database.windows.netという読み書きリスナーエンドポイントが提供されます。アプリケーションはこのエンドポイントに接続するだけで、フェイルオーバー時に自動的にセカンダリに接続が切り替わります。