From Amazon RDS for MySQL to Amazon Aurora Serverless I had the opportunity to switch to, so I would like to introduce something like a clue. This article is based on Java, SpringBoot, but the essence is regardless of language or framework, so your environment is appropriate. I would appreciate it if you could read it as.
For details, please check the official document etc., but the major feature is that it does not have an instance to manage. It may be a bit rough analogy, but with a mechanism like the database version of AWS Lambda, the database server starts when the database is used. When you finish using it, it will stop, and you will be charged for the amount of Aurora Capacity Unit (ACU) used during that time. (To be exact, there is an additional charge for database storage and I / O in addition to ACU)
In my case, I was using Amazon RDS for MySQL on my internal system, but I switched to Amazon Aurora Serverles. Since this system is basically used only during business hours and it is assumed that a very severe response time is not required, you do not have to worry too much about the time until the database starts, and outside business hours It was a suitable system for using Amazon Aurora Serverles because I wanted to stop it for cost reasons.
On the other hand, it does not seem to be very suitable for a system that requires a quick response 24 hours a day, 365 days a year, so it is important to understand the characteristics of the system and select the appropriate service. That's right.
It may be a bit confusing to be addicted to, but you need to be a little careful if you are using a database connection pool. Depending on the framework you're using and its settings, Amazon Aurora Serverles will last forever because connection pools often keep you connected to your database on a permanent basis. Will fall into a situation where it will not stop. To avoid this situation, it is necessary to review the connection pool settings or stop the connection pool.
In my case, SpringBoot 2.0 used a connection pool called HikariCP, so I responded by changing this setting. Only the following properties have been changed.
spring.datasource.hikari.minimum-idle=0
spring.datasource.hikari.idle-timeout=180000
spring.datasource.hikari.minimum-idle is the minimum number of idle connections maintained in the connection pool, and spring.datasource.hikari.idle-timeout is until the connection is idle in the connection pool. Time (milliseconds).
By making these settings, the connection will be idle after 180 seconds, and the connection will be dropped from the connection pool from the setting that the idle connection is not maintained. This allowed us to drop the connection from the connection pool when not in use, creating a state where Amazon Aurora Serverles could be stopped.
In a niche, if you use Spring Session (https://spring.io/projects/spring-session) to manage your application's sessions and use Amazon Aurora Serverles for that session store. Also needs a little attention. Spring Session periodically issues a query that deletes expired session information, but by default this query is issued every minute. When a query is issued every minute, Amazon Aurora Serverles naturally falls into a situation where it is not stopped.
The issuance interval of this query can be changed with the following properties. (The default value is 0 * * * * *)
spring.session.jdbc.cleanup-cron=0 0 0 * * 0
With the above settings, the delete query will be issued every Sunday at 00:00:00. (Note that this property is "seconds, minutes, hours, days, months, days of the week" unlike cron)
In my case, except for the above configuration changes, I didn't need to change anything other than the JDBC connection string. It may depend on the size of the database, but at least on the systems I support, Amazon Aurora Serverles starts in about 20 to 25 seconds, and once started, it has the same performance as before. The application is running.
I was really surprised to be able to switch to a serverless database in the same way as a traditional relational database, except around the connection pool. The connection pool part can be guessed by those who have knowledge, so the expression addictive in the article may not be honestly appropriate. As long as the assumptions are met, I think it is a very effective service in terms of cost and operation, so why not consider it once.
Recommended Posts