Azure SQL Database

解決する課題

• DB サーバーの OS パッチ・バックアップ・監視が重い → 自動化したい
• 障害で DB が止まると困る → 組み込みの高可用性で可用性を上げたい
• 負荷が読めない／変動する → 使った分だけ課金や自動スケールにしたい
• リージョン障害に備えたい → 自動フェイルオーバーグループで地理冗長したい

主要概念と用語

• 論理サーバー（logical server）: DB の接続エンドポイント（<name>.database.windows.net）と認証・ファイアウォール設定の管理単位。物理マシンではない
• デプロイ オプション: 単一データベース（Single Database） と エラスティック プール（Elastic Pool）。プールは複数 DB で計算リソースを共有しコストを平準化
• 購入モデル: vCore モデル（vCore 数とメモリを選ぶ。推奨）と DTU モデル（CPU/メモリ/IO を束ねた旧来の単位）
• サービス レベル（vCore）: General Purpose（汎用）／Business Critical（高 IOPS・低遅延・読み取りレプリカ付き）／Hyperscale（最大 128 TB まで分離ストレージで拡張）
• サーバーレス（Serverless）: General Purpose の計算層を自動スケールし、非アクティブ時は自動一時停止して課金を抑える計算層オプション
• アクティブ geo レプリケーション / フェイルオーバー グループ: 別リージョンへの読み取り可能なレプリカと、自動フェイルオーバー＋リスナーエンドポイント

仕様・制限・クォータ

• 自動バックアップ: フル／差分／トランザクションログを自動取得。ポイントインタイムリストア（PITR）保持期間は 1〜35 日（既定 7 日）。さらに 長期保持（LTR） で最大 10 年保管可能
• 最大サイズ: General Purpose / Business Critical は最大 4 TB、Hyperscale は最大 128 TB
• 接続: 同時要求数・ワーカー数・セッション数は選択した vCore / サービスレベルに比例。サーバーレスの最小 vCore は 0.5
• 暗号化: Transparent Data Encryption（TDE）は既定で有効。鍵は Microsoft 管理鍵、または Key Vault による顧客管理鍵（BYOK）
• リージョン／サブスクリプションごとにサーバー数・DTU・vCore のクォータがあり、引き上げ申請が可能

内部の仕組み

• General Purpose: 計算層と リモートのプレミアム ストレージを分離した構成。可用性は Service Fabric が計算ノード障害時に別ノードへ再配置して確保（AWS RDS の Multi-AZ に近い「ストレージ分離型」フェイルオーバー）
• Business Critical: 各 DB が Always On 可用性グループで複数レプリカ（通常 3 + 1）を持ち、ローカル SSD で動作。1 つは読み取り専用レプリカとして利用可能。低遅延・高 IOPS が必要なワークロード向け
• Hyperscale: ログサービス・ページサーバー・計算ノードに分離したアーキテクチャ。ストレージをほぼ無制限に拡張でき、スナップショットベースの高速バックアップ／リストアと複数の読み取りレプリカに対応
• フェイルオーバー: 計画外フェイルオーバーは通常数十秒。アプリは接続の再試行（リトライ）ロジックを実装しておくのが前提

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

• 本番は ゾーン冗長（Zone Redundant） を有効化し、可用性ゾーン間で冗長化
• 災害対策には フェイルオーバー グループで別リージョンへ自動フェイルオーバー（リスナーで接続先を切替）
• 多数の小さな DB は エラスティック プールでリソースを共有しコスト最適化
• 負荷が断続的なら サーバーレス、変動が大きいワークロードに合わせる
• 接続は プライベート エンドポイント（Private Link） でプライベート化し、パブリックアクセスは無効化
• 認証は Microsoft Entra ID 認証を優先し、SQL 認証のパスワード管理を避ける

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

• Azure Monitor / メトリクスで DTU・vCore・CPU・ストレージ・接続数を監視
• Query Performance Insight と Intelligent Insights で重いクエリや性能劣化を自動検出
• 自動チューニング（インデックスの作成/削除、プラン強制）を有効化して継続的に最適化
• 接続不可時はサーバーファイアウォール規則・仮想ネットワーク規則・プライベートエンドポイントを確認
• スロークエリは Query Store の実行プラン履歴とインデックス推奨を見直し

コスト

• vCore モデル（プロビジョニング）＝ vCore 数 × 時間 ＋ ストレージ ＋ バックアップストレージ
• サーバーレス＝秒単位の vCore 使用量＋ストレージ。非アクティブ時は計算課金が停止（自動一時停止）
• 定常稼働は 予約容量（Reserved Capacity, 1〜3 年） や Azure Hybrid Benefit（SQL Server ライセンス持ち込み）で割引

セキュリティ

• TDE（保存時暗号化）は既定で有効。鍵は Key Vault による顧客管理鍵（BYOK）も選択可
• 転送時は TLS を強制（最小 TLS バージョンを指定可能）
• Microsoft Entra ID 認証 + RBAC で権限を制御。SQL 認証のパスワード運用を避ける
• プライベート エンドポイントでパブリック露出を排除し、ファイアウォール規則は最小化
• Microsoft Defender for SQL で脆弱性評価・異常検知（SQL インジェクション等のアラート）
• 機微データは Always Encrypted（クライアント側暗号化）や 動的データ マスクで保護

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

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

# 論理サーバーを作成（Entra ID 管理者は後から設定推奨）
az sql server create \
  --name demo-sqlsrv-0603 \
  --resource-group demo-rg \
  --location japaneast \
  --admin-user sqladmin \
  --admin-password '<StrongP@ssw0rd!>'

# サーバーレスの単一データベースを作成（General Purpose / Gen5 / 自動一時停止 60分）
az sql db create \
  --resource-group demo-rg \
  --server demo-sqlsrv-0603 \
  --name appdb \
  --edition GeneralPurpose \
  --compute-model Serverless \
  --family Gen5 \
  --capacity 2 \
  --auto-pause-delay 60 \
  --zone-redundant false \
  --backup-storage-redundancy Local

# 別リージョンへフェイルオーバーグループを作成（DR）
az sql failover-group create \
  --name appdb-fog \
  --resource-group demo-rg \
  --server demo-sqlsrv-0603 \
  --partner-server demo-sqlsrv-dr \
  --add-db appdb