クラウドマネージドデータベース (RDS/Aurora/Cloud SQL/Atlas/Azure SQL)
症状
目標: クラウドマネージドデータベースとセルフマネージドのインストールの主な違いを学び、クラウドでバックアップ、パラメータ、フェイルオーバー、監視、アップグレード、接続がどのように機能するかを理解する。
1. 考え方の転換: アクセスするのはサーバーではなくサービス
マネージドデータベースでは、OS、ファイルシステム、データベースプロセスへのシェルアクセスはない。SSH でのログイン、構成ファイルの手動編集、スーパーユーザー化はできない。得られるのはプロバイダーの管理 API/コンソールと通常の SQL 接続のみである。AWS RDS/Aurora: 管理はリソース (インスタンス/クラスタ) レベルで、サーバーは隠されている。GCP Cloud SQL: インスタンス API のみで OS はない。MongoDB Atlas: フルマネージドのクラスタで、mongod へのアクセスはない。Azure SQL Database: PaaS で、下層のサーバーも OS も見えない (Managed Instance ではやや多くの制御が可能)。そのため「ファイルを見る」「プロセスを強制終了する」「OS ツールを実行する」といったセルフマネージドでの反射的な対応の多くは通用しない。
2. バックアップ: 自動スナップショット + ポイントインタイムリカバリ (PITR)
バックアップをスケジュールする必要はなく、プロバイダーが自動的に取得する。復旧は通常「特定の時点へのリストア」(PITR) またはスナップショットからの新規インスタンス作成であり、既存のインスタンスは上書きされない。AWS RDS/Aurora: 自動バックアップ + 保持期間。秒単位の精度での PITR リストアは新しいインスタンス/クラスタとして開かれる。手動スナップショットも可能。GCP Cloud SQL: 自動バックアップ + バイナリログによる PITR。リストアは新しいインスタンスに行われる。MongoDB Atlas: 継続的なクラウドバックアップ + PITR (M10+)。スナップショットからのリストア。Azure SQL: 組込みの自動バックアップ、1-35 日の保持、任意の時点への PITR と削除された DB のリストア。共通ルール: バックアップ構成 (ウィンドウ、保持期間) を確認し、定期的にリストアテストを行う。
3. パラメータ: 構成ファイルではなくパラメータグループ / フラグ
postgresql.conf や my.cnf を手動で編集する代わりに、プロバイダーのパラメータ抽象化を使う。一部のパラメータはロックされており、一部は再起動が必要 (静的) である。AWS RDS/Aurora: DB パラメータグループ (およびクラスタパラメータグループ) で設定する。動的パラメータは即座に、静的パラメータは再起動時に適用される。GCP Cloud SQL: 「データベースフラグ」をコンソール/gcloud から設定する。MongoDB Atlas: 限定的な「Additional Settings」+ oplog サイズなど。内部パラメータの大半は管理対象。Azure SQL: サーバーレベルの設定の大半は管理対象で、SCOPED CONFIGURATION とサービス階層の選択で動作が変わる。適用前に、パラメータが動的か静的かを確認する。
4. 高可用性 / フェイルオーバー: マネージドの Multi-AZ とレプリカ
フェイルオーバーを自分で構築するのではなく、チェックボックスをオンにしてプロバイダーに任せる。スタンバイと自動フェイルオーバーは管理され、接続は安定したエンドポイントを通じて新プライマリにリダイレクトされる。AWS RDS: Multi-AZ (同期スタンバイ、自動フェイルオーバー)。Aurora: マルチコピーストレージ + 自動フェイルオーバー、クラスタエンドポイントはライターを指す。GCP Cloud SQL: ワンクリックの HA 構成 (リージョナル、セカンダリゾーンにスタンバイ)。読み取りレプリカは別途追加する。MongoDB Atlas: レプリカセットが組込みで、マルチリージョン/マルチクラウドのデプロイが可能、フェイルオーバーは自動。Azure SQL: 組込みの HA (Business Critical ではローカルレプリカ)、ゾーン冗長オプション、リージョン間のアクティブ geo レプリケーション / フェイルオーバーグループ。アプリケーションは常にエンドポイントに接続し、固定 IP には決して接続しないこと。
5. 監視: プロバイダーのメトリクスとログサービス
OS ツール (top、iostat) を実行できないため、プロバイダーのメトリクスプラットフォームで監視する。CPU、接続数、IOPS、レプリケーションラグ、ストレージのメトリクスはそこにある。AWS: CloudWatch メトリクス + Enhanced Monitoring + Performance Insights (クエリレベルの分析)。GCP Cloud SQL: Cloud Monitoring (旧 Stackdriver) + Query Insights。MongoDB Atlas: 組込みの Atlas メトリクス/チャート + Performance Advisor + リアルタイムパネル。Azure SQL: Azure Monitor + SQL Analytics + Query Performance Insight。しきい値アラーム (ストレージ使用量、CPU、接続数上限、レプリカラグ) を必ず設定する。
6. バージョンアップグレードとメンテナンス: コンソールから、メンテナンスウィンドウ内で
バイナリを手動で更新する代わりにターゲットバージョンを選ぶ。マイナーバージョンのパッチはほぼ自動で、メジャーバージョンのアップグレードは計画的に行い、通常はダウンタイム/HA フェイルオーバーを伴う。AWS RDS/Aurora: エンジンバージョンの選択 + 自動マイナーアップグレードのオプション + Blue/Green Deployments による低リスクのメジャーアップグレード。GCP Cloud SQL: メンテナンスウィンドウ + セルフサービスのメジャーバージョンアップグレード。MongoDB Atlas: ワンクリックのバージョンアップグレード、ローリング方式でほぼ無停止。Azure SQL: プラットフォームが自動的にパッチを適用する (バージョンの概念はほぼ抽象化されている)。動作は互換性レベルで制御する。必ずまずテスト/ステージングのコピーで試し、メンテナンスウィンドウは業務時間外にスケジュールする。
7. 接続とセキュリティ: エンドポイント + IAM/TLS
接続は常にプロバイダーが提供する DNS エンドポイントを経由し、暗号化される (TLS)。ネットワークアクセスと ID はクラウドの ID システムに結び付けられる。AWS RDS/Aurora: インスタンス/クラスタエンドポイント + ネットワーク用の Security Group + 任意の IAM データベース認証 + TLS (rds-ca 証明書)。GCP Cloud SQL: パブリック IP + Authorized Networks またはプライベート IP/VPC、Cloud SQL Auth Proxy、IAM データベース認証、TLS。MongoDB Atlas: SRV 接続文字列 (mongodb+srv://)、IP アクセスリスト + プライベートエンドポイント/ピアリング、SCRAM または IAM/X.509、TLS 必須。Azure SQL: サーバー FQDN エンドポイント + ファイアウォール/Private Link + Microsoft Entra ID (旧 Azure AD) 認証 + TLS 必須。ルール: 接続文字列には固定 IP ではなくエンドポイントを使い、TLS を強制し、可能な場合はクラウドの IAM ID で接続する。