Amazon RDS の可用性、耐久性、スケーラビリティ ​

AWS のクラウドデータベース、特に Amazon RDS を利用する上で、サービスの信頼性、継続性、そして変化する負荷への対応能力は極めて重要です。本記事では、RDS が提供する可用性、耐久性、およびスケーラビリティを実現するための主要な機能と、その仕組みについて詳しく解説します。

RDS の可用性と耐久性 ​

RDS は、基盤となる AWS グローバルインフラストラクチャを活用し、データベースの高い可用性と耐久性を実現します。

AWS リージョンとアベイラビリティーゾーン (AZ) の活用 ​

AWS は、互いに地理的に離れたリージョンと、各リージョン内のアベイラビリティーゾーン (AZ) という概念でグローバルインフラストラクチャを構成しています。各 AZ は、独立した電源、ネットワーク、冷却システムを持つ分離されたデータセンターの集まりであり、単一の AZ 障害が他の AZ に影響を与えないように設計されています。

マルチ AZ 配置による高可用性 ​

マルチ AZ 配置は、本稼働環境のデータベースに推奨されるデプロイモデルです。

マルチ AZ DB インスタンスデプロイ ​

これは、プライマリ DB インスタンスが1つの AZ に配置され、同期レプリケーションによって別の AZ にスタンバイレプリカが自動的にプロビジョニングされ、維持される構成です。このスタンバイレプリカは読み取りトラフィックを処理しませんが、プライマリインスタンスに問題が発生した場合のフェイルオーバーサポートを提供します。

利点:

  • データの冗長性
  • 自動フェイルオーバー
  • I/O フリーズの排除
  • システムバックアップ中のレイテンシースパイクの最小化

フェイルオーバー: インフラストラクチャの欠陥による計画的または計画外の停止が発生した場合、RDS は自動的にスタンバイレプリカに切り替わります。フェイルオーバー時間は、データベースアクティビティやトランザクションの規模によって異なりますが、通常は60～120秒です。ユーザーは DB イベントサブスクリプションを設定することで、フェイルオーバー開始を通知で受け取ったり、RDS コンソールや API で現在の状態を確認したりできます。

コスト: マルチ AZ 配置は追加のリソースを使用するため、シングル AZ 配置と比較してコストが高くなります。コンピューティングコストとストレージコストがプライマリとスタンバイの両方で発生し、データ転送コストも発生する場合があります。

マルチ AZ DB クラスターデプロイ ​

これは、単一のライター DB インスタンスと2つのリーダー DB インスタンスを同じ AWS リージョン内の3つの異なる AZ に配置する構成です。3つの DB インスタンスすべてが読み取りトラフィックを処理できる点が、マルチ AZ DB インスタンスデプロイとの大きな違いです。MySQL と PostgreSQL エンジンでサポートされています。

バックアップと復旧 ​

Amazon RDS は、データベースの耐久性を確保するために、堅牢なバックアップ機能を提供します。

自動バックアップ ​

RDS は、ユーザーが指定したバックアップ保持期間に基づいて、DB インスタンスの自動バックアップを有効にできます。これらのバックアップは、効率的で信頼性の高いデータベース復元を可能にします。

手動スナップショット ​

ユーザーは手動でデータベーススナップショットを作成することも可能です。

クロスリージョン自動バックアップ ​

災害復旧対策として、別の AWS リージョンに自動バックアップをレプリケートする機能を有効にできます。これは、RDS for Db2 を除く主要なデータベースエンジンで利用可能です。

バックアップストレージの課金 ​

バックアップストレージは、自動データベースバックアップとアクティブなデータベーススナップショットに関連付けられています。保持期間を延長したり、スナップショットを追加したりすると、バックアップストレージの消費量が増加し、それに応じて課金されます。

専用ログボリューム (DLV) ​

DLV は、PostgreSQL のトランザクションログ、MySQL/MariaDB の REDO ログおよびバイナリログを、データベーステーブルのボリュームとは別のストレージボリュームに移動させる機能です。これにより、トランザクション書き込みロギングの効率と一貫性が向上します。I/O 要求の高い、または遅延に敏感なワークロードを持つ大規模データベースに最適です。DLV はプロビジョンド IOPS (io1 および io2 Block Express) ストレージでサポートされており、汎用ストレージ (gp2 および gp3) ではサポートされていません。

RDS のスケーラビリティ ​

RDS は、変化するワークロード要件に合わせてデータベースを柔軟にスケールアップ・スケールアウトする機能を提供します。

リードレプリカによる読み取りスケーリング ​

リードレプリカは、ソース DB インスタンスの読み取りトラフィックをオフロードし、データベースの全体的なパフォーマンスを向上させるために使用されます。

仕組み ​

