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"
            ],
            ...

ボトルネック

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

• 同時接続数
• I/O
• メモリ
• CPU

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

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

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

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

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

耐久性

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

可用性

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

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

• 🟡 リードレプリカを設定していない場合
  • Aurora は Writer の配置された AZ で Writer を再作成する
  • 新規で立ち上げるので、リードレプリカからの復旧よりも時間がかかる
• 🟢 リードレプリカを設定している場合
  • いずれかのリードレプリカが Writer に昇格する
  • リードレプリカが Writer と異なる AZ に配置されていれば、リードレプリカの AZ も同時に落ちていない限り、直ちに復旧できる

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

• 🔴 リードレプリカを設定していない場合
  • Aurora は Writer の配置された AZ で Writer を再作成しようとするので、AZ 全体が落ちている限り復旧しない
• 🟢 リードレプリカを設定している場合
  • いずれかのリードレプリカが Writer に昇格する
  • リードレプリカが Writer と異なる AZ に配置されていれば、リードレプリカの AZ も同時に落ちていない限り、直ちに復旧できる

パフォーマンス

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

• I/O が原因で詰まっている場合
• 同時接続数, メモリ, CPU が原因で詰まっており、かつ、以下いずれかの場合
  • 最大 ACU が上限値に達しておりスケールアップが不可能な場合
  • スケールアップよりもスケールアウトの方がコスト効率が良い場合

リードレプリカその他

endpoint

• Type: Writer と Type: Reader の endpoint は異なる
• リードレプリカを 1 つ以上設けることでType: Readerの endpoint が作成される
• Reader を複数設置した場合も、Type: Readerの endpoint は 1 つである

整合性

• Type: Writerの endpoint にアクセスした場合は強整合性が実現する
• Type: Readerの endpoint にアクセスした場合は結果整合性が実現する

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

2 つの意味

• “リードレプリカと非機能要件”で述べたとおり、リードレプリカは可用性とパフォーマンスの 2 点で意味がある
• 可用性を高める目的だけであれば、Type: Readerの endpoint を利用する必要はない

モニタリングすべき項目

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

• キャパシティ系（メモリ, CPU）
• 同時接続数
• 結果指標（レイテンシ, スループット）