Amazon Aurora Serverless v2 のスケールアップ・ダウンを試してみた
はじめまして！SHIFT DAAE（ダーエ）開発グループ所属の白木です。
先日、正式版が公開された Aurora Serverless v2 の導入検討にあたり、スケールアップ・ダウンの検証を行ったのでそこで得られた知見をまとめました。
この記事の内容は Using Aurora Serverless v2 を参考にしています。
Aurora Serverless v2 の特徴
DB サーバのキャパシティー管理を考えなくてもよくすることを目指して開発された DB サービスです。
Aurora Serverless v2 の特徴は大きく以下の 3 つです。
スケールアップ・ダウン中にクエリが止まったり、スループットが落ちたりしない。
(v1 と比較して)細くキャパシティユニットの変更が行われる。
複数の AZ にまたがって最大 16 インスタンスを起動できる。
現時点で以下の DB エンジンをサポートしています。
MySQL 8.0(Aurora MySQL 3.02.0 以上)
PostgreSQL 13(Aurora PostgreSQL 13.6 以上)
Aurora Serverless v2 に期待していること
開発環境でのコスト削減
夜間や土日の利用していない時間は自動で停止 or 最小限のサイズに縮小することで、コストを抑えたいです。本番環境でのスケーラビリティ
Aurora Serverless v1 の課題であったコールドスタートは Aurora Serverless v2 になり解消され本番環境用途での実用性が高まりました。
特徴にも書きましたが、v2 では実行中のクエリへの影響なくスケールアップが行われるため、突然のスパイク時の対応も期待できます。
Aurora Serverless v2 はどのように高速なスケールを実現しているか？
Aurora の特徴として、
コンピュート(クエリを実行する役割)とストレージ(データを保持する役割)を分けて動作するアーキテクチャが採用されています。
それによってコンピュート側の CPU・メモリの量を動的に変えることができ高速なスケールアップ・ダウンを実現しています。
キャパシティー管理の仕組み
Aurora Servless v2 のキャパシティは ACU(Aurora Capacity Unit) と呼ばれる単位で管理されています。
1 ACU = 2GiB のメモリが割り当てられ、CPU・ネットワークは ACU に準じて割り当てサイズが決まります。
最小は 0.5 ACU(1GiB のメモリ) から 0.5 ずつ、最大 128 ACU(64GiB のメモリ)まで設定が可能です。
スケールアップで増える ACU サイズは実行時の ACU によってサイズが異なり、 ACU が大きければ大きいほどスケールする幅も大きくなります。
何をトリガーにしてスケールアップ・ダウンをするのか？
CPU・Memory・Network の利用状況を監視し、Aurora の管理システムがスケールアップ・ダウンのイベントをキックすることでスケールアップ・ダウンが行われます。
負荷テストしてみる
Aurora Serverless v2 の特徴を紹介したので、次は本題であるスケールアップ・ダウンの検証するために pgbench を使って負荷をかけてみます。
DB エンジンは Aurora PostgreSQL (Compatible with PostgreSQL 13.6)を使用して 、最小 ACU の値を変えたパターン 1 と 2 で ACU によってスケールアップ・ダウンの速度が変わることを確認します。
パターン 1
最小: 0.5 ACU(1GiB メモリ)
最大: 32 ACU(16GiB メモリ)
パターン 2
最小: 8 ACU(4GiB メモリ)
最大: 32 ACU(16GiB メモリ)
pgbench の設定
初期化
$ pgbench -i -s 100 -U postgres -h xxxxx.ap-northeast-1.rds.amazonaws.com -d test
pgbench -iで初期化を行います。 -s 100を指定して pgbench_accounts テーブルに 10,000,000 レコード作成します。
実行
$ pgbench -c 1000 -t 100 -h xxxxx.ap-northeast-1.rds.amazonaws.com -d test -U postgres
負荷テストの結果
パターン 1(最小:0.5 ACU、最大: 32 ACU)
最初のスケールアップでは 8 ACU、最高の 18 ACU までは 10 分後に到達。
pgbench 終了後、20 分で最小値までスケールダウン。
パターン 2(最小:8 ACU、最大: 32 ACU)
最初のスケールアップでは 15.5 ACU、最高の 17.5 ACU までは 2 分後に到達。
pgbench 終了後、13 分で最小値までスケールダウン。
まとめ
Aurora Serverless v2 の特徴紹介とスケールアップ・ダウンの検証を行いました。負荷テストでは各パターン 3 回ずつ検証を行いましたが、どの回でも近しい値が得られACU の大きさに応じでスケールアップ・ダウンの速度が変わることが確認できました。
既に現在のプロジェクトでは開発環境で Aurora Serverlesss v2 を採用して、本番環境への導入を見据えて検証を進めています。今後も本番環境導入に向けての検証結果を発信していきたいと思います。
MAGAZINE
＼もっと身近にもっとリアルに！DAAE公式Twitter／
執筆者プロフィール: Shoya Shiraki
ソフトウェアエンジニアとしてソーシャルゲーム開発、スタートアップでのCTO経験を経てSHIFTに入社。
技術を人に最適化するをモットーに、日々楽しんで開発しています。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/