Azure SQL Managed Instance

解決する課題

• オンプレの SQL Server をほぼ無改修で移行したいが、DB 単位の PaaS では機能が足りない → インスタンス互換のマネージド DB が欲しい
• OS パッチ・バックアップ・高可用性の運用が重い → クラウド側に任せたい
• SQL Agent ジョブ・クロス DB クエリ・CLR・リンクサーバーなどインスタンスレベルの機能を使い続けたい
• DB をプライベートネットワーク内に閉じて配置したい

主要概念と用語

• マネージドインスタンス（Managed Instance）: SQL Server のインスタンスにほぼ完全互換なデプロイ単位。複数のユーザーデータベースを 1 つのインスタンスに収容できる
• インスタンスレベル機能: SQL Server Agent、クロスデータベースクエリ、CLR、リンクサーバー、Service Broker、共通ログインなど、DB 単位の PaaS では制限される機能に対応
• サービスレベル: 汎用の General Purpose（計算とストレージを分離）と、高 IOPS・低遅延でローカル SSD と可用性グループを使う Business Critical の 2 種類
• インスタンスプール（Instance Pool）: 小規模なインスタンスを共有プールにまとめ、リソースを効率的に使う仕組み
• 委任サブネット（delegated subnet）: マネージドインスタンスは必ず仮想ネットワークの専用サブネットに配置され、そのサブネットはインスタンス専用に委任される
• マネージドインスタンスリンク（MI link）: オンプレや別環境の SQL Server とインスタンスをレプリケーションで結び、移行やハイブリッド運用を支援する機能

仕様・制限・クォータ

• 互換性: SQL Server のインスタンスレベル機能の大半に対応するが、ファイルストリームや一部の物理パス依存機能など非対応の機能も残るため、移行前にアセスメントが必要
• 配置: 必ず仮想ネットワークの専用サブネットに配置する。サブネットはインスタンスに委任され、他リソースと共有できない
• 自動バックアップ: フル／差分／トランザクションログを自動取得。**ポイントインタイムリストア（PITR）に対応し、保持期間は設定可能。さらに長期保持（LTR）**で長期保管できる
• 暗号化: Transparent Data Encryption（TDE）は既定で有効。Microsoft 管理鍵のほか、Key Vault による顧客管理鍵（BYOK）も選択可
• ストレージとインスタンスサイズ: vCore 数・メモリ・最大ストレージはサービスレベルと選択した構成に比例する。General Purpose と Business Critical で上限が異なる
• リージョン／サブスクリプションごとに vCore 数などのクォータがあり、引き上げ申請が可能

内部の仕組み

• General Purpose: 計算層とリモートのストレージを分離した構成。計算ノードに障害が起きると別ノードへ再配置して可用性を確保する。可用性とコストのバランスを重視する汎用ワークロード向け
• Business Critical: Always On 可用性グループで複数レプリカを持ち、ローカル SSD で動作する。1 つは読み取り専用レプリカとして利用でき、低遅延・高 IOPS を必要とするワークロードに向く
• ネットワーク分離: インスタンスは委任サブネット内に閉じて動作し、内部の管理トラフィックとユーザートラフィックが分離される。アプリは仮想ネットワーク内またはプライベート接続経由でアクセスする
• フェイルオーバー: 計画外フェイルオーバーが起きうるため、アプリ側には接続の再試行（リトライ）ロジックを実装しておくのが前提

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

• 移行前にアセスメントツールで互換性を確認し、非対応機能を洗い出す
• 本番はゾーン冗長を有効化し、可用性ゾーン間で冗長化する（対応するサービスレベルで）
• 災害対策には自動フェイルオーバーグループで別リージョンへ複製し、読み取りスケールにも活用する
• 接続は仮想ネットワーク内に閉じ、必要に応じてプライベート接続でアプリと結ぶ
• 認証は Microsoft Entra ID 認証を優先し、SQL 認証のパスワード管理を避ける
• オンプレからの移行は MI link や Azure Database Migration Service を使い、ダウンタイムを抑える

運用・監視

• Azure Monitor / メトリクスで CPU・メモリ・ストレージ・IO・接続数を監視する
• SQL Server Agent ジョブをそのまま運用できるため、既存の定期メンテナンスジョブを移行しやすい
• スロークエリは Query Store の実行プラン履歴とインデックス推奨を見直す
• 接続不可時はサブネットのネットワークセキュリティグループ・ルートテーブル・DNS 設定を確認する
• バックアップは自動取得されるが、復元手順の検証を定期的に行う

コスト

• 課金は vCore 数 × 時間 ＋ ストレージ ＋ バックアップストレージが基本
• 定常稼働は**予約容量（1〜3 年）**や Azure Hybrid Benefit（SQL Server ライセンス持ち込み）で割引できる
• 小規模インスタンスを多数使う場合はインスタンスプールでリソースを共有しコストを平準化する
• 具体的な料金は構成・リージョン・期間で変動するため、公式の料金計算ツールで見積もる

セキュリティ

• TDE（保存時暗号化）は既定で有効。鍵は Key Vault による顧客管理鍵（BYOK）も選択可
• 転送時は TLS を強制する
• Microsoft Entra ID 認証 + RBAC で権限を制御し、SQL 認証のパスワード運用を避ける
• 仮想ネットワーク分離でパブリック露出を排除し、サブネットのネットワークセキュリティグループで最小化する
• Microsoft Defender for SQL で脆弱性評価・異常検知を有効化する
• 機微データは Always Encrypted（クライアント側暗号化）や動的データマスクで保護する

Well-Architected の観点

• 信頼性（Reliability）: ゾーン冗長と自動フェイルオーバーグループで可用性を高め、自動バックアップと PITR で復旧性を確保する。アプリにリトライロジックを実装する
• オペレーショナルエクセレンス（Operational Excellence）: パッチ・バックアップ・高可用性をプラットフォームに任せ、SQL Agent ジョブで既存運用を継続できる。監視は Azure Monitor と Query Store に集約する
• セキュリティ: 仮想ネットワーク分離、TDE、Entra ID 認証、Defender for SQL を組み合わせて多層防御を構成する
• コスト最適化: 予約容量と Azure Hybrid Benefit、インスタンスプールで定常コストを抑える

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

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

# 仮想ネットワークと専用サブネットを作成
az network vnet create \
  --name demo-vnet \
  --resource-group demo-rg \
  --location japaneast \
  --address-prefix 10.0.0.0/16 \
  --subnet-name mi-subnet \
  --subnet-prefix 10.0.0.0/24

# サブネットをマネージドインスタンスに委任
az network vnet subnet update \
  --name mi-subnet \
  --resource-group demo-rg \
  --vnet-name demo-vnet \
  --delegations Microsoft.Sql/managedInstances

# マネージドインスタンスを作成（General Purpose / Gen5）
az sql mi create \
  --name demo-mi-0614 \
  --resource-group demo-rg \
  --location japaneast \
  --subnet mi-subnet \
  --vnet-name demo-vnet \
  --admin-user miadmin \
  --admin-password 'StrongP@ssw0rd!' \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 4 \
  --storage 256

# インスタンス内にデータベースを作成
az sql midb create \
  --resource-group demo-rg \
  --managed-instance demo-mi-0614 \
  --name appdb