Amazon RDS で運用するマネージドデータベース - Multi-AZ とリードレプリカの設計
Multi-AZ で高可用性を確保し、リードレプリカで読み取り負荷を分散する。Blue/Green Deployments と RDS Proxy の活用パターンを紹介します。
RDS の概要
RDS はリレーショナルデータベースをマネージドに提供するサービスです。EC2 にデータベースをインストールする場合と比較して、OS パッチ、DB パッチ、バックアップ、フェイルオーバーが自動化されます。サポートするエンジンは MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2 の 6 種類で、既存のコードやツールをほぼそのまま移行できます。Aurora は RDS 互換の AWS 独自エンジンで、標準の MySQL/PostgreSQL と比較して最大 5 倍のスループットを提供し、ストレージが 3 つの AZ に 6 コピーで自動複製されるため耐久性が極めて高い設計です。RDS は自動バックアップ (ポイントインタイムリカバリ) を標準で提供し、保持期間を 1-35 日に設定できます。手動スナップショットは保持期間の制限なく保存可能で、長期保存や別リージョンへのコピーに利用します。
Multi-AZ とリードレプリカ
Multi-AZ 配置はプライマリインスタンスとスタンバイインスタンスを異なる AZ に配置し、同期レプリケーションでデータを複製します。プライマリの障害時に自動フェイルオーバーが実行され、DNS エンドポイントがスタンバイに切り替わります。フェイルオーバーは通常 1-2 分で完了しますが、大量のトランザクションが未コミットの場合はリカバリに時間がかかることがあります。Multi-AZ Cluster (MySQL と PostgreSQL で利用可能) は 2 つのリーダーインスタンスを異なる AZ に配置し、フェイルオーバーを 35 秒未満に短縮すると同時に、リーダーインスタンスからの読み取りも可能にします。リードレプリカは非同期レプリケーションで読み取り専用のコピーを作成し、レポートクエリや分析クエリをリードレプリカに向けることでプライマリの負荷を軽減します。同一リージョンに最大 15 台、クロスリージョンにも配置可能で、災害復旧や地理的に分散した読み取りアクセスの最適化に活用できます。Performance Insights はデータベースの負荷を待機イベント別、SQL 別に可視化し、スロークエリやロック競合を特定します。
Blue/Green デプロイとプロキシ
RDS Blue/Green Deployments はメジャーバージョンアップグレードやパラメータ変更を安全に実行します。グリーン環境 (新バージョン) を作成し、レプリケーションでデータを同期した後、スイッチオーバーで 1 分以内にトラフィックを切り替えます。スイッチオーバー後に問題が検出された場合、旧環境はまだ残っているため手動で切り戻しが可能です。RDS Proxy はデータベース接続のプーリングとフェイルオーバーの高速化を提供します。Lambda のような短命な接続が大量に発生するワークロードで、データベースの接続数を削減し、フェイルオーバー時の接続切り替えを自動化します。Proxy はアイドル接続を再利用するため、RDS インスタンスの max_connections 上限に達するリスクを軽減します。Proxy のエンドポイントに接続するだけでアプリケーションコードの変更は不要で、IAM 認証や Secrets Manager との統合で認証情報のローテーションも自動化できます。 マネージド DB の基礎から応用まで、書籍 (Amazon)で体系的に学べます。
RDS の料金最適化
RDS の料金はインスタンス時間、ストレージ (gp3: 1 GB あたり月額約 0.08 ドル)、バックアップストレージ、データ転送で構成されます。リザーブドインスタンスで最大 72% の割引が適用されます。Multi-AZ はスタンバイインスタンスの料金が追加されるため、可用性要件に応じて選択します。gp3 ストレージは gp2 より 20% 安価で、IOPS とスループットを独立して設定できます。リードレプリカで読み取り負荷を分散し、プライマリインスタンスのサイズダウンを検討します。
Aurora との比較と使い分け
RDS の標準エンジン (MySQL/PostgreSQL) と Aurora のどちらを選ぶかは、コスト構造とスケール要件で判断します。Aurora はストレージが自動拡張 (最大 128 TiB) で IOPS の事前設定が不要なため、成長が予測しづらいワークロードに適しています。一方、RDS 標準エンジンの gp3 ストレージは GB 単価が安く、ベースライン IOPS 3,000 で十分な小中規模のデータベースではコスト優位です。フェイルオーバー時間は Aurora が 30 秒未満、RDS Multi-AZ が 1-2 分、RDS Multi-AZ Cluster が 35 秒未満です。Aurora のリーダーエンドポイントは複数リーダーへの負荷分散を自動で行いますが、RDS のリードレプリカではアプリケーション側またはロードバランサーで振り分ける必要があります。コスト面では Aurora のインスタンス単価が RDS より高いため、小規模で可用性要件が緩いシステムには RDS 標準エンジン + Multi-AZ が最適解になることが多いです。
設計の落とし穴と運用上の注意点
RDS 運用で陥りがちな問題をまとめます。第一に、パラメータグループの変更適用タイミングです。dynamic パラメータは即時適用されますが、static パラメータは DB インスタンスの再起動が必要で、再起動中はダウンタイムが発生します。本番環境では Blue/Green Deployments でパラメータ変更を安全に適用すべきです。第二に、ストレージの自動拡張 (autoscaling) を有効にしていても、拡張にはクールダウン期間があり、急激なデータ増加で空き容量が枯渇する場合があります。CloudWatch の FreeStorageSpace メトリクスにアラームを設定し、残容量が 20% を切った時点で通知を受け取る設計が推奨されます。第三に、リードレプリカのラグ (ReplicaLag) が増大するとデータの一貫性が損なわれます。長時間実行される DDL 操作やバックアップウィンドウ中のラグ増大に注意し、レプリカラグが閾値を超えた場合にアプリケーション側でプライマリにフォールバックする仕組みを設計します。第四に、メンテナンスウィンドウの設定で、トラフィックが最も低い時間帯を選択し、Multi-AZ 構成でもフェイルオーバーによる短時間の切断が発生することを想定した設計が必要です。
まとめ
RDS はリレーショナルデータベースの運用を自動化するマネージドサービスです。Multi-AZ で高可用性を確保し、リードレプリカで読み取り負荷を分散します。Blue/Green Deployments でメジャーバージョンアップグレードを安全に実行し、RDS Proxy で Lambda からの大量接続をプーリングします。Aurora との使い分けはコスト構造とスケール要件で判断し、パラメータグループ・ストレージ・レプリカラグの運用上の注意点を押さえることで、安定したデータベース基盤を維持できます。