Azure Database for MariaDB

解決する課題

• MariaDB サーバーの OS パッチ・マイナーバージョン更新・バックアップが重い → マネージドで自動化したかった
• 障害でデータベースが止まると困る → 組み込みの高可用性とバックアップで可用性を上げたかった
• 既存の MariaDB アプリ（各種 OSS、CMS など）をほぼ無改修でクラウドに移したかった

このサービスは MariaDB エンジンの互換性を保ったまま運用を肩代わりするマネージド PaaS でした。ただし現在は提供を終了しており、新規構築には使えません。これから MariaDB 互換のワークロードを Azure で動かす場合は、後述の移行先を前提に設計してください。

主要概念と用語

• マネージド MariaDB（PaaS）: MariaDB エンジンをサービス側が運用し、ユーザーはデータベースとアプリに集中できる提供形態
• コンピューティング階層: 用途別の階層構成。小規模・断続負荷向けのバースト可能な階層、本番の標準となる汎用階層、高負荷向けのメモリ最適階層といった分け方
• 自動バックアップ: 定期的に自動取得されるバックアップ。保持期間内であれば任意時点へ復元できる
• ポイントインタイムリストア（PITR）: 自動バックアップを使い、保持期間内の任意の時点へ復元する機能
• 読み取りレプリカ: 非同期レプリケーションで読み取り負荷を分散するためのレプリカ
• 退役（リタイア）: サービスの提供を終了するライフサイクル上の段階。新規作成停止 → 既存サーバーの停止という流れで進む
• 移行先: 退役に伴う推奨の移行ターゲット。本サービスでは Azure Database for MySQL フレキシブルサーバー

仕様・制限・クォータ

• 新規作成は不可: 退役済みのため、新しい MariaDB サーバーは作成できない。これが最大の制約
• 対応していた MariaDB バージョンは主要なメジャー系列に限られ、最新のメジャーバージョンには追随していなかった
• 自動バックアップと PITR: 保持期間内であれば任意時点への復元に対応していた。保持期間は一定の範囲内で設定可能だった
• 接続数の上限はコンピューティングサイズ（メモリ）に比例して決まる構成だった
• リージョンやサブスクリプションごとにクォータがあり、必要に応じて引き上げ申請する形だった

具体的な対応バージョン・保持日数・退役の正確な日付は変動・確定情報のため、最新値は公式ドキュメントで確認してください。

内部の仕組み

• ストレージとコンピューティングの分離: データは耐久性のあるストレージに保持され、コンピューティングノードがその上で MariaDB エンジンを動かす。サイズ変更はコンピューティングを入れ替える形でスケールした
• 高可用性とバックアップ: 基盤側でデータを冗長化し、自動バックアップを定期取得して PITR を可能にしていた
• 読み取りレプリカ: プライマリの変更を非同期でレプリカに反映する。非同期のためレプリケーション遅延が生じうる
• メンテナンスとパッチ: マイナー更新や基盤のパッチはサービス側が適用していた。アプリ側は**接続の再試行（リトライ）**を実装しておくと、再起動時の瞬断に強くなる

設計思想は Azure Database for MySQL のマネージドサービスとほぼ共通です。MariaDB から MySQL への移行を考える際、これらの概念はそのまま読み替えられます。

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

• 新規構築では本サービスを選ばない。Azure Database for MySQL フレキシブルサーバーを前提に設計する
• 既存の MariaDB サーバーを運用中なら、退役前に移行計画を立てて実行する。検証環境で互換性を先に確認する
• 移行時はバージョン互換（MariaDB と MySQL のメジャー対応関係）を確認し、SQL や関数の差異を洗い出す
• 接続はプライベートアクセスを基本にし、パブリックアクセスは無効化するかファイアウォール規則を最小限に絞る
• 接続のたびに新規接続を張らず、コネクションプーリングでハンドシェイクの負荷と接続数を抑える

運用・監視

• 既存サーバーを退役まで運用する場合も、Azure Monitor / メトリクスで CPU・メモリ・ストレージ使用率・接続数・レプリケーション遅延を監視する
• しきい値を超えたらアラートで通知し、容量逼迫やレプリカ遅延を早期に検知する
• スロークエリログや監査ログを有効化し、重いクエリや想定外のアクセスを把握する
• バックアップからの**復元手順（PITR）**を事前にリハーサルし、目標復旧時点（RPO）を確認しておく
• 最優先の運用タスクは移行の完了。退役後はサーバーが停止・削除され、データへアクセスできなくなる点を運用計画に織り込む

コスト

• 課金は概ね コンピューティング ＋ ストレージ ＋ バックアップ ＋ ネットワーク（送信など） で構成されていた
• 断続的・小規模な負荷にはバースト可能な階層がコスト効率的だった
• 高可用性や読み取りレプリカは追加のコンピューティング/ストレージ費用が発生した
• コスト面でも、移行先の Azure Database for MySQL フレキシブルサーバーは停止/開始による課金抑制など、より柔軟な節約手段を備える

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

セキュリティ

• 保存データは保存時暗号化が既定で有効だった
• 転送時は TLS/SSL を強制でき、最小 TLS バージョンを指定できた
• ネットワークはプライベートアクセスを基本とし、パブリックアクセスはファイアウォール規則で最小化する
• 接続文字列やパスワードはコードに直書きせず、Key Vault などのシークレット管理に保管する

関連サービス・比較

最も関連の深いサービスは移行先である Azure Database for MySQL フレキシブルサーバーです。両者を比較します。

ハンズオン / CLI例

# 注意: Azure Database for MariaDB は退役済みのため、新規作成はできません。
# 既存サーバーの確認と、移行先（MySQL フレキシブルサーバー）作成の例を示します。

# 既存の MariaDB サーバーを一覧表示（移行対象の棚卸し）
az mariadb server list \
  --resource-group demo-rg \
  --output table

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

# 移行先: MySQL フレキシブルサーバーを作成（ゾーン冗長 HA を有効化）
az mysql flexible-server create \
  --name demo-mysql-target \
  --resource-group demo-rg \
  --location japaneast \
  --admin-user mysqladmin \
  --admin-password 'StrongP@ssw0rd!' \
  --tier GeneralPurpose \
  --high-availability ZoneRedundant \
  --public-access None \
  --version 8.0

# 以降はダンプ&リストア、または Database Migration Service でデータを移行する