Nous avons rencontré des limites pratiques non documentées des instances EC2 que nous utilisions pour notre cluster DNS principal. Dimensionner les instances cloud en fonction des spécifications traditionnelles (processeur, mémoire, etc.) fonctionne généralement comme on pourrait s'y attendre, mais parfois ce modèle matériel traditionnel ne s'applique pas.
Business in a box.
Découvrez nos solutions.
Parlez à notre équipe de vente
Comment Nous Avons Traqué des Pannes DNS Inhabituelles dans AWS
Nous avons construit SparkPost autour de l'idée qu'un service cloud comme le nôtre doit être lui-même natif du cloud. Ce n'est pas juste de la posture. C'est notre architecture cloud qui sous-tend la scalabilité, l'élasticité et la fiabilité qui sont des aspects fondamentaux du service SparkPost. Ces qualités sont les principales raisons pour lesquelles nous avons construit notre infrastructure sur Amazon Web Services (AWS)—et c'est pourquoi nous pouvons offrir à nos clients des garanties de niveau de service et de taux d'explosion inégalées par quiconque dans le secteur.
Mais nous ne prétendons pas que nous ne sommes jamais confrontés à des bugs imprévus ou aux limites de la technologie disponible. Nous avons rencontré quelque chose de similaire vendredi dernier, et cet incident a entraîné une lenteur intermittente de notre service et des retards de livraison pour certains de nos clients.
Tout d'abord, permettez-moi de dire que le problème a été résolu le même jour. De plus, aucun e-mail ou donnée associée n'a été perdu. Cependant, si la livraison de vos e-mails a été ralentie à cause de ce problème, veuillez accepter mes excuses (en fait, les excuses de toute notre équipe). Nous savons que vous comptez sur nous, et c’est frustrant quand nous ne sommes pas à la hauteur de vos attentes.
Certaines entreprises sont tentées de balayer sous le tapis des problèmes comme une dégradation de service et espèrent que personne ne le remarque. Vous avez peut-être déjà vécu cela avec des services que vous avez utilisés dans le passé. Je sais que c'est mon cas. Mais ce n'est pas notre façon de faire des affaires.
Je voulais écrire sur cet incident pour une autre raison également : nous avons appris quelque chose de vraiment intéressant et précieux sur notre architecture cloud AWS. Les équipes construisant d'autres services cloud pourraient être intéressées à en apprendre davantage à ce sujet.
TL;DR
Approfondir dans DNS
Pourquoi notre utilisation de DNS est-elle spéciale ? Eh bien, cela a beaucoup à voir avec la manière dont fonctionne l'email, par rapport au modèle de contenu pour lequel AWS a été initialement conçu. La livraison de contenu basée sur le Web utilise fortement ce qui pourrait être considéré comme des scénarios d'appel « pull » classiques : un client demande des données, qu'il s'agisse de HTML, de flux vidéo ou d'autre chose, depuis le cloud. Mais les cas d'utilisation pour les fournisseurs de services de messagerie comme SparkPost sont des exceptions au scénario AWS habituel. Dans notre cas, nous effectuons beaucoup de poussées de trafic sortant : en particulier, les emails (et d'autres types de messages comme les SMS ou les notifications push mobiles). Et ce trafic en mode push repose fortement sur DNS.
Si vous êtes familier avec DNS, vous savez peut-être que c'est généralement des données assez légères. Pour demander une page HTML donnée, vous devez d'abord demander où cette page peut être trouvée sur Internet, mais cette demande est une fraction de la taille du contenu que vous récupérez.
Les emails, cependant, font un usage exceptionnellement intensif de DNS pour rechercher les domaines de livraison — par exemple, SparkPost envoie des milliards d'emails à plus d'un million de domaines uniques chaque mois. Pour chaque email que nous livrons, nous devons effectuer un minimum de deux recherches DNS, et l'utilisation des enregistrements DNS « txt » pour des technologies anti-phishing comme SPF et DKIM signifie que DNS est également requis pour recevoir du courrier. Ajoutez à cela notre utilisation plus traditionnelle des services API AWS pour nos applications, et il est difficile d'exagérer l'importance de DNS pour notre infrastructure.
Tout cela signifie que nous nous sommes retrouvés dans une condition inhabituelle où notre volume croissant de messages sortants a créé un volume de trafic DNS qui a atteint une limite de débit réseau globale sur des types d'instances qui semblaient par ailleurs avoir suffisamment de ressources pour gérer cette charge. Et comme les attaques par déni de service sur l'infrastructure Dyn DNS ont démontré l'année dernière, lorsque DNS tombe en panne, tout tombe en panne. (C'est quelque chose que toute personne qui construit des systèmes reposant sur DNS sait déjà très bien.)
Les problèmes DNS soudains ont déclenché une réponse de nos équipes d'exploitation et d'ingénierie de la fiabilité pour identifier le problème. Elles ont collaboré avec nos partenaires chez Amazon pour intensifier les opérations AWS. En travaillant ensemble, nous avons identifié la cause et une solution. Nous avons déployé un groupe de serveurs de noms de plus grande capacité avec un accent accru sur la capacité réseau qui pourrait répondre à nos besoins DNS sans franchir les lignes rouges du débit. Heureusement, comme tout cela était au sein d'AWS, nous avons pu mettre en place les nouvelles instances et même redimensionner les instances existantes très rapidement. DNS a repris un comportement normal, les échecs de recherche ont cessé, et nous (ainsi que la livraison des messages sortants) étions de retour sur la bonne voie.
Pour atténuer ce problème spécifique à l'avenir, nous apportons également des modifications à l'architecture DNS pour mieux isoler nos composants principaux de l'impact des rencontres avec des seuils similaires, inattendus. Nous travaillons également avec l'équipe Amazon pour déterminer des modèles de surveillance appropriés qui nous donneront un avertissement adéquat pour éviter un incident similaire avant qu'il n'affecte l'un de nos clients.
AWS et la lueur d'argent du Cloud
Je ne veux pas minimiser l'impact de cet incident sur nos clients. Mais notre capacité à identifier le problème sous-jacent comme une interaction inattendue de notre cas d'usage avec l'infrastructure AWS—puis à trouver une solution très rapidement—est en grande partie due à la façon dont nous avons construit SparkPost, et à notre excellente relation avec l'équipe d'Amazon.
Le superbe corps d'opérations de SparkPost, notre équipe d'Ingénierie de Fiabilité du Site (SRE), et nos principaux architectes techniques travaillent avec Amazon chaque jour. Les forces de l'infrastructure d'AWS nous ont donné un réel avantage pour optimiser l'architecture de SparkPost pour le cloud. Travailler si étroitement avec AWS au cours des deux dernières années nous a également beaucoup appris sur le déploiement de l'infrastructure AWS et sur la rapidité d'exécution, et nous avons également le bénéfice d'un soutien approfondi de l'équipe AWS.
Si nous avions dû contourner une limitation similaire dans un modèle de centre de données traditionnel, quelque chose comme ça pourrait prendre des jours voire des semaines à résoudre complètement. Cette agilité et cette réactivité sont juste deux des raisons pour lesquelles nous avons misé notre entreprise sur le cloud et AWS. Ensemble, le genre d'expertise en cloud que nos entreprises partagent est difficile à trouver. Amazon a été un excellent partenaire commercial pour nous, et nous sommes vraiment fiers de ce que nous avons accompli avec la pile AWS.
SparkPost est le premier service de livraison d'e-mails qui a été conçu pour le cloud dès le départ. Nous envoyons plus d'e-mails à partir d'une véritable plateforme cloud que quiconque, et parfois cela signifie entrer en territoire inconnu. C'est une vérité fondamentale de l'informatique que vous ne savez pas quels défis surviennent à grande échelle jusqu'à ce que vous les rencontriez. Nous en avons trouvé un sur AWS, mais notre réponse rapide est un excellent exemple de la flexibilité que le cloud rend possible. C'est aussi notre engagement envers nos clients.
Que vous construisiez votre propre infrastructure sur AWS, ou que vous soyez un client SparkPost qui profite de la nôtre, j'espère que cette explication de ce qui s'est passé vendredi dernier, et comment nous l'avons résolu, vous a été utile.
