Amazon Aurora
MySQL の最大 5 倍、PostgreSQL の最大 3 倍のスループットを実現する AWS 独自のクラウドネイティブなリレーショナルデータベース
概要
Amazon Aurora は、AWS がクラウド向けにゼロから設計したリレーショナルデータベースエンジンです。MySQL および PostgreSQL と互換性があり、既存のアプリケーションコードやツールをほぼそのまま利用できます。ストレージは 3 つのアベイラビリティゾーンにまたがる 6 つのコピーに自動複製され、最大 128 TB まで自動拡張されます。Aurora Serverless v2 を使えば、データベースのキャパシティがワークロードに応じて自動的にスケールし、アイドル時のコストを最小化できます。リードレプリカは最大 15 個まで作成でき、フェイルオーバー時間は通常 30 秒以内です。Aurora Global Database を使えば、最大 5 つのリージョンにデータを 1 秒未満のレイテンシで複製し、リージョン障害時のフェイルオーバーも可能です。
コンピュートとストレージの分離アーキテクチャ
Aurora の高性能の根幹は、コンピューティングとストレージを分離した独自設計にあります。従来の RDS ではインスタンスにストレージが直接アタッチされていましたが、Aurora ではストレージレイヤーが独立した分散システムとして動作します。データは 10 GB のセグメントに分割され、3 つの AZ にまたがる 6 つのコピーとして保存されます。書き込みは 6 つのうち 4 つに成功すれば完了 (4/6 クォーラム)、読み取りは 3 つから応答があれば完了 (3/6 クォーラム) と判定されるため、2 つのコピーが同時に失われてもデータの読み取りが可能です。障害が検出されたセグメントは自動的に再構築されます。Azure SQL Database Hyperscale も計算とストレージを分離した設計ですが、Aurora は MySQL と PostgreSQL の 2 エンジンに対応する点で選択肢が広く、フェイルオーバー時間も通常 30 秒以内と高速です。
Serverless v2 とリードレプリカの使い分け
Aurora Serverless v2 はキャパシティを 0.5 ACU (約 1 GB メモリ) から 128 ACU まで自動スケールし、トラフィックの変動が大きいワークロードに最適です。夜間やオフピーク時は最小 ACU まで縮小するため、プロビジョンドインスタンスと比較してアイドル時のコストを大幅に抑えられます。一方、読み取り負荷が高い場合はリードレプリカの追加が効果的で、最大 15 台まで作成できます。リードレプリカはフェイルオーバーターゲットとしても機能し、プライマリの障害時に自動昇格します。データベース運用の専門書 (Amazon) では、Serverless とプロビジョンドの判断基準が詳しく解説されています。
バックトラックと Global Database による復旧戦略
Aurora MySQL 互換のバックトラック機能を有効にすると、最大 72 時間前の任意の時点にデータベースを数秒で巻き戻せます。誤った DELETE 文の実行や、デプロイ後のデータ不整合といった人為的ミスからの復旧が、スナップショットからの復元と比較して圧倒的に高速です。リージョン障害への備えには Aurora Global Database が有効で、最大 5 つのセカンダリリージョンにデータを 1 秒未満のレイテンシで複製します。リージョン間フェイルオーバーは通常 1 分以内で完了し、RPO (目標復旧時点) は 1 秒未満です。コスト面では、リザーブドインスタンスの 1 年全額前払いで約 40% の削減が可能です。Performance Insights でクエリのパフォーマンスを可視化し、スロークエリの特定とインデックス最適化を継続的に実施することで、インスタンスサイズの過剰なスケールアップを防げます。