Pocket Bundle シリーズ : Amazon Aurora MySQL・PostgreSQL 互換のクラウドネイティブなリレーショナルデータベース

Amazon Aurora は、Amazon RDS 上で動作するクラウドネイティブなリレーショナルデータベースエンジンです。MySQL と PostgreSQL の両方に互換性があり、既存のコード・ツール・アプリケーションをほぼそのまま利用できます。

「クラウドネイティブ」とは、クラウド環境の特性を最大限に活かすよう設計されていることを意味します。Aurora はストレージとコンピュートを分離したアーキテクチャを採用しており、従来のデータベースでは難しかった「高性能」「高可用性」「運用の自動化」を同時に実現しています。

Aurora は Amazon RDS の一部として提供されるため、RDS コンソールから作成・管理します。RDS が提供するパッチ適用、バックアップ、モニタリングなどのマネージド機能をそのまま活用しつつ、Aurora 独自の高性能ストレージサブシステムの恩恵を受けられます。

なお、Aurora は MySQL と PostgreSQL の「互換」であり、完全な同一ではありません。一部のネイティブ機能やプラグインは利用できない場合があります。移行前に互換性の詳細 (Aurora MySQL / Aurora PostgreSQL) を確認してください。

詳しくは、公式ドキュメントの「Amazon Aurora とは」をご覧ください。

X ポスト » | Facebook シェア » | はてブ »

Aurora には 3 つの主要な特徴があります。商用 DB を超える高性能、高可用性・高耐久性、そして運用の自動化です。

パフォーマンスについて、Aurora は MySQL 比最大 5 倍、PostgreSQL 比最大 3 倍のスループットを実現するとされています。ただし、この数値は特定のベンチマーク条件下での結果であり、実際のパフォーマンスはワークロードの特性によって異なります。この性能差は、Aurora 独自のストレージエンジンに起因します。従来のデータベースではトランザクションログをストレージに書き込んでからデータページを更新しますが、Aurora はログレコードのみをストレージ層に送信し、データページの生成はストレージ側で非同期に行います。この「ログ構造化ストレージ」により、書き込み I/O が大幅に削減されます。

高可用性については、データを 3 つの Availability Zone (AZ) にまたがる 6 つのストレージノードに同期的にレプリケートします。6 つのコピーのうち、書き込みは 4 つ、読み取りは 3 つのコピーが応答すれば処理が完了するクォーラムモデルを採用しており、一部のノードに障害が発生してもサービスを継続できます。Multi-AZ 構成の SLA は 99.99%、Single-AZ 構成では 99.9% です。

運用面では、自動バックアップ、自動パッチ適用、ストレージの自動拡張 (最大 128 TiB、特定バージョン以降は 256 TiB) が標準で提供されます。データベース管理者が手動で行っていた多くの作業が自動化されるため、アプリケーション開発に集中できます。

詳しくは、公式ドキュメントの「Amazon Aurora の特徴」をご覧ください。

