はじめに
こんにちは。システム事業部のgakiです。新卒入社3年目にして初めての技術ブログ執筆です。 私事ではありますが、最近AWS Certified Solutions Architect - Professionalに合格したこともあり、最近は特定の言語やプロダクトに偏ることなくAWS周りの相談に乗ったり、新規案件のインフラ設計なども行っています。
さて、今回のテーマはAurora Serverless v2についてです。基本的な仕様や導入のきっかけについて書いていきます。
Aurora Serverless v2とは何か
AuroraはAmazon RDSのサービスの1つで、高可用なデータベースを提供しています。 Aurora Serverless v2はAuroraの中でも比較的新しいサービスで、負荷状況に合わせてDBのスペックを自動でスケールアップ・ダウンする機能が備わっています。
スペックを表す単位としてACUというものがあり、1ACUに対して約2GiB のメモリと対応する CPU、ネットワークが付与されます。 詳細は公式ドキュメントをご覧ください。
Aurora Serverless v2 導入のきっかけ
弊社のあるプロダクトではデータベースにAuroraを使用しています。しかし、プロダクトの規模が大きくなるにつれて、高負荷のSQLが特定の時間帯に多く実行されることによりCPU使用率が100％に張り付き、レスポンス性能が低下するといったことに悩まされていました。 サーバレス導入前は、下記のような構成で運用していました。
システム側での検索や帳票出力など、高負荷な読み取りSQLはリーダーインスタンスに振り分けることで負荷分散していました。しかし負荷はデータ量の増加に伴い上昇していき、SQLのチューニングは定期的に行っていたものの対処しきれず、DBインスタンスのサイズを上げて何とか負荷に対応していました。高負荷時のレスポンス性能を改善するため、スパイクアクセスに対して優れたスケーリング性能を発揮するデータベースである、Aurora Serverless v2を採用しました。
導入手順
Auroraでは、1つのクラスターの中でプロビジョンドインスタンスとサーバレスインスタンスを共存させることができるため、段階的な導入が可能でした。 下記の簡単な手順でクラスターにサーバレスインスタンスを追加することができます。
- Auroraクラスターのメニューから、「アクション」を選択
- DBインスタンスクラスに「Serverless v2」を選択
また、既存のプロビジョンドインスタンスをサーバレスインスタンスに変更することも可能です。
置き換え方法
今回は、本番環境で稼働しているリードレプリカのみサーバレスに置き換える方針で進めることになり、具体的な作業は下記の流れで行いました。
- 置き換え前 リーダーインスタンスと同数のサーバレスインスタンスを仕込んでおく
- 置き換え中 カスタムエンドポイントの宛先DBをレプリカ(プロビジョンド)→レプリカ(サーバレス)に変更
障害時は、カスタムエンドポイントの宛先DBをレプリカ(プロビジョンド)に戻すことで復旧が可能です。
今回Aurora Serverless v2を導入するプロダクトではリードレプリカへの接続はカスタムエンドポイントを使用していたため、置き換え作業はカスタムエンドポイントのターゲットインスタンスの変更で対応しました。
移行後に感じたメリット/デメリット
メリット
パフォーマンスの向上
導入前後で比較すると、高負荷時のレスポンス速度がかなり改善しました。導入前はデータを大量に出力する際にタイムアウトが発生することもありましたが、Aurora Serverless v2を導入して以降、タイムアウトは一度も発生していません。
メンテナンスコストの削減
現在このプロダクトで運用しているAurora Serverless v2は、以前のDBの1/8~4倍のスケーリング幅で柔軟に稼働しています。そのため、毎日のように来ていたDBのCPUアラートが止まり、高頻度の調査・メンテナンス作業から解放されました。
高速なスケーリング
実用性を評価する上で一番気になるところといえば、スケーリングの速度かと思います。
最大ACU使用時のCPU使用率と、サーバレスインスタンスのACUの推移を下記の通り比較してみました。 (Aurora Serverless v2ではCPUUtilizationの値がその時点でのACU数に対する使用率となるため、数式を利用し最大ACU使用時に対応する値に換算しています)
この図から、スケールアップは負荷の上昇の1分以内には開始しており、スケールダウンは比較的ゆっくりと行われるということが分かるかと思います。
一方でAuroraは、負荷上昇に対応する別機能として、Aurora Auto Scalingというものも提供しています。
こちらはスケールアウトの方式で、一時的にインスタンスを増設し負荷に対応するというものです。
しかし、増設インスタンスのプロビジョニング時間が追加でかかるため、負荷上昇への反応速度は10分ほど遅れます。
以前、同プロダクトにてAurora Auto Scalingを導入していましたが、増設インスタンスの立ち上がりが遅く、実際に稼働し始める頃には負荷は減少傾向になっているといったことが多くありました。
以上から、現状のAmazon RDSが提供するスケーリングの仕組みの中では、Aurora Serverless v2が最も負荷の増減に流動的に対応できるサービスであると考えられます。
ただ、スケーリングの速度が常に高速かと言われると、そうでは無いようです。 下記公式ドキュメントによると、スケーリングのスピードはその時点でのACU数が多い方が速くなる、との記載がありました。 docs.aws.amazon.com
現在、同プロダクトのAurora Serverless v2は4ACU~32ACUで設定しておりますが、プロダクトの要件として1分以内のスケーリングで速度面は十分なため、性能面の問題は無いと感じています。 ACUの範囲については、負荷テストなどを実施した上で良い落とし所を見つけていただければと思います。
デメリット
持続的な負荷がある場合はコスト効率を上げにくい
Aurora Serverless v2は使用量による従量課金です。そのため、持続的な負荷がある場合は料金が高くなる可能性があるため注意が必要です。
というのもAurora Serverless v2は、その負荷に相当するプロビジョンドDBインスタンスを利用した場合と比較すると高コストであるためです。
東京リージョンの料金で汎用インスタンスであるdb.m5.largeと、それに相当する4ACUのAurora Serverless v2で料金を比較してみました。
| 1時間あたりの料金1 | |
|---|---|
| db.m5.large | USD 0.235 |
| Aurora Serverless v2 (4ACU) | USD 0.8 |
このように、持続的な負荷がある場合はAurora Serverless v2が原因でコストパフォーマンスがあまり向上しなかったり、かえって高コストになってしまう可能性があります。 Aurora Serverless v2 を導入する際は、持続的な負荷が原因で料金がかさまないよう注意が必要です。
移行の教訓とベストプラクティス
負荷状況がAurora Serverless v2のユースケースとマッチするか確認しよう
お話ししてきた通り、Aurora Serverless v2がハマるのは常時低負荷&突発的な高負荷といった状況になります。
例えば下記のような場合は相性が良いかと思います
- 常時負荷は低いが、1日数回の高負荷なバッチ処理を行うため泣く泣く高スペックのデータベースを稼働させている
- 検証環境やデータ分析など短い使用時間のために、ほぼアイドル状態のデータベースを稼働させている
このような状況ですとAurora Serverless v2を導入することで、必要な時は必要なスペックで稼働させることができ、一方で大きなコスト削減も見込めます。
負荷が無い時間帯は、最低ACUを下げてコストダウンを図ろう
夜間や休日などにシステムがあまり利用されない場合は、その時間帯だけ最低ACUを下げることでコストの削減が可能です。
下記のように、1コマンドでデータベースの設定値を更新できるため、EventBridgeと組み合わせるなどしてACU調整の自動化も容易に行うことができます。 docs.aws.amazon.com
便利さに依存せず、継続的なSQLのチューニングを
Aurora Serverless v2を導入することで、使用量に応じた従量課金となります。そのため負荷の高いSQLを発行していると、その分だけ料金がかさみます。
導入前になるべくSQLのチューニングを済ませておく
負荷が高くなる要因は事前に取り除いておくと、性能面、コスト面において適切なスケール幅を設定することが可能です。
導入後も負荷軽減が可能なところは改善を続け、スケーリング幅の見直しも行う
改善できそうなSQLがあればチューニングをし、適切なスケーリング幅を設定することで、コスト効率を高められます。
負荷の高いSQLを効率的に検出するために、Performance Insightsの利用を検討してみても良いかもしれません。
docs.aws.amazon.com
おわりに
以上、Aurora Serverless v2導入について書いてみました。品質の維持やメンテナンスコスト削減の面では大きな強みを持っているサービスですが、負荷状況によっては割高になってしまうため状況によって適切な判断が必要となります。
導入の方法は柔軟に決めることができるため、簡単に試すことができるのが大きな強みだと感じています。DBのコスト削減を目指していたり、バースト的な負荷によりレスポンスに懸念があるような状況でしたら、ぜひ導入を検討してみてください。
スタイル・エッジでは、一緒に働く仲間を絶賛大募集しています。 もし興味を持っていただけましたら、以下の採用サイトも一度覗いてみてください！
- 2024.5.29現在↩
