こんにちは。
アプリケーションサービス部の兼安です。
本記事はサーバーワークス Advent Calendar 2024の1日目の記事です。
今年もみんなで書いていますのでよろしくお願いします。
さて一発目の記事ですが、Amazon Aurora Serverless v2がゼロキャパシティをサポート開始しました。
今回は早速これについて紹介します。
なお、本記事は2024年11月末時点の情報に基づいていることをご了承ください。
- Amazon Aurora Serverless v2とは
- Amazon Aurora Serverless v2のゼロキャパシティを試してみる
- ゼロキャパシティのメリット
- 残る課題はRDS Proxy
- サーバーレスの恩恵を受けつつも、自身のスキルアップは欠かさない
Amazon Aurora Serverless v2とは
Amazon Aurora Serverless v2は、オートスケーリング機能を備えたリレーショナルデータベースです。
データベースに対する需要に応じて、自動的にリソースを垂直スケーリング（スケールアップ／ダウン）することができます。
Amazon Aurora Serverless v2 は、ACUという単位でリソースを割り当てます。
ACUはデータベースに対する需要に応じて自動的に増減し、使用されたACUに対して課金されます。
これまでACUの最小値は0.5でしたが、2024年11月下旬のアップデートで最小ゼロを指定可能になりました。
これで本当の意味でのサーバーレスに近づきましたね。
Amazon Aurora Serverless v2のゼロキャパシティを試してみる
早速試してみましょう。
Amazon Aurora Serverless v2のゼロキャパシティを指定するには、エンジンバージョンを特定のバージョンに設定します。
AWSのページには以下のように記載されています。
0 ACUs is supported for Aurora PostgreSQL 13.15+, 14.12+, 15.7+, and 16.3+, and Aurora MySQL 3.08+.
これの見方ですが、Aurora PostgreSQLの15系なら、15.7以上、16系なら16.3以上という意味です。
最新メジャーバージョンの16系ならOKという意味ではないので注意してください。
今回はAurora PostgreSQL 16.3を使って試してみます。
エンジンバージョンを16.3に選択することで、最小ACUとして0を指定できるようになりました。
なお、以前は最大ACUは128でしたが、2024年10月から最大ACUは256まで入力可能になっています。
こちらも、エンジンバージョンに指定があるのでリンク先を確認してください。
この状態で起動後、何もアクセスせず放置してみました。
起動直後に少しACUが上昇しますが、その後はゼロのままですね。
コストエクスプローラーを確認してみると、ほぼ費用が発生していませんでした。
流石にまったくのゼロとはいかないようですね。
予想通りではありますが、とても嬉しいですね。
ゼロキャパシティのメリット
今回ゼロキャパシティがサポートされたメリットとしては、単純なコスト削減もありますが、個人的に開発環境でもAmazon Aurora Serverless v2を採用しやすくなったことだと思います。
Amazon Auroraの料金ページを見ると、Amazon Aurora Serverless v2のACUあたりの料金は以下のようになっています。
| 測定 | Aurora Standard (ACU 時間あたり) | Aurora I/O 最適化 (ACU 時間あたり) |
|---|---|---|
| Aurora キャパシティーユニット | USD 0.20 | USD 0.26 |
※2024年11月末時点の東京リージョンの料金です。
ACUが最小0.5だとしたら、1時間あたりUSD 0.10かかります。
一方、通常のAmazon Auroraのオンデマンドインスタンスは最小がdb.t4g.mediumで、1時間あたりUSD 0.113です。
最低料金にそれほど大きな差がないため、開発環境ではAmazon Aurora Serverless v2よりも、需要に応じて金額が変動しないオンデマンドインスタンスの方が優先される可能性が高いと思います。
ここがゼロキャパシティがサポートされたことで、開発環境でもAmazon Aurora Serverless v2を使いやすくなり、本番と開発で完全に同じ環境を使うことができる可能性が高まったのではないでしょうか。
インスタンスサイズがシステムの挙動に直結することは稀かもしれませんが、少しでも本番環境に近い環境で開発を行うことは重要だと思います。
残る課題はRDS Proxy
今回のアップデートでAmazon Aurora Serverless v2がゼロキャパシティをサポートしましたが、2024年11月末時点ではまだAmazon RDS Proxyについては同様のアップデートがありません。
従って、Amazon RDS Proxyを使う場合は最低8ACU分の料金が発生します。
アプリケーションにAWS Lambdaなどのサーバーレスを使用する場合、Amazon RDS Proxyを採用する可能性が高いため、同様のアップデートが待たれます。
サーバーレスの恩恵を受けつつも、自身のスキルアップは欠かさない
ここからは私見になります。
今回のアップデートは、データベースのオートスケーリングを受けやすくする素晴らしいアップデートだと思います。
データベースのオートスケーリングは、性能不足によるシステム停止を防ぎ、ビジネスを安定させるための一助となるでしょう。
一方でここ数年、クラウドの拡張性に頼り、データベース設計上の課題が後回しにされる事例を耳にします。
一般的にデータベースはシステムの中で特に寿命が長く、変更がしづらい部分です。
これは、データベースは多数のプログラムからアクセスされるため、おいそれと変更できないという理由からです。
データベースの設計不備により性能が発揮できない場合も、オートスケーリングを初めとしたクラウドの拡張性がある程度カバーできますが、設計不備の根本的な解決にはなりません。
変更が難しいからといって、対処法をし続けると、コストが増大していき、システムを維持できなくなる可能性もあります。
そうならないためにも、サーバーレスを採用する／しないを問わず、データベースの設計やチューニングについてはしっかりとやっておくという意識は保ちたいと思います。
あとは、問題が顕在化していないからといってそこで止まらず、継続的な監視を行い、変化を見逃さないことも重要です。
今回は以上です。
今回のアップデートと本記事の内容が皆様の業務や開発においてお役に立てれば幸いです。
兼安 聡(執筆記事の一覧)
アプリケーションサービス部 DS3課所属
2024 Japan AWS Top Engineers (Database)
2024 Japan AWS All Certifications Engineers
認定スクラムマスター
広島在住です。今日も明日も修行中です。