Aurora は「DB クラスター」という単位で構成されます。DB クラスターは「インスタンス」と「共有ストレージ (クラスターボリューム）」の 2 つの要素で成り立っています。

インスタンスには 2 つの役割があります。プライマリインスタンス (ライター) は読み書き両方を処理し、クラスターに 1 台だけ存在します。Aurora レプリカ (リーダー) は読み取り専用で、最大 15 台まで追加できます。

Aurora の最大の特徴は「ストレージとコンピュートの分離」です。従来のデータベースではインスタンスごとにストレージが紐付いていましたが、Aurora ではすべてのインスタンスが 1 つの共有ストレージ (クラスターボリューム) にアクセスします。このため、レプリカの追加時にデータのコピーが不要で、数分で新しいリーダーを追加できます。

クラスターボリュームは SSD ベースで、3 つの AZ に合計 6 コピーのデータを分散配置します。この 6 コピーの仕組みにより、2 つのコピーが同時に失われてもデータの書き込みが可能で、3 つのコピーが失われても読み取りが可能です。

レプリカを削除してもデータは失われません。データはクラスターボリュームに保持されるため、クラスター全体を削除しない限りデータは安全です。

詳しくは、公式ドキュメントの「Amazon Aurora DB クラスター」をご覧ください。

Aurora データベースの作成から利用開始まで、RDS コンソール上で完結します。「エクスプレス設定」を選択すると、事前設定済みの Aurora PostgreSQL Serverless (負荷に応じてキャパシティが自動で調整されるサーバーレス構成。詳細は本記事の「スケーリング」のセクション を参照) を数秒で作成を開始できます (クラスターが完全に利用可能になるまでは数分かかる場合があります）。

「フル設定」では、エンジンのタイプ (Aurora MySQL または Aurora PostgreSQL）、DB クラスター識別子、マスターユーザー情報、インスタンスクラス、VPC、セキュリティグループなどを細かく指定できます。

Aurora は需要の変化に応じて柔軟にスケールでき、アプリケーションの成長に合わせて後から性能を調整できます。垂直スケーリング、水平スケーリング、ストレージスケーリングの 3 種類があります。

Aurora は最大 15 台のリードレプリカを作成でき、読み取り処理を分散して性能を向上させます。

Aurora は継続的なバックアップにより、データ保護を自動化します。バックアップは Amazon S3 に保存され、Aurora のストレージと同様に 3 つの AZ に分散されます。

Aurora では、ポイントインタイムリカバリ (PITR) 機能により、自動バックアップ保持期間内 (1 ~ 35 日間) の任意の時点に秒単位で復旧できます。

PITR の最大の特徴は、復旧先が新しい DB クラスターとして作成される点です。元のクラスターはそのまま稼働を継続するため、本番環境に影響を与えずにデータを復旧できます。例えば、誤って DELETE や DROP TABLE を実行してしまった場合、その直前の時点に復旧した新しいクラスターからデータを取り出し、元のクラスターに戻すことができます。

Aurora MySQL のバックトラック

Aurora MySQL には、PITR に加えて「バックトラック」という独自機能があります。バックトラックは新しいクラスターを作成せずに、既存のクラスターを指定した時点まで「巻き戻す」機能です。PITR より高速に復旧できますが、最大 72 時間前までしか遡れず、バックトラック用の変更レコードを保存するための追加料金が発生します。また、クラスター作成時にバックトラックを有効にしておく必要があります (後から有効化はできません）。
PITR とバックトラックの使い分けとしては、数時間以内の誤操作からの迅速な復旧にはバックトラック、それ以前のデータ復旧や Aurora PostgreSQL 環境では PITR を使用します。

⚠ PITR で復旧可能な最新の時点は、通常、現在時刻の約 5 分前です。直近 5 分間のデータは復旧できない可能性があります。

詳しくは、公式ドキュメントの「DB クラスターを指定の時点の状態に復元する」をご覧ください。

Aurora は用途に応じた接続エンドポイントを提供し、書き込みと読み取りを適切に振り分けます。エンドポイントは Aurora 固有の URL で、ホストアドレスとポート番号で構成されます。

Aurora の高性能・高可用性は、様々な業界の基幹システムで活用されています。

詳しくは、公式ドキュメントの「Amazon Aurora のお客様」をご覧ください。

従来のデータベースが抱えていたさまざまな課題を Aurora の機能で解決できます。

• ストレージ構成の選択
  Aurora には Aurora Standard と Aurora I/O-Optimized の 2 つのストレージ構成があります。Aurora Standard は I/O リクエストごとに課金されるため、I/O 使用量が少ないワークロードに適しています。Aurora I/O-Optimized は I/O 料金が無料になる代わりにインスタンスとストレージの単価が高くなりますが、I/O コストが総コストの 25% 以上を占める場合は最大 40% のコスト削減が見込めます。
  Aurora I/O-Optimized から Standard への切り替えはいつでも可能ですが、Aurora Standard から I/O-Optimized への切り替えは 30 日に 1 回のみです。まずは Aurora Standard で運用を開始し、Amazon Aurora のモニタリングツール で I/O コストの割合を確認してから切り替えを検討するのが安全です。
  
• コストに関する注意
  Aurora は同等のインスタンスサイズの Amazon RDS for MySQL/PostgreSQL と比較してインスタンス単価が高めに設定されています。ただし、Aurora の高性能ストレージにより、同等のパフォーマンスを得るために必要なインスタンスサイズが小さくなるケースも多く、総コストでは Aurora の方が安くなることもあります。AWS 料金見積りツール で事前に試算することを推奨します。
• RDS Extended Support
  Aurora のメジャーバージョンがコミュニティのサポート終了 (EOL) を迎えた後も、Amazon RDS 延長サポート を利用すれば最大 3 年間の延長サポートを受けられます。ただし、追加料金が発生し、EOL 後の経過期間に応じて段階的に料金が上がります。計画的なバージョンアップグレードを推奨します。
• 暗号化
  2026 年 2 月 18 日以降に作成されたすべての新規 DB クラスター は、デフォルトで保管時の暗号化 (AES-256) が有効になっています。暗号化を無効にすることはできません。既存の暗号化されていないクラスターには影響しませんが、暗号化されたクラスターの暗号化を後から解除することもできません。暗号化キーは AWS 所有キー (SSE-RDS) がデフォルトですが、カスタマーマネージドキー (CMK) も選択できます。

詳しくは、公式ドキュメントの「Amazon Aurora のクォータと制約」をご覧ください。

• Amazon RDS と Aurora の使い分け
  Amazon RDS は MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2 の 6 つのエンジンに対応する汎用的なマネージドデータベースサービスです。Aurora は MySQL と PostgreSQL のみですが、独自のストレージエンジンにより高い性能と可用性を提供します。
  小 ~ 中規模のワークロードでコストを重視する場合は Amazon RDS、高い性能・可用性・スケーラビリティが求められる場合は Aurora が適しています。Amazon RDS から Aurora への移行は、スナップショットの復元やレプリケーションを使って比較的容易に行えます。
• Aurora と Amazon DynamoDB の使い分け
  Amazon DynamoDB はキーバリュー型の NoSQL データベースで、テーブル間の JOIN が不要なワークロードに適しています。複雑なリレーションや SQL による柔軟なクエリが必要な場合は Aurora、単純なキーベースのアクセスパターンで極めて高いスケーラビリティが必要な場合は DynamoDB を選択します。
• Aurora と Amazon Redshift の使い分け
  Amazon Redshift は列指向のデータウェアハウスで、大量データの集計・分析に最適化されています。OLTP (トランザクション処理) には Aurora、OLAP (分析処理) には Amazon Redshift が適しています。Aurora の ゼロ ETL 統合を使えば、Aurora のデータを Amazon Redshift にほぼリアルタイムで自動連携でき、ETL パイプラインの構築が不要になります。
• Aurora DSQL
  2025 年 5 月に GA となった Amazon Aurora DSQL は、サーバーレスの分散 SQL データベースです。PostgreSQL 互換で、マルチリージョンでの強整合性のある読み書きを実現します。インフラ管理が不要で、単一リージョンで 99.99%、マルチリージョンで 99.999% の可用性を提供します。常時稼働が求められるグローバルアプリケーションに適しています。

詳しくは、公式ドキュメントの「AWS でのデータベースの選択」をご覧ください。

Aurora の料金は、主に「インスタンス」「ストレージ」「I/O」「バックアップ」の 4 要素で構成されます。

インスタンス料金
DB インスタンスの稼働時間に対して課金されます。料金はインスタンスクラスによって異なり、秒単位 (最低 10 分) で計算されます。Aurora Serverless v2 の場合は ACU 時間単位で課金されます。コスト削減には リザーブドインスタンス (1 年または 3 年の前払い) や Database Savings Plans (Aurora、Amazon RDS、Amazon DynamoDB などを横断して適用可能) が有効です。詳細は 公式料金ページ をご確認ください。

ストレージ料金
使用したストレージ容量に対して GiB/月単位で課金されます。ストレージは自動拡張されるため、事前のプロビジョニングは不要です。データを削除すると使用領域が縮小し、料金も減少します。

I/O 料金
Aurora Standard 構成では、100 万リクエストあたりの料金が発生します。Aurora I/O-Optimized 構成では I/O 料金が無料になります。I/O コストが総コストの 25% 以上を占める場合は I/O-Optimized への切り替えを検討してください。

バックアップ料金
自動バックアップのストレージは、クラスターボリュームの合計サイズと同容量まで無料です。それを超える分と手動スナップショットは GiB/月単位で課金されます。

見落としがちなコスト

• データ転送料金 : 同一リージョン内の AZ 間転送は無料ですが、クロスリージョン転送は有料です。Aurora Global Database のレプリケーションにもクロスリージョン転送料金が発生します。
• RDS Proxy 料金 : RDS Proxy は vCPU 単位で別途課金されます。
• 停止中のクラスター : DB クラスターを停止しても、ストレージとバックアップの料金は引き続き発生します。また、停止状態は最大 7 日間で、その後自動的に再起動されます。

⚠ 料金は頻繁に変更されます。最新の単価は 公式料金ページ をご確認ください。

Aurora についてさらに学ぶための公式リソースです。QR コードから各リソースにアクセスできます。

各リソースの使い分け: 

• 公式ドキュメント : Aurora の全機能・API・ベストプラクティスを学べる公式リファレンス
• 料金ページ : インスタンス、ストレージ、I/O 料金の詳細。複数リージョンでの料金比較も可能
• AWS ブログ : Aurora のベストプラクティスと最新機能

なお、英語版の公式ドキュメントは日本語版より更新が早い場合があります。最新の仕様確認には英語版も参照することをおすすめします。

⚠ 本記事の内容は作成時点の情報です。料金や仕様は変更される場合があるため、最新情報は公式ドキュメントをご確認ください。

米倉 裕基
アマゾン ウェブ サービス ジャパン合同会社
テクニカルライター・イラストレーター

日英テクニカルライター・イラストレーター・ドキュメントエンジニアとして、各種エンジニア向け技術文書の制作を行ってきました。趣味は娘に隠れてホラーゲームをプレイすることと、暗号通貨自動取引ボットの開発です。現在、AWS や機械学習、ブロックチェーン関連の資格取得に向け勉強中です。