Commençons par ce que 4 9 signifie exactement :

Quatre neuf, c’est 4,38 minutes de temps d’arrêt par mois, ou 52,56 minutes par an.

C’est probablement plus qu’acceptable pour presque tous les services sur Internet, pas tous, mais presque tous. Donc, votre courriel est en panne pendant 4 minutes par mois, ce n’est pas la fin du monde. Je veux dire, vous ne le remarquerez probablement même pas. Le temps que vous alliez vérifier Twitter pour voir si ce n’est que vous ou pas, il serait de nouveau opérationnel.

Typiquement, pour obtenir un bon temps de disponibilité, on pense à ajouter de la redondance et de la réplication pour que si un serveur tombe en panne, vous en ayez déjà d’autres en fonctionnement qui prennent immédiatement le relais. Le problème de cette approche est qu’elle est compliquée et coûteuse. Vous avez besoin de plusieurs serveurs, généralement 3 ou plus pour votre application et votre base de données, plus un équilibreur de charge en amont. Et puis vous devez gérer/surveiller toutes ces machines.

Et avec la nouvelle tendance des Microservices où les gens divisent leurs apps en plus petits services, vous devez répéter ces configurations compliquées pour chaque service.

Si vous construisez un Microservice, moins vous avez besoin de « trucs » pour le faire fonctionner, mieux c’est. Vous ne voulez pas avoir à aller configurer une nouvelle base de données répliquée chaque fois que vous voulez jeter ensemble une petite API, n’est-ce pas ? Je veux être super productif, je veux être capable de lancer un service rapidement sans avoir à m’occuper de tous les trucs compliqués d’ops qui font perdre du temps.

Alors je me suis mis à penser, « et s’il y avait un moyen d’être… assez fiable ? ». Je veux dire combien de choses que vous construisez ont réellement besoin d’être hautement disponibles ? Combien de services ne peuvent pas se permettre d’être en panne pendant quelques minutes ici et là ou de perdre un tout petit peu de données une fois dans une lune bleue en raison d’une défaillance fatale du serveur ?

Mon avis est qu’il n’y a pas beaucoup de services qui ne peuvent pas se permettre de perdre une très petite quantité de données et d’avoir quelques minutes de temps d’arrêt par an. Même si vous architecturez l’enfer de votre service, vous aurez probablement toujours des temps d’arrêt de toute façon pour une raison quelconque. Alors pourquoi ne pas rester simple.

D’abord, quelques chiffres : disons qu’en moyenne, une instance AWS EC2 tombe en panne tous les six mois. Je pense que c’est beaucoup moins que cela de nos jours, mais personne ne le sait vraiment, alors nous serons conservateurs. Cela nous donne environ 26,5 minutes pour récupérer l’application tous les six mois tout en ayant 4 9 de temps de disponibilité.

Voici comment vous pouvez obtenir 4 9 sur une seule machine.

Étape 1) Lancer le serveur, déployer l’application et changer le script DNS

La première chose dont nous avons besoin est un script simple qui peut lancer une nouvelle instance, démarrer l’application (Docker rend cela facile) et changer le DNS pour pointer vers la nouvelle instance. Je ne vais pas entrer dans les détails de cette étape dans ce post, mais si vous pouvez faire un script one liner qui peut faire ces étapes, vous êtes bon. Service fails : run script.

Étape 2) Base de données avec Auto Backup et Auto Recover

Si vous pouvez vous assurer que vous avez des sauvegardes très récentes de votre base de données et que celles-ci sont stockées dans un emplacement facilement accessible comme S3, alors vous pouvez créer une application qui peut se récupérer elle-même au démarrage. L’utilisation d’une base de données embarquée rend tout plus simple puisque vous n’avez besoin de déployer qu’une seule chose : votre app.

J’ai beaucoup utilisé BoltDB ces derniers temps, principalement parce que j’écris beaucoup de Go et que Bolt est une simple base de données embarquée disponible dans un package Go que vous utilisez comme toute autre dépendance. Vous n’avez donc pas besoin d’exécuter une base de données distincte à laquelle vous vous connectez et de vous occuper de la maintenir en fonctionnement. Vous utilisez simplement la bibliothèque et les données sont écrites sur votre disque local.

Maintenant, c’est aussi le problème avec Bolt, les données sont uniquement sur votre machine locale aux côtés de votre application. Si la machine tombe en panne, vous perdez toutes vos données.

Et pourquoi ne pas faire une sauvegarde toutes les minutes ou 2 ? Et être capable de récupérer automatiquement à partir de cette sauvegarde lorsque l’app démarre ?

J’ai créé une librairie qui fait exactement cela, appelée Bolt Backup et juste en changeant la ligne d’initialisation de BoltDb, elle sauvegardera automatiquement votre base de données sur S3 et mieux encore, lorsque vous démarrez l’app, elle récupérera à partir de la sauvegarde la plus récente.

Vous pouvez facilement tester cela en ajoutant des données à votre base de données Bolt, en tuant votre app, en supprimant le fichier de données Bolt, puis en redémarrant votre app. Elle continuera là où elle s’est arrêtée, peu importe où vous redémarrez votre app.

Voici un exemple d’app utilisant ceci que vous pouvez essayer : https://github.com/treeder/bolt-backup/tree/master/example

Conclusion

Avec les concepts simples ci-dessus, vous pouvez récupérer votre application en moins de 26 minutes et donc obtenir 4 9 ou mieux de temps de disponibilité. Assurez-vous simplement que tout est automatisé avec un script de lancement et une récupération automatique de la base de données comme la bibliothèque Bolt Backup mentionnée ci-dessus.

La valeur de la simplicité peut parfois être perdue lorsque nous sommes tous excités par le « web scale », mais souvent, vous pouvez vous épargner beaucoup de temps et de chagrin si vous gardez les choses simples. Et beaucoup d’argent.