Amazon Aurora

概要

は、MySQLおよびPostgreSQLと互換性のあるマネージドです。コンピューティングと分散ストレージを分離し、高い性能と可用性を提供します。

主要技術

① DBクラスター

ライターとレプリカが共有のクラスター用ストレージを使用します。クラスターは書き込み、リーダーエンドポイントは読み取り分散に使用します。

② Auroraレプリカ

読み取り処理を複数レプリカへ分散し、障害時の昇格先にもできます。アプリケーションは用途に応じたへ接続します。

1つのクラスターには最大15台のレプリカを置けます。レプリカはライターと同じクラスターボリュームを読むため、遅延は通常100ミリ秒未満に収まります。Aurora を使うと、使用率や接続数に合わせてレプリカの台数を自動で増減できます。のはエンジンの非同期複製で作られ、台数の自動増減には対応しません。

RDS for MySQLやRDS for PostgreSQLからAuroraへ移るときは、移行元のDBインスタンスからAuroraリードレプリカを作り、レプリカ遅延が0になったところで昇格させると、書き込みを止める時間を短くできます。のフルロードとでも、稼働を続けたまま移せます。

③ Aurora Serverless

需要に合わせてデータベース容量を自動調整します。変動が大きい、または断続的なワークロードに適しています。

Serverless v2はACU（容量単位）という単位で容量を細かく増減し、使った容量に応じて課金されます。最小容量を0 ACUにすると、ユーザーの接続がない状態が指定した時間（5分〜1日）続いたときにインスタンスが自動で一時停止し、その間はインスタンスの料金がかかりません。ストレージの料金は続きます。再開には通常15秒ほどかかるため、開発・検証環境や、接続の待ち時間を許容できる社内用途に向きます。 Proxyを関連付けたクラスターや、Global Databaseのプライマリクラスターでは自動では一時停止しません。

負荷が終日高く一定なら、容量を自動で増減させる利点が小さくなります。容量を固定したプロビジョンドのインスタンスにリザーブドDBインスタンスを適用した方が、費用を抑えやすくなります。

④ Global Database

複数へレプリケートし、近接リージョンでの読み取りやリージョン障害への備えに利用します。

セカンダリリージョンのクラスターは読み取り用です。書き込み転送を有効にしても、書き込みはプライマリリージョンのクラスターで実行されてから各リージョンへ複製されます。どのリージョンでもローカルに書き込みたい要件には、のを検討します。

リージョン間の複製はストレージ層で行われ、遅延は通常1秒未満です。プライマリリージョンの障害時はセカンダリクラスターを昇格させるで、は通常1秒程度、は1分未満を目安に復旧できます。セカンダリは最大10リージョンまで置けます。計画的にプライマリを移すときはデータを失わないスイッチオーバーを使います。グローバルデータベースのライターは切り替え後も新しいプライマリを指すため、アプリケーションの接続先を変えずに済みます。

⑤ 高可用性、接続、バックアップ

クラスターボリュームは複数にまたがってデータを保持します。ただし、ストレージの冗長性と、を処理するDBインスタンスの可用性は別です。別AZにレプリカを配置すると、ライター障害時に既存レプリカを昇格でき、復旧を速められます。

接続先	用途	判断ポイント
クラスター	読み書き	現在のライターへ接続します
リーダーエンドポイント	読み取り	接続を複数レプリカへ分散します
Proxy	接続プール	などの接続急増を抑えます

自動バックアップはポイントインタイムリカバリ、手動は長期保管や別環境への復元に使います。Global Databaseは間で非同期複製するため、ではと切替手順も確認します。

Aurora MySQL互換にはBacktrackがあり、バックアップから復元し直さずにクラスターを直近の指定時点へ巻き戻せます。巻き戻せる範囲は設定した時間枠に限られ、対象もAurora MySQL互換だけです。長期保管や目的のバックアップの代わりにはならないため、保持期間の要件はスナップショットやで満たします。

⚠️ 頻出: AuroraにはMySQL互換とPostgreSQL互換だけがあり、他のエンジン互換のエディションは存在しません。移行先としてAuroraが挙がる選択肢は、まず互換性を確認します。

⑥ ストレージ構成、クローン、バックアップの費用

構成	課金	選ぶ目安
Standard	インスタンスとストレージに加え、I/Oを100万リクエストごとに課金します	I/Oの費用がAuroraの費用全体の25%未満
Aurora I/O-Optimized	読み書きのI/Oに課金しません。インスタンスとストレージの単価は高くなります	I/Oの費用がAuroraの費用全体の25%以上

StandardからI/O-Optimizedへの切り替えは30日に1回までで、I/O-OptimizedからStandardへはいつでも戻せます。リザーブドDBインスタンスはどちらの構成にも適用されます。

開発や検証のために本番のデータを複製するときは、Auroraのクローンを使えます。クローンはコピーオンライトで作られ、作成時はデータページを元のクラスターと共有します。から復元して全量を複製するより速く、ストレージ料金は変更したページの分だけ増えます。クローンは元のクラスターと同じにだけ作れます。

自動バックアップは、保持期間（1〜35日）内の任意の時点へ戻すための増分の記録です。最新のクラスターボリュームのサイズまでは追加料金がかかりません。保持期間内に取ったスナップショットも無料ですが、保持期間を過ぎた手動スナップショット（が取ったものを含む）は、それぞれ取得時のボリュームサイズで課金され続けます。

⑦ SQL Serverからの移行（Babelfish）

Babelfish for PostgreSQLは、Aurora PostgreSQLに、 Serverのワイヤープロトコル（TDS）とT-SQLを受け付けるを追加する機能です。SQL Server向けに作られたアプリケーションを、データベースドライバーを変えずに、従来の移行より少ないコード変更でAurora PostgreSQLへ移せます。SQL Serverのライセンス費用をなくしたい場合の候補になります。T-SQLには一部違いがあるため、移行前に互換性を評価します。

試験対策

① RDSとの比較

MySQL／PostgreSQL互換性を保ちながら、分散ストレージ、高速なレプリカ、クラスター構成を求める場合にを選びます。

② 読み取り性能

読み取り集中型ではレプリカとリーダーを使用します。接続急増には Proxyも検討します。

⚠️ 頻出: リーダーエンドポイントはクエリを分割するのではなく、新しい接続をレプリカへ振り分けます。変動負荷にはServerless v2、にはGlobal Databaseを検討します。

概要