リードレプリカは、ソース DB インスタンスのスナップショットから作成され、プライマリ DB インスタンスからの変更を非同期レプリケーションで更新します。リードレプリカは読み取り専用の接続のみを許可します（ただし、Db2 と Oracle のレプリカはスタンバイ/マウントモードであり、読み取りトラフィックを受け付けません。これらは主にクロスリージョンの災害復旧目的です）。

クロスリージョンリードレプリカ ​

リードレプリカは、プライマリ DB インスタンスとは異なる AWS リージョンに配置することも可能です。これにより、地理的な分散によるレイテンシーの削減や災害復旧能力の向上が期待できます。クロスリージョンレプリケーションの場合、RDS は安全な通信チャネルを自動的に設定します。

管理とモニタリング ​

  • スケーリング: RDS はリードレプリカの自動スケーリングをサポートしていません。ユーザーが手動で作成・管理する必要があります。
  • 昇格: リードレプリカをスタンドアロンの DB インスタンスに昇格させることもできます。これは、プライマリ DB インスタンスに障害が発生した場合の災害復旧スキームとして利用できます。
  • モニタリング: Amazon CloudWatch の ReplicaLag メトリクスを使用して、レプリケーションの遅延をモニタリングできます。遅延が大きい場合、書き込みワークロードの調整やリーダーインスタンスのリソース最適化が必要になることがあります。
  • コスト: リードレプリカは、ソース DB インスタンスと同じレートで、標準の DB インスタンスとして課金されます。

DB インスタンスクラスの変更 (垂直スケーリング) ​

DB インスタンスクラスは、DB インスタンスに割り当てられるコンピューティング（CPU）とメモリの容量を決定します。ワークロードの要件に応じて、DB インスタンスクラスを後から変更し、スケールアップすることが可能です。

インスタンスクラスタイプ ​

  • 汎用 (db.m*): 幅広いワークロードに対応するバランスの取れた性能を提供します。db.m8g のような最新世代は Graviton4 プロセッサを搭載しています。
  • メモリ最適化 (db.r*, db.x*, db.z*): メモリを大量に消費するアプリケーションに最適です。db.r7g や db.x2g はそれぞれ Graviton3/2 プロセッサを搭載しています。db.z1d は高周波数 CPU を提供します。
  • コンピューティング最適化 (db.c*): 計算集約型ワークロードに適しており、高い CPU 性能を提供します。db.c6gd は Graviton2 プロセッサとローカル SSD ストレージを提供します。
  • バースト可能パフォーマンス (db.t*): ベースライン性能を持ちつつ、必要に応じて CPU をバーストさせることができ、開発/テスト環境や低〜中程度のワークロードに適しています。db.t4g は Graviton2 プロセッサを搭載し、Unlimited モードでバースト可能です。

パフォーマンスのモニタリング ​

ReadIOPS メトリクスを確認し、作業セットがメモリ内に収まっているかを確認することで、適切な RAM 容量を判断できます。CPU や I/O に問題がある場合、より大きなインスタンスクラスにアップグレードすることが推奨されます。

旧世代インスタンスの終了 ​

db.m4, db.m3, db.r4, db.r3, db.t2 などの旧世代インスタンスクラスは、サポート終了プロセスが進んでおり、自動アップグレードが推奨または実行されています。

DB インスタンスストレージのスケーリング ​

RDS は、データベースとログの保存に Amazon Elastic Block Store (EBS) ボリュームを使用します。ストレージは、ワークロードの特性に合わせて選択・調整できます。

ストレージタイプ ​

汎用 SSD (gp2, gp3) ​

コスト効率が高く、幅広いワークロードに適しています。gp3 はストレージ容量とは独立して IOPS とスループットをカスタマイズできるため、推奨されています。gp2 はストレージ容量に応じて IOPS 性能が決まります。

プロビジョンド IOPS (PIOPS) SSD (io1, io2 Block Express) ​

低レイテンシーで一貫した I/O スループットが必要な I/O 集約型ワークロード、特に本稼働環境のデータベースに最適です。io2 Block Express が推奨されています。ユーザーは IOPS レートとボリュームサイズを指定し、RDS はその IOPS レートを保証します。

マグネティック (廃止) ​

下位互換性のためにサポートされていますが、新規デプロイでは SSD の使用が推奨されます。

ストレージ容量の増加 ​

既存の DB インスタンスのストレージは必要に応じてスケールアップできます。ストレージ容量を減らすことはできません。

ストレージの自動スケーリング ​

予測不能なワークロードに対応するため、RDS のストレージ自動スケーリングを有効にできます。使用可能な空き領域が10%未満の状態で5分以上続くと、自動的にストレージがスケールアップされます。ただし、大量のデータロードによるストレージ不足を完全に防ぐことはできず、磁気ストレージでは利用できません。

Dedicated Log Volume (DLV) ​

