Relational Database Platformを再設計する

1. データベース選択は互換性と管理境界から始める

既存のリレーショナルデータベースをAWSへ移行するときは、単に「マネージドサービスへ移せるか」だけで判断しません。

まず確認するのは、既存データベースが何に依存しているかです。

既存データベース
        │
        ├─ データベースエンジン / バージョン
        ├─ 拡張機能
        ├─ パラメータ
        ├─ 認証方式
        ├─ バックアップ / 復元方式
        └─ 運用ツール
        │
        ▼
移行先で必要な互換性を満たせるか
        │
        ▼
どこまでの管理権限が必要か
        │
        ▼
EC2 / Amazon RDS / Amazon Aurora

重要なのは、エンジン名が同じことと、既存環境をそのまま移行できることは同義ではないという点です。

2. EC2上のセルフマネージドデータベースでは制御範囲が広い

Amazon EC2上にデータベースを構築すると、利用者はOSからデータベースソフトウェアまで広い範囲を管理できます。

例えば、次のような作業を利用者側で制御できます。

• OSの設定
• OSパッケージの導入
• データベースソフトウェアの導入
• データベースソフトウェアのバージョン管理
• データベースバイナリへの製品固有パッチ適用
• ファイルシステム構成
• データベースの設定ファイル
• OS上で動作する監視・バックアップツール
• データベース固有の拡張機能

特に、既存環境で特定のデータベースバイナリ、製品固有パッチ、アップグレード順序そのものを利用者が管理し続ける必要がある場合は、マネージドサービスへ委譲できる管理範囲との違いを確認する必要があります。

3. 制御の自由度と引き換えに運用責任も増える

EC2上でデータベースをセルフマネージドする場合、制御範囲が広い一方、その範囲の運用責任も利用者が持ちます。

代表的な作業には次があります。

• OSのパッチ適用
• データベースソフトウェアのパッチ適用
• バックアップ設計
• 復旧手順の管理
• データベースプロセスの監視
• 障害発生時の復旧
• 可用性構成の設計と運用

そのため、EC2を選択するときは「自由度が高い」という利点だけでなく、その自由度を維持するために継続して引き受けるデータベース運用まで考える必要があります。

4. Amazon RDSは一般的なデータベース管理作業をAWSへ委譲する

Amazon RDSはリレーショナルデータベースをマネージドサービスとして提供します。

利用者がEC2上で直接管理していた作業のうち、基盤側の多くをAWSへ委譲できます。

代表例は次のとおりです。

• 基盤となるコンピューティング環境の管理
• OSの管理
• データベースソフトウェアのインストール
• サービスとして提供されるパッチ管理
• バックアップ機能
• 障害時の基盤側復旧

さらにMulti-AZ構成を利用する場合は、AWSがスタンバイのプロビジョニングと維持、障害時のフェイルオーバーに必要な基盤処理を管理します。

したがってAmazon RDSでは、データベース管理者が管理する対象を「サーバそのもの」から「データベースとアプリケーションに近い領域」へ寄せることができます。

5. Amazon RDSでも利用者のデータベース責任は残る

Amazon RDSを利用しても、データベースに関するすべての作業をAWSが担当するわけではありません。

利用者側には、例えば次の責任が残ります。

• スキーマ設計
• テーブル設計
• インデックス設計
• クエリの最適化
• データベースユーザーと権限の管理
• アプリケーションからの接続設計
• ワークロードに応じたDBインスタンスの選択
• 必要なデータベースパラメータの設定

Multi-AZを構成してAWSがフェイルオーバー基盤を管理していても、アプリケーション側で必要となる接続の再確立や再試行までAWSが自動的に設計するわけではありません。

AWS
├─ 基盤
├─ OS
├─ サービスとしてのデータベースソフトウェア管理
└─ Multi-AZ時のスタンバイ / フェイルオーバー基盤

利用者
├─ スキーマ
├─ インデックス
├─ クエリ
├─ データベースユーザー / 権限
├─ パラメータ
└─ アプリケーション接続 / 再試行

6. 標準的なAmazon RDSでは基盤OSを直接管理しない

標準的なAmazon RDSでは、利用者は基盤ホストへログインしてOSを直接管理する方式を取りません。

そのため、既存データベースの運用処理が次のような実装へ依存している場合は、移行前に依存関係を分解します。

既存方式
OS上のスクリプト
        │
        ├─ 本当にOSアクセスそのものが要件か
        │
        └─ 実現したいバックアップ・監視・運用結果が要件か
                       │
                       ▼
          RDSの機能へ置換可能か確認

ここでは「現在OS上で実行している」という事実だけで移行先を決めず、その処理が実現しているデータベース上の要件を確認することが重要です。

ただし、標準的なAmazon RDSとは別に、Amazon RDS CustomではOSやデータベース環境へアクセスし、利用者側でより広い範囲を管理できます。

RDS Customは任意のAmazon RDS対応エンジンで利用できるわけではなく、対象となるデータベースエンジンが限定されます。現在の主な対象はOracle DatabaseとMicrosoft SQL Serverです。

したがって、標準的なAmazon RDSでは管理範囲が不足する場合も、

