De Amazon RDS pour MySQL à Amazon Aurora Serverless J'ai eu l'occasion de passer à, alors j'aimerais vous présenter quelque chose comme un indice. Cet article est basé sur Java, SpringBoot, mais l'essentiel est indépendamment du langage ou du framework, votre environnement est donc approprié. Je vous serais reconnaissant si vous pouviez le lire comme.
Pour plus de détails, veuillez consulter les documents officiels, mais la principale caractéristique est qu'il n'a pas d'instance à gérer. Cela peut être une analogie un peu approximative, mais avec un mécanisme tel que la version de base de données de AWS Lambda, le serveur de base de données démarre lorsque la base de données est utilisée. Le service s'arrêtera lorsque vous aurez fini de l'utiliser et vous serez facturé pour la quantité d'unité de capacité Aurora (ACU) utilisée pendant cette période. (Pour être exact, il y a des frais supplémentaires pour le stockage de la base de données et les E / S en plus de l'ACU)
Dans mon cas, j'utilisais Amazon RDS pour MySQL sur mon système interne, mais je suis passé à Amazon Aurora Serverles. Étant donné que ce système est essentiellement utilisé uniquement pendant les heures ouvrables et qu'il est supposé qu'un temps de réponse très sévère n'est pas nécessaire, vous n'avez pas à vous soucier trop du temps nécessaire au démarrage de la base de données et en dehors des heures ouvrables C'était un système approprié pour utiliser Amazon Aurora Serverles car je voulais l'arrêter pour des raisons de coût.
En revanche, il ne semble pas très adapté à un système qui nécessite une réponse rapide 24 heures sur 24, 365 jours par an, il est donc important de comprendre les caractéristiques du système et de sélectionner le service approprié. C'est vrai.
Il peut être un peu déroutant d'être accro, mais vous devez être un peu prudent si vous utilisez un pool de connexions de base de données. Selon la structure que vous utilisez et ses paramètres, Amazon Aurora Serverles continuera à avoir une connexion constante à la base de données dans de nombreux cas lors de l'utilisation d'un pool de connexions. Sera dans une situation où il ne s'arrêtera pas. Pour éviter cette situation, il est nécessaire de revoir les paramètres du pool de connexions ou d'arrêter le pool de connexions.
Dans mon cas, SpringBoot 2.0 a utilisé un pool de connexions appelé HikariCP, j'ai donc répondu en modifiant ce paramètre. Seules les propriétés suivantes ont été modifiées.
spring.datasource.hikari.minimum-idle=0
spring.datasource.hikari.idle-timeout=180000
«spring.datasource.hikari.minimum-idle» est le nombre minimum de connexions inactives maintenues dans le pool de connexions et «spring.datasource.hikari.idle-timeout» jusqu'à ce que la connexion soit inactive dans le pool de connexions. Temps (millisecondes).
En définissant ces paramètres, la connexion sera inactive après 180 secondes et la connexion sera supprimée du pool de connexions à partir du paramètre selon lequel la connexion inactive ne sera pas maintenue. Cela permettait à la connexion d'être supprimée du pool de connexions lorsqu'elle n'était pas utilisée, créant un état dans lequel Amazon Aurora Serverles pouvait être arrêté.
Pour le rendre encore plus niche, si vous utilisez Spring Session (https://spring.io/projects/spring-session) pour gérer les sessions de votre application et utilisez Amazon Aurora Serverles pour son magasin de sessions. A également besoin d'un peu d'attention. Spring Session émet une requête qui supprime régulièrement les informations de session expirées, mais par défaut, cette requête est émise toutes les minutes. Lorsque des requêtes sont émises toutes les minutes, Amazon Aurora Serverles tombe naturellement dans une situation où il n'est pas arrêté.
Vous pouvez modifier l'intervalle d'émission de cette requête avec les propriétés suivantes. (La valeur par défaut est «0 * * * * *»)
spring.session.jdbc.cleanup-cron=0 0 0 * * 0
Avec les paramètres ci-dessus, la requête de suppression sera émise tous les dimanches à 00:00:00. (Notez que cette propriété est "secondes, minutes, heures, jours, mois, jours" contrairement à cron)
Dans mon cas, à l'exception des changements de configuration ci-dessus, je n'ai pas eu besoin de changer autre chose que la chaîne de connexion JDBC. Cela peut dépendre de la taille de la base de données, mais au moins sur les systèmes que je prend en charge, Amazon Aurora Serverles démarre dans environ 20 à 25 secondes, et une fois démarré, il a les mêmes performances qu'auparavant. L'application est en cours d'exécution.
J'ai été vraiment surpris de pouvoir passer à une base de données sans serveur de la même manière qu'une base de données relationnelle traditionnelle, sauf autour du pool de connexions. La partie pool de connexion est également susceptible d'être comprise par ceux qui ont des connaissances, de sorte que l'expression addictive dans l'article peut ne pas être honnêtement appropriée. Tant que les hypothèses sont respectées, je pense que c'est un service très efficace en termes de coût et de fonctionnement, alors pourquoi ne pas le considérer une fois.
Recommended Posts