La panne AWS d’un point de vue de fournisseur de services

La panne AWS d’un point de vue de fournisseur de services

Attention aux chutes de membres !

Vous avez probablement déjà entendu à propos de la panne d’AWS dimanche dernier vers midi PDT. Le bruit de ça problème “mineur” de réseau et de stockage dans l’une des régions de données les plus fréquentées de l’Amazonie forêt nuage a été entendu haut et fort. Même avant que ça ne tombe zone les feuilles des arbres ont touché le sol, des rapports sur l’effondrement de certaines des marques sociales les plus connues (c’est-à-dire Instagram, Vine et IFTTT) a commencé à arriver.

Comme d’habitude, AWS n’a pas divulgué toute l’étendue de l’impact de l’incident, mais il va de soi qu’il y a eu d’autres victimes, quoique moins importantes. Nos services Redis Cloud et Memcached Cloud utilisent les ressources de cette zone, et nous y gérons un certain nombre de clusters assez importants. Nous utilisons fortement le réseau et le stockage, compte tenu de la nature de nos bases de données en mémoire répliquées et durables, donc naturellement notre tableau de bord s’est allumé en rouge vif au premier bruit d’éclatement sinistre.

D’après l’étendue des dommages que nous avons surveillés dans notre environnement, nous pensons qu’il est possible que 15 à 30 % des services de cette zone aient été affectés par l’événement. Même après que le réseau a commencé à se dégrader, nos systèmes ont heureusement pu résister à l’interruption. Nos flux de réplication n’étaient pas en retard pour la plupart, et l’impact sur la latence de réponse était relativement faible.

Les choses ont semblé un peu fragiles pour la disponibilité de nos instances non multi-AZ pendant un certain temps, mais nous avons tenu bon. Mais juste au moment où il semblait que le pire était passé et que les secousses s’atténuaient, nous avons connu une chute des performances avec le déclin accéléré de notre stockage.
Suspense.

Le saviez-vous?

Bien que quelque peu contre-intuitif au début, la base de données en mémoire utilise le stockage. Cependant, ils l’utilisent uniquement pour stocker des données au lieu de lire et d’écrire depuis/vers elles comme une base de données sur disque.

L’écriture des données sur le disque confère à la base de données en mémoire de la persistance – une caractéristique hautement souhaitable qui s’avère très pratique lors de la récupération après un effondrement, mais c’est une autre histoire. Cependant, cela signifie également que lorsque le stockage devient indisponible, la base de données ne peut pas garantir la durabilité des données. Elle peut toujours répondre aux demandes de lecture, mais dans la plupart des cas, une base de données en lecture seule est comme un poisson sur un vélo.

C’est pourquoi la plupart des bases de données en mémoire sont conçues pour cesser de fonctionner sans stockage accessible, y compris Redis.

Et maintenant, revenons à notre programmation régulière…

Le stockage défaillant sur plusieurs nœuds simultanément, nos systèmes ont fait la seule chose qu’ils pouvaient : contourner l’échec pour se rétablir et maintenir le service opérationnel.

Les nœuds concernés ont continué à servir les instances Redis Cloud non persistantes tandis qu’une action immédiate a été prise avec les instances persistantes. Les instances Redis Cloud activées pour la persistance ont été rapidement migrées vers des ressources de serveur et de stockage non affectées avant de provoquer une interruption de notre service. Certes, la charge supplémentaire que nous mettons sur le réseau et le stockage en déplaçant les données d’un endroit à l’autre n’était pas destinée à résoudre les problèmes en développement, mais visait à faire une retraite précipitée vers les abris voisins.

Finalement, nous avons réussi à dégager la zone de danger – en moins de 20 minutes.

Une fois la poussière retombée, nous avons mené une enquête rapide auprès de nos utilisateurs et avons été soulagés d’apprendre qu’aucun n’avait rencontré de problèmes avec notre service pendant cette période (malgré que nos journaux ressemblaient au travail d’un meurtrier psychotique à la hache). Bien sûr, le scénario aurait pu être différent si cette panne avait été légèrement moins mineure.

Nous sommes heureux que ce ne soit pas le cas et nous nous sentons validés pour obtenir une preuve réelle de la façon dont un système conçu pour la stabilité dynamique fait face aux défis pour lesquels il a été conçu.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *