AWS : une panne « mondiale » ?

AirBnB, Slack, SnapChat par terre ! Les médias se sont fait l'écho (par exemple ici Le Monde avec l'AFP) d'un incident majeur touchant l'infrastructure d'AWS, parlant de « panne mondiale ». Le terme est-il approprié ?

Nb : il ne s'agit pas de "défendre" AWS, ni de nier l'ampleur de l'incident, mais de donner l'opportunité aux moins "tech" de comprendre ce qui se cache derrière.

Quelques exemples d'impacts chez mes clients

L'un de mes clients a toute son infrastructure sur les datacenters d'AWS en France (on parle de "région" de Paris, ou eu-west-3). Il n'a juste eu aucun impact de l'incident. Business as usual. Même trafic, mêmes temps de réponses, même nombre de commandes sur son site d'e-commerce.

Un autre client a une partie de son infra à Paris et l'autre aux Etats-Unis, en Virginie du Nord (us-east-1), la région en cause dans l'incident. Pendant la durée de l'incident, les envois de mails via le service SES ont échoué. Les temps de réponses ont augmenté et le nombre de messages en file d'attente traités par seconde a drastiquement baissé, le débit étant volontairement limité par AWS dans la phase de "recovery" (pour ne pas submerger des machines qui démarrent sous un flux de requêtes d'autant plus volumineux que tout le monde "retry").

Enfin, pendant tout l'incident, j'ai de mon côté été dans l'impossibilité de mettre à jour l'infrastructure de mes clients (ce que je fais habituellement en appelant les services d'AWS par un outil appelé "Terraform").

Un incident régional, des impacts mondiaux

Alors que s'est-il passé ? Sans entrer trop dans les détails techniques, AWS a eu - sur la région us-east-1 un problème d'adressage réseau (DNS) pour un de ses services, DynamoDB, une base de données ultra-performante qui est utilisée par de nombreux autres services AWS (AWS dénombrait environ 70 services impactés).

Pourquoi cet incident, semble-t-il local, a t-il eu un impact si large ? Aurait-il été identique si une autre région, par exemple Europe (Milan), avait connu le même incident ?

Pour comprendre cela, il faut comprendre deux notions clés :

1. Data-Plane vs Control-Plane : pour consommer un service, je mets en place du paramétrage, c'est le control plane ; ce paramétrage est ensuite utilisé par AWS pour opérer une ressource, c'est le data plane. Par exemple : je démarre un cluster de base de données MySQL (control plane), ce cluster sert du trafic SQL, enregistre des transactions sur des disques durs, écrit des logs (data plane).

1. L'empreinte géographique d'un service : certains services AWS sont conçus pour fonctionne à l'échelle d'un data center (pour faire simple, en réalité à l'échelle d'une zone de disponibilité). C'est le cas quand je déploie une machine Linux. D'autres fonctionnent à l'échelle d'une région (de sorte qu'ils sont capable de vivre avec la perte d'un datacenter). D'autres enfin fonctionnent à l'échelle mondiale.

Ces deux notions se conjuguent : par exemple IAM a son control plane centralisé (je définis mes politiques d'autorisation à un seul endroit) puis la configuration est distribuée sur toutes les régions, de sorte que celles-ci peuvent appliquer ces politiques eu toute autonomie (data plane régionalisé).

Le tableau ci-dessous donne quelques exemples :

Que s'est-il passé ?

Il se trouve que la région us-east-1 sert de control plane centralisé pour un certain nombre (voire un nombre certain) de services AWS. Quand un incident majeur survient sur cette région (historiquement tous les 2 à 4 ans), cela impacte donc :

• le control plane de tous ces services
• le data plane des services sur cette région (le data plane des services sur les autres régions est sauf, d'où le business-as-usual de mon premier client).

Quelles leçons en tirer ?

1. Architecturer pour la haute-disponibilité ! « Tout échoue tout le temps, tout tombera en panne un jour» dit le Dr. Werner Vogels, CTO d'Amazon. Si l'incident a eu un tel impact visible du public c'est que les opérateurs des services cités par la presse n'ont pas jugé bon (ou su) architecturer leurs services pour être résilients à la perte de la région us-east-1. Cela peut-être un choix éclairé (mon client précité a choisi d'être KO si la région de Paris tombait, confiant qu'AWS saurait remonter l'infra plus rapidement que lui ne saurait mettre en oeuvre un Plan de Reprise d'Activité, avec toutefois un backup externalisé juste au cas où...)

2. Persister d'abord, traiter ensuite : mon deuxième client ne pouvait pas envoyer ses mails... et les appels d'API pour les envoyer se faisaient au beau milieu du traitement d'une transaction. Retour d'expérience et évolution dans les prochains jours : il va désormais stocker ces tâches dans une file d'attente et la dépiler avec gestion du retry, une dead letter queue etc.

Voilà, vous avez maintenant quelques base sur la conception de l'infrastructure mondiale d'AWS !