Azure Database for MySQL

解決する課題

• MySQL サーバーの OS パッチ・マイナーバージョン更新・バックアップが重い → マネージドで自動化したい
• 障害でデータベースが止まると困る → 組み込みの高可用性で可用性を上げたい
• 既存の MySQL アプリ（WordPress、Laravel、各種 OSS など）をほぼ無改修でクラウドに移したい
• 接続を絞りたい・運用コストを抑えたい → ネットワーク統合と柔軟な停止/再開を使いたい

AWS でいう Amazon RDS for MySQL に相当するサービスで、MySQL エンジンの互換性を保ったまま運用を肩代わりするのが狙いです。

主要概念と用語

• Flexible Server（フレキシブル サーバー）: 現行の推奨デプロイ モデル。停止/開始、メンテナンス時間帯の指定、ゾーン冗長 HA、仮想ネットワーク統合などきめ細かい制御ができる
• Single Server（シングル サーバー）: 旧来のデプロイ モデル。新規構築では Flexible Server が推奨で、Single Server は段階的に役割を終える位置づけ
• コンピューティング階層: Burstable（バースト可能、小規模/断続負荷向け）／General Purpose（汎用、本番の標準）／Business Critical（メモリ最適、高負荷向け）といった用途別の階層
• ゾーン冗長 HA（高可用性）: 別の可用性ゾーンにスタンバイを配置し、障害時に自動フェイルオーバーする構成。同一ゾーン内に置く構成も選べる
• 読み取りレプリカ（Read Replica）: 非同期レプリケーションで読み取り負荷を分散するためのレプリカ
• ポイントインタイム リストア（PITR）: 自動バックアップを使い、保持期間内の任意の時点へ復元する機能
• メンテナンス ウィンドウ: パッチ適用などの計画メンテナンスを実施する曜日・時間帯を指定できる枠

仕様・制限・クォータ

• 自動バックアップ: 定期的に自動取得され、保持期間内であれば PITR で任意時点へ復元できる。保持期間は一定の範囲内で設定可能
• コンピューティングとストレージは分離してスケールでき、ストレージは拡張方向に変更しやすい一方で縮小には制約がある
• 接続数の上限はコンピューティング サイズ（vCore とメモリ）に比例して決まる
• 対応バージョンは MySQL の主要メジャー系列で、マイナー更新は計画メンテナンスで適用される
• リージョン／サブスクリプションごとに vCore 数などのクォータがあり、必要に応じて引き上げ申請ができる

具体的な日数・数値・対応バージョンは変動するため、最新値は公式ドキュメントで確認してください。

内部の仕組み

• ストレージとコンピューティングの分離: データは耐久性のあるストレージに保持され、コンピューティング ノードはその上で MySQL エンジンを動かす。サイズ変更時はコンピューティングを入れ替える形でスケールする
• 高可用性: ゾーン冗長 HA を有効にすると、別ゾーンにスタンバイ サーバーを用意し、データを同期しながら待機させる。プライマリ障害時はスタンバイへ自動フェイルオーバーし、接続文字列は同じエンドポイントのまま切り替わる
• 読み取りレプリカ: プライマリの変更を非同期でレプリカに反映する。非同期のためレプリカ側にはレプリケーション遅延が生じうる
• メンテナンスとパッチ: マイナー更新や基盤のパッチはサービス側が計画メンテナンスとして適用する。アプリ側は**接続の再試行（リトライ）**を実装しておくと、フェイルオーバーや再起動時の瞬断に強くなる

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

• 新規構築は原則 Flexible Server を選ぶ。停止/開始やゾーン冗長 HA など制御範囲が広い
• 本番では ゾーン冗長 HA を有効化し、可用性ゾーン障害に備える
• 読み取りが多いワークロードは 読み取りレプリカで参照負荷を分散する（書き込みはプライマリに集約）
• 接続は プライベート アクセス（仮想ネットワーク統合） を基本にし、パブリック アクセスは無効化するか最小限のファイアウォール規則に絞る
• 接続のたびに新規接続を張らず、コネクション プーリングでハンドシェイクの負荷と接続数を抑える
• メンテナンス ウィンドウを業務影響の少ない時間帯に設定する

運用・監視

• Azure Monitor / メトリクスで CPU・メモリ・ストレージ使用率・接続数・IOPS・レプリケーション遅延を監視する
• しきい値を超えたらアラートで通知し、容量逼迫やレプリカ遅延を早期に検知する
• スロークエリ ログや監査ログを有効化し、重いクエリや想定外のアクセスを把握する
• バックアップからの**復元手順（PITR）**を事前にリハーサルし、目標復旧時点（RPO）を確認しておく
• 計算サイズやストレージはオンラインで変更できる範囲が広いので、メトリクスを根拠に段階的にスケールする

コスト

• 課金は概ね コンピューティング（vCore 数 × 時間）＋ ストレージ ＋ バックアップ ＋ ネットワーク（送信など） で構成される
• 開発・検証など常時稼働が不要なサーバーは 停止/開始 でコンピューティング課金を抑えられる（停止中もストレージは課金される）
• 断続的・小規模な負荷には Burstable 階層がコスト効率的
• 長期に動かす本番は、前払いコミットによる予約（リザーブド）割引でコストを下げられる
• 高可用性（スタンバイ）や読み取りレプリカは追加のコンピューティング/ストレージ費用が発生する点に注意する

実際の料金は変動するため、最新の料金は公式の料金ページで見積もってください。

セキュリティ

• 保存データは保存時暗号化が既定で有効。鍵は Microsoft 管理鍵のほか、Key Vault による顧客管理鍵（BYOK）も選択できる
• 転送時は TLS/SSL を強制でき、最小 TLS バージョンを指定できる
• ネットワークは プライベート アクセス（仮想ネットワーク統合） を基本とし、パブリック アクセスはファイアウォール規則で最小化する
• 認証は MySQL ネイティブ認証に加えて Microsoft Entra ID 認証に対応し、パスワード運用を減らせる
• 接続文字列やパスワードはコードに直書きせず、Key Vault などのシークレット管理に保管する

Well-Architected の観点

• 信頼性（Reliability）: ゾーン冗長 HA で自動フェイルオーバーを構成し、PITR で時点復元できる状態にする。アプリ側に接続リトライを実装する
• 運用（Operational Excellence）: パッチとバックアップはサービスに任せ、メトリクスとアラートで状態を可視化する。メンテナンス ウィンドウを管理して計画停止の影響を制御する
• セキュリティ: プライベート アクセス、TLS 強制、Entra ID 認証、顧客管理鍵で公開面と権限を絞る
• パフォーマンス効率: 読み取りレプリカとコネクション プーリングで負荷を分散し、メトリクスを根拠に計算/ストレージをスケールする
• コスト最適化: 停止/開始、Burstable 階層、予約割引でワークロードに合わせて費用を抑える

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

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

# Flexible Server を作成（General Purpose、ゾーン冗長 HA を有効化）
az mysql flexible-server create \
  --name demo-mysql-0614 \
  --resource-group demo-rg \
  --location japaneast \
  --admin-user mysqladmin \
  --admin-password 'StrongP@ssw0rd!' \
  --tier GeneralPurpose \
  --high-availability ZoneRedundant \
  --public-access None \
  --version 8.0

# 読み取りレプリカを作成（読み取り負荷の分散）
az mysql flexible-server replica create \
  --replica-name demo-mysql-0614-rep \
  --resource-group demo-rg \
  --source-server demo-mysql-0614

# 開発用にサーバーを停止してコンピューティング課金を抑える
az mysql flexible-server stop \
  --name demo-mysql-0614 \
  --resource-group demo-rg