上述の通り、PIOPS ストレージ使用時にログを分離することで書き込みパフォーマンスを向上させます。

I/O を大量に消費するストレージの変更 ​

一部のストレージ変更（マグネティックからの移行、特定の古いレイアウトからの変更、大規模な容量増加など）は、データのフルコピーを伴い、I/O を大量に消費する可能性があります。このような操作は、ピーク時間帯を避けてスケジュールすることが推奨されます。

データベースエンジンのアップグレード ​

セキュリティ、パフォーマンス、コンプライアンスを維持するために、データベースエンジンのバージョンを定期的にアップグレードすることが推奨されます。RDS は、セキュリティパッチや機能強化を含む新しいマイナーバージョンとメジャーバージョンをリリースします。

アップグレードの種類 ​

マイナーバージョンアップグレード ​

自動アップグレードを有効にすることで、パッチ適用が容易になります。

メジャーバージョンアップグレード ​

アプリケーションの互換性をテストし、計画的なアップグレード期間を設定することが重要です。

ブルー/グリーンデプロイ ​

MySQL、PostgreSQL、MariaDB では、データベースの更新（メジャー/マイナーバージョンアップグレード、スキーマ変更、インスタンスクラス変更など）に必要なダウンタイムを最小限に抑えるために、ブルー/グリーンデプロイを使用できます。これは、現在の本稼働環境（ブルー環境）を複製したステージング環境（グリーン環境）を作成し、グリーン環境で変更を適用・テストした後、切り替え（スイッチオーバー）を行うことで、短時間で本稼働環境を更新する機能です。

RDS 延長サポート ​

古いメジャーバージョンのデータベースエンジンを、標準サポート終了後も継続して利用するためのオプションです。

RDS のモニタリングツール ​

RDS は、データベースのパフォーマンスとヘルス状態を追跡するための多様なモニタリングツールを提供します。これらは、可用性とスケーラビリティの維持に不可欠です。

Amazon CloudWatch ​

DB インスタンスのパフォーマンスやヘルス状態をモニタリングできます。RDS は、アクティブな各データベースのメトリクスを1分ごとに CloudWatch に自動送信し、追加料金は発生しません。CPU 使用率、IOPS、レプリカ遅延などを監視し、アラームを設定できます。

Performance Insights ​

DB インスタンスの負荷をモニタリングし、データベースパフォーマンスの分析とトラブルシューティングを行うのに役立ちます。問題のあるクエリを特定し、チューニングの推奨事項を提供できます。Performance Insights は2025年11月30日にサポート終了が発表されており、CloudWatch Database Insights の Advanced モードへのアップグレードが推奨されています。

拡張モニタリング ​

オペレーティングシステム（OS）レベルのメトリクスを詳細にモニタリングできます。

イベント、ログ、およびデータベースアクティビティストリーミング ​

イベント ​

RDS イベントをモニタリングすることで、DB インスタンスのステータス変更や重要な操作に関する通知を受け取ることができます。

ログ ​

データベースログファイル（Db2, MariaDB, SQL Server, MySQL, Oracle, PostgreSQL）の表示、リスト化、ダウンロード、CloudWatch Logs への発行が可能です。

データベースアクティビティストリーミング ​

Oracle および SQL Server データベース内の監査活動を監視し、アラームを設定できます。Db2, MariaDB, MySQL, PostgreSQL では利用できません。

CloudTrail ​

RDS API コールの履歴をモニタリングできます。

GuardDuty RDS Protection ​

RDS データベース内の脅威をモニタリングするサービスです。

まとめ ​

Amazon RDS の可用性、耐久性、スケーラビリティ機能を理解し、適切に活用することで、以下のメリットを得ることができます：

可用性の向上 ​

  • マルチ AZ 配置による自動フェイルオーバー
  • 60-120秒の短時間でのフェイルオーバー実現
  • 複数の AZ を活用した高可用性構成

耐久性の確保 ​

  • 自動バックアップとスナップショット機能
  • クロスリージョンバックアップによる災害復旧
  • 専用ログボリューム（DLV）による書き込みパフォーマンス向上

スケーラビリティの実現 ​

  • リードレプリカによる読み取りスケーリング
  • インスタンスクラスの柔軟な変更
  • ストレージの自動スケーリング
  • ブルー/グリーンデプロイによる無停止アップグレード

包括的なモニタリング ​

  • CloudWatch による詳細なメトリクス監視
  • Performance Insights による性能分析
  • 拡張モニタリングによる OS レベルの監視

これらの機能とツールを適切に組み合わせることで、AWS 環境における RDS データベースの可用性、耐久性、およびスケーラビリティを最大限に引き出し、ビジネス要件を満たす信頼性の高いデータベースインフラストラクチャを構築・運用できるでしょう。

参考リンク ​

関連記事: Amazon RDS の特徴整理