この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWSチームのすずきです。
2022年4月23日に開催されたJAWS-UG横浜、 アマゾンウェブサービスジャパンの星野豊氏による、Aurora Serverless v2 Deep Dive を視聴する機会がありました。
アーカイブ動画はYoutubeで公開されていますが、4月22日に一般公開された直後の Aurora Serverless v2 (以降v2)について、 印象的だった内容についてレポートします。
YouTube(アーカイブ)
発表者について
- Amazon Aurora MySQL 開発チームに所属するSA 星野豊さんでした。
前提事項
- v2 GA当日(2022年4月23日)の資料との事でした
v2のコンセプト
- アプリケーション負荷に応じたマネージドなDB性能調整
- 実際に利用したDB性能に応じたオンデマンド課金利用
- DBキャパシティ管理の最小化
v2 の特徴
スケーリング
- 稼働しているDBインスタンスがそのままスペックアップ、スペックダウン
- トランザクションやDBコネクションに影響を与えず、vCPU、メモリが増減
従来の Aurora Serveless v1 (以下v1) 、動作中にスペック変更する事が可能でしたが、クエリが処理されていないスケーリングポイントを必要としていたため、 長時間実行されるクエリや、トランザクション処理中はスペック変更ができない制限がありました。
Buffer pool resizing
- インスタンスのスペック変更に追従し、DBに割り当てられるメモリサイズが動的に変更
- スペックアップ、利用可能なメモリが増える場合、バッファプールは都度拡張
- スペックダウンによりメモリが減少する場合、LRU(Least Recently Used)
- ストレージから読み取られた直後、中間の優先度でバッファプールに格納され、廃棄対象となる事を回避
- スペックダウン時、利用頻度の低いバッファプールから切り詰め(LRU)
- バッファプールの調整仕様、MySQL標準で備える仕組みに加え、v2独自のカスタマイズが施されている
DB性能(キャパシティ)
- Aurora Serveless v2の性能単位はACU
- 1ACUで 2GiBのメモリが割り当てられ、比例したCPU、ネットワーク性能が利用出来る
- 最小のACU設定は0.5 (1GiB割当)、 増加単位は0.5
v1のACU設定、MySQL互換エンジンでは、1、2、4、8、16、32、64、128、256、2のべき乗数で設定する仕様でした。
高めのDB性能、例えばACU数80のDB性能を必要とする場合、v1 では 128の過剰なACU設定となる場合がありましたが、v2では無駄の少ない利用が可能になりました。
スペックアップ
- Auroraの管理システムが、CPU、メモリ、ネットワークの利用状況を監視、最適なACU数になるようスペックが調整
- ACU:10から18へのスペックアップであれば、1回の変更で高速に行われる。
- ACUスペックアップ可能な上限(スペックアップデート)が存在。変更前のACU数が少ない状態から、高いACUに上げる必要がある場合、注意が必要。
スケール動作例
TPP-Cベンチマークを実行中の、CloudWatchメトリクスのグラフ
- 緑色がCPU使用率に応じて、青色のACU数が変化
- スペックアップは高速、スペックダウンはゆっくり
リードレプリカ
- 従来のAurora同様、最大15台までリードレプリカを作成、フェイルオーバ先としても利用可能
- フェイルオーバ優先度(Tier)を 0と1に設定した リードレプリカは、フェイルオーバー時の性能不足を回避するためライターインスタンスと同じACU数が維持される
- マルチAZ配置にした v2の Auroraクラスタ、可用性のSLAは99.99%
v1 の Auroraは リードレプリカは未サポート リードレプリカを活用できるワークロードで読み取り性能の向上手段が限定されたり、AZ障害が発生した場合の回復がベストエフォートになるといった課題がありました。
v2のインスタンスは、リードレプリカやグローバルデータベースでも利用する事ができ、同一のAuroraクラスタ内で、従来のAurora(Provisoned) と、v2サーバレスのインスタンスを混在した利用も可能になりました。
グローバルデータベースでの利用
- Serveless v2をセカンダリリージョンに採用、平時のACU数を抑制して維持。
- プライマリの障害などで セカンダリへの切替が必要となった場合、ACUをスペックアップして利用する。
ユースケース例
マルチテナント
- テナント数が多く、DB負荷管理が難しいSaaSアプリケーション、
- 多数のアプリケーションから参照され、性能管理が難しいワークロード
- シャーディング、水平方向に負荷分散したデータベースで、各シャード毎で必要なDB性能を、V2の自動調整でカバー
- 無停止でライターインスタンスの性能強化が必要なワークロード
- リーダーインスタンスの性能調整
リードレプリカインスタンスの起動直後、キャッシュなどが温まる前の性能が問題となるワークロードや、 リードレプリカ縮退時の影響のため、リーダーインスタンスのスペックアップ、スペックダウンが望まれる場合。
まとめ
4月22日に一般公開された直後の Aurora Serverless v2について 興味深い内容、 特にスペック変更に応じたバッファプールのリサイズなどについて、いち早く知る貴重な機会を得る事ができました。
登壇頂いたAWS星野さん、イベントを主催頂いたJAWS横浜の関係者に感謝です。
Aurora Serverless v2 公式ドキュメント Using Aurora Serverless v2 に記載された内容や、セッション中のベストプラクティスとして紹介された事項についても、逐次検証を進め、改めて紹介させて頂きたいと思います。
4