必要な管理範囲
      │
      ▼
RDS Customの対象エンジンか
      │
      ├─ 対象
      │   └─ RDS Customも候補
      │
      └─ 対象外
          └─ EC2上のセルフマネージド構成などを検討

のように、必要な制御範囲だけでなく、対象エンジンまで含めて候補を判断する必要があります。

7. Amazon AuroraはMySQL / PostgreSQL互換のマネージドリレーショナルデータベース

Amazon Auroraは、MySQL互換またはPostgreSQL互換のリレーショナルデータベースです。

ここで重要なのはAuroraの内部アーキテクチャではなく、既存データベースがAuroraという移行先候補の互換性境界へ収まるかを判断することです。

例えば、現在利用しているエンジンをそのまま維持することが必須で、そのエンジンがAuroraの互換対象ではない場合、エンジンを維持したままAuroraへ移すことはできません。

一方で、MySQLまたはPostgreSQL系のワークロードでは、必要な機能がAuroraで利用できることを確認したうえで移行先候補とします。

8. Auroraは「すべてのRDSより上位」のデータベースではない

Amazon RDSとAmazon Auroraは単純な上下関係ではありません。

Amazon RDSでは複数のリレーショナルデータベースエンジンを利用できます。一方、AuroraはMySQL互換またはPostgreSQL互換を前提とします。

そのため、複数の既存データベースをAWSへ移す場合でも、

Auroraを利用できる
        ↓
すべてAuroraへ統一する

とは判断しません。

例えば、既存エンジンを維持する必要がありAmazon RDSでそのエンジンが提供されている場合には、Amazon RDSが候補となります。

一方、MySQLまたはPostgreSQL系のワークロードがAuroraの互換性境界に収まり、その選択が要件に適合する場合にはAuroraを候補として評価します。

9. 互換性確認の結果を移行先選択へ反映する

既存データベースと移行先の互換性は、エンジン名だけでなく、使用している機能や設定まで確認した結果を前提とします。

ここでは互換性確認の詳細を繰り返すのではなく、必要な互換性が成立する候補だけを残し、その候補間で管理境界と運用負荷を比較することに集中します。

互換性を満たす候補
        │
        ▼
必要な管理境界を満たすか
        │
        ▼
運用負荷を比較
        │
        ▼
移行先を選択

10. 互換性が成立した後に運用負荷を比較する

移行先候補を比較するとき、運用負荷は重要な判断材料になります。

ただし、運用負荷だけを先に比較するのではありません。

互換性
  ↓
必要機能が成立
  ↓
管理境界を確認
  ↓
運用負荷を比較

例えば、Amazon RDSへ移行することでOSやデータベースソフトウェアの管理を減らせても、必要な機能を満たせなければ、その候補はそのまま採用できません。

逆に、既存のOS上で実行していた運用処理をRDSの機能へ置き換えられる場合は、既存実装を維持するためだけにセルフマネージド構成を残す必要がないこともあります。

11. マネージド化のために必要な機能を捨てない

データベース再設計では、現在利用している「実装方法」と「本当に必要な要件」を分けて考えます。

例えば既存環境で、

cron
  ↓
ベンダー製バックアップエージェント
  ↓
特定ファイルシステムへバックアップ

という処理を行っているとします。

必要なのが「そのエージェントを動かすこと」ではなく、

必要なRPO
必要なRTO
必要な保持期間
必要な復元単位

を満たすことであれば、Amazon RDSで利用可能なバックアップ、スナップショット、エンジン固有の復元手段などで要件を実現できるかを評価します。

逆に、既存の処理そのものが業務・製品要件として必須であり代替できない場合は、その制約を移行先選択へ反映します。

12. 3つの候補を管理境界で比較する

この比較で重要なのは、「最もマネージドなものを常に選ぶ」ことではありません。

既存データベースに必要な互換性と機能を満たしたうえで、不要な運用責任をAWSへ移せる構成を選ぶことが重要です。

13. 判断フロー

既存リレーショナルデータベース
        │
        ▼
エンジン / バージョンを確認
        │
        ▼
拡張機能 / パラメータ /
認証 / バックアップ /
アプリケーション依存関係を確認
        │
        ▼
移行先で互換性が成立するか
        │
        ├─ 不成立
        │   └─ 別の候補または再設計を検討
        │
        └─ 成立
            │
            ▼
       必要な管理境界を確認
            │
            ├─ データベースソフトウェアまで
            │   自己管理する必要がある
            │          ↓
            │   RDS Customの対象可否も確認
            │          │
            │          ├─ 対象
            │          │   └─ RDS Customも候補
            │          │
            │          └─ 対象外
            │              └─ EC2上の
            │                 セルフマネージド
            │                 データベースを検討
            │
            └─ AWSへ委譲可能
                       │
                       ▼
             Amazon RDS / Aurora
                       │
                       ▼
          データベース固有要件を比較
                       │
                       ▼
               運用負荷を比較
                       │
                       ▼
             移行先を選択

試験では、単に「RDSは運用が楽」「EC2は自由」と覚えるのではなく、

互換性
+
データベース固有の依存関係
+
管理責任

を分解して判断します。