はじめに
Amazon RDS for MySQL から Amazon Aurora Serverless へ乗り換える機会があったので、勘所のようなものをご紹介します。この記事では Java, SpringBoot を前提に記載していますが、本質は言語やフレームワークを問わない内容ですので、適宜ご利用の環境に読み替えてご覧頂けると幸いです。
Amazon Aurora Serverles とは
詳細は公式のドキュメント等をご確認頂きたいのですが、大きな特徴としては管理するインスタンスを持たない点が挙げられます。少し乱暴な例えかも知れませんが、 AWS Lambda のデータベース版のような仕組みで、データベースを使用するタイミングでデータベースサーバが起動、使い終わったら停止するような動作となり、その間に利用した Aurora Capacity Unit (ACU) の使用量で課金されるといったサービスになります。(正確には ACU 以外にもデータベースストレージと I/O で別途料金は発生します)
Amazon Aurora Serverles の使い所
私の場合は、Amazon RDS for MySQL を社内のシステムで使用していましたが、それを Amazon Aurora Serverles に乗り換えました。このシステムは基本的に営業時間内しか利用しないのと、それほどシビアな応答時間を求められないという前提がありましたので、データベースが起動するまでの時間はさほど気にせずともよく、営業時間外ではコスト面からむしろ停止しておきたいという状況で Amazon Aurora Serverles の利用には適したシステムでした。
一方、 24 時間 365 日 、いかなる時も素早い応答を求められるようなシステムでは、あまり適しているとは思えませんので、システムの特徴を理解した上で適切なサービスを選択することが重要と言えそうです。
Amazon Aurora Serverles のハマりどころ
ハマりどころというのは少し語弊があるかも知れませんが、データベースのコネクションプールを使用しているケースでは少し注意が必要になります。使用しているフレームワークやその設定にも依りますが、コネクションプールを使用していると多くの場合はデータベースに対する接続を恒常的に持ち続けている状態となる為、 Amazon Aurora Serverles がいつまで経っても停止しないという状況に陥ります。この状況を避けるには、コネクションプールの設定を見直したり、コネクションプールを止めるなどの対応が必要になります。
私の場合は、 SpringBoot 2.0 で HikariCP というコネクションプールを利用しておりましたので、この設定を変更する方向で対応しました。変更したのは以下のプロパティのみとなります。
spring.datasource.hikari.minimum-idle=0
spring.datasource.hikari.idle-timeout=180000
spring.datasource.hikari.minimum-idle はコネクションプール内で維持されるアイドル接続の最小数で、 spring.datasource.hikari.idle-timeout はコネクションプール内で接続がアイドル状態に切り替わるまでの時間（ミリ秒）です。
これらの設定を行う事で、 180 秒後に接続はアイドル状態となり、アイドル接続は維持しないという設定から、コネクションプールから接続が破棄されるという状態になります。これで使用がない時はコネクションプールから接続破棄されて、 Amazon Aurora Serverles が停止できる状態を作り出すことができました。
Spring Session との相性
さらにニッチな話になりますが、アプリケーションのセッション管理に Spring Session を利用しており、そのセッションストアに Amazon Aurora Serverles を使用する場合も少し注意が必要になります。 Spring Session は有効期限が切れたセッション情報を削除するクエリを定期的に発行するのですが、デフォルトでは毎分このクエリが発行されます。毎分クエリが発行されると当然 Amazon Aurora Serverles が停止されない状況に陥ります。
このクエリの発行間隔については以下のプロパティで変更可能です。（デフォルト値は 0 * * * * * です）
spring.session.jdbc.cleanup-cron=0 0 0 * * 0
上記の設定値の場合は毎週日曜日 00:00:00 に削除クエリが発行されるようになります。（このプロパティは、 cron とは違って「秒、分、時、日、月、曜日」であることにご注意ください）
アプリケーションに対する影響
私のケースでは上記の設定変更を除くと、JDBC の接続文字列以外は何も変更する必要はありませんでした。データベースのサイズにも依存するのかも知れませんが、少なくとも私が対応したシステムでは Amazon Aurora Serverles は 20〜25 秒あたりで起動しており、一度起動さえしてしまえばこれまでと遜色ないパフォーマンスでアプリケーションが動作しています。
まとめ
コネクションプール周りを除き、従来のリレーショナル・データベースと変わらない扱い方でサーバレスのデータベースに切り替えられるというのが本当に驚きでした。コネクションプールの部分も、知見のある方なら察しがつくと思われますので、記事内のハマるという表現も正直適切では無いのかも知れません。前提さえ合えば、コストや運用面で非常に有効なサービスだと思いますので、一度検討してみてはいかがでしょうか。