k-tokitoh

2025-12-11

Aurora Serverless v2

Aurora Serverless v2 について。 （以下、provisioned なものと区別する必要のない文脈では Aurora と呼ぶ。）

AZ

ストレージレベル / コンピューティングレベルの AZ 冗長化を区別する必要がある。

コンピューティング

マネコンでクラスターを作成する際、AZ を 1 つ指定できる。

特に注釈はないが、これはコンピューティングレベルの、その中でもクラスターに 1 つだけ存在する Writer の AZ の指定である。

リードレプリカは 0~15 指定することができる。

クラスターをマネコンから作成する際、Multi-AZ deploymentという項目でCreate an Aurora Replica or Reader node in a different AZを選択することでレプリカをつくることができる。

in a different AZとあるとおり、Writer インスタンスと異なる AZ が自動的に選択される。

（マネコンで後から追加する場合は、Writer と同じ AZ を選択することもできた。）

ストレージ

分散型の耐障害性と自己修復機能を備えた Aurora ストレージを使用してデータ損失を防ぎ、リージョン内の 3 つのアベイラビリティーゾーン (AZ) にわたってデータの耐久性を高めます。 https://aws.amazon.com/jp/rds/Aurora/serverless/

これはストレージレベルの話。

この AZ はマネコンから作成するときは全く現れてこない。

また、作成後にマネコンをみてもどの AZ で冗長化されているのかは見当たらない。

CLI で確認することができた。

client % aws rds describe-db-clusters --db-cluster-identifier database-1
{
    "DBClusters": [
        {
            "AllocatedStorage": 1,
            "AvailabilityZones": [
                "us-east-1a",
                "us-east-1d",
                "us-east-1c"
            ],
            ...

ボトルネック

代表的なのは、よくある順番に並べると以下。

Aurora では CPU/メモリは ACU という設定値に応じて変化する。

ユーザーが最小 ACU と最大 ACU を指定しておくと、その範囲で Aurora がスケールアップ/ダウンして最適化してくれる。

同時接続数もやや間接的ではあるが ACU に応じて算出される。（詳細はこちら。）

I/O だけは ACU と関係がないので、I/O がボトルネックになった場合には基本的にスケールアウトでの対応が必要。

リードレプリカと非機能要件

耐久性

これはリードレプリカ含む作成時の設定には依らず、自動的に行われるストレージレベルの冗長化によって実現する。

可用性

Reader が落ちた場合の影響は比較的軽微なので、Writer が落ちた場合のみ考える。

インスタンス固有の問題で落ちた場合

Writer の配置された AZ 全体が落ちた場合

パフォーマンス

上記”ボトルネック”での記述を踏まえると、以下の場合にリードレプリカの追加がボトルネックの解消に有効である。

リードレプリカその他

endpoint

整合性

アプリケーション側で、各アクセスにおいてどのレベルの整合性が必要なのかをケアする必要がある。

2 つの意味

モニタリングすべき項目

“ボトルネック”を踏まえて、ざっくり以下。