Quelle est la bonne stratégie pour garder mon site en ligne lorsque S3 se déconnecte?

Quelle est la bonne stratégie pour garder mon site en ligne lorsque S3 se déconnecte?

Si S3 US East 1 se déconnecte, comment dois-je configurer / structurer mon application pour empêcher que tout mon site ne soit déconnecté?

Quelles sont les meilleures stratégies pour se diversifier dans ce genre de situation?

En mars 2015, Amazon AWS a annoncé qu'il prend en charge la réplication S3 dans toutes les régions. Lorsqu'une certaine région de S3 se déconnecte, vous pouvez diffuser des fichiers depuis votre miroir dans une autre région.

^{source: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/}

La pratique consistant à maintenir votre infrastructure en ligne en effectuant un basculement vers une autre région est complexe, mais S3 est un composant relativement petit et simple. Netflix a un excellent article sur leur expérience avec Chaos Gorilla.

Cela s'applique également à la dégradation des services, comme l'augmentation de la latence. Pas seulement lorsqu'un service dont vous dépendez est complètement hors ligne. Netflix a également un article à ce sujet: Chaos Engineering Upgraded .

Ce que vous demandez, c'est essentiellement une haute disponibilité. Pour rendre un système hautement disponible, vous avez besoin de trois choses:

1. Éliminez les points de défaillance uniques
2. Un mécanisme pour passer d'un point de terminaison à un autre
3. Un moyen de détecter les pannes

Éliminez les points de défaillance uniques

Dans le cas de S3, le point n ° 1 est adressé, comme l'a souligné Evgeny, par réplication inter-régions S3 .

Cependant, la réplication n'est pas instantanée et vous voudrez vérifier si vous souhaitez rendre votre réplication d'application consciente ou non. En cas de panne, il est possible que quelque chose qui a été écrit dans votre compartiment source ne soit pas encore arrivé (n'a pas été répliqué) dans le compartiment de destination. Vous devez penser à la manière dont l'application gérerait un tel scénario. Cela dépend vraiment du type de données, de ce qui en est fait et (potentiellement) des utilisateurs finaux ou des attentes de la direction.

Un mécanisme pour passer d'un point de terminaison à un autre

Pour S3, cela signifie qu'en cas de panne, vous souhaitez que l'application arrête la lecture et l'écriture depuis / vers le compartiment A et utilise le compartiment B à la place.

Pour autant que je sache, comment y parvenir est à vous de décider pour l'instant. Certains autres services AWS offrent des basculements totalement transparents, mais je ne suis pas au courant d'une telle chose pour S3 pour le moment.

Il existe différentes manières d'y parvenir. Un exemple utilise un proxy qui acheminera le trafic vers le compartiment approprié. Pendant une panne, vous devez mettre à jour / modifier le proxy pour acheminer le trafic vers un compartiment non affecté par la panne. Un autre exemple serait de rendre votre configuration d'application dynamique et de la stocker dans un magasin de valeurs-clés. Si l'application lit assez souvent le magasin KV pour les propriétés mises à jour, vous pouvez changer d'où vous lisez et où écrire (Spring Cloud prend en charge un écouteur "EnvironmentChange", par exemple).

Un moyen de détecter les pannes

Eh bien, celui-là est facile, je pense. Configurez simplement une boucle écriture + lecture et alertez dès que quelque chose ne va pas :)

Notes de clôture

• Si votre application écrit dans le compartiment, vous devez penser à ce qui se passerait en cas de basculement. Toutes les écritures ont-elles atteint le compartiment de destination (et pouvez-vous le dire)? Pouvez-vous autoriser les écritures dans le compartiment de destination (ce qui en fait le nouveau "principal")? Une planification minutieuse évitera les scissions de cerveaux ou les mises à jour perdues.
• Selon votre SLA, vous souhaiterez peut-être que les points # 2 et # 3 soient automatisés ou automatiques. Cela nécessite une planification, des outils et des tests supplémentaires, mais les scripts bien écrits réagiront toujours plus rapidement et de manière plus prévisible que les humains (les échecs ont également la fâcheuse habitude de se produire au milieu de la nuit lorsque l'intervention humaine est quelque chose de dangereux.
• Il convient de mentionner que même la réplication entre régions n'élimine pas complètement les points de défaillance uniques. Bien sûr, si une région tombe en panne, vous êtes couvert. Mais que se passe-t-il si une panne AWS à l'échelle des États-Unis se produit? Azure a connu une panne partielle mais mondiale l'année dernière et une en 2014 également.