Comment nous avons suivi des pannes de DNS inhabituelles dans AWS
Nous avons construit SparkPost autour de l'idée qu'un service cloud tel que le nôtre doit être lui-même natif du cloud. Ce n'est pas juste une posture. C'est notre architecture cloud qui sous-tend l'évolutivité, l'élasticité et la fiabilité qui sont des aspects essentiels du service SparkPost. Ces qualités sont d'importantes raisons pour lesquelles nous avons construit notre infrastructure sur Amazon Web Services (AWS) — et c'est pourquoi nous pouvons offrir à nos clients des niveaux de service et des garanties de taux de pointe inégalés par quiconque dans le secteur.
Mais nous ne prétendons pas que nous ne sommes jamais confrontés à des bogues inattendus ou aux limites de la technologie disponible. Nous avons rencontré quelque chose comme cela vendredi dernier, et cet incident a entraîné une lenteur intermittente dans notre service et des retards de livraison pour certains de nos clients.
Tout d'abord, laissez-moi dire que le problème a été résolu ce jour-là. De plus, aucun e-mail ou donnée connexe n'a été perdu. Cependant, si la livraison de vos e-mails a été retardée en raison de ce problème, veuillez accepter mes excuses (en fait, des excuses de la part de toute notre équipe). Nous savons que vous comptez sur nous, et il est frustrant lorsque nous ne performons pas au niveau que vous attendez.
Certaines entreprises sont tentées de balayer des problèmes tels qu'une dégradation de service sous le tapis et d'espérer que personne ne le remarque. Vous avez peut-être expérimenté cela avec des services que vous avez utilisés dans le passé. Je sais que c'est arrivé. Mais ce n'est pas ainsi que nous aimons 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 à l'apprendre.
TL;DR
Nous avons rencontré des limites pratiques non documentées des instances EC2 que nous utilisions pour notre cluster DNS principal. La taille des instances cloud basée sur des spécifications traditionnelles (processeur, mémoire, etc.) fonctionne généralement comme vous l'attendez, mais parfois, ce modèle matériel traditionnel ne s'applique pas. C'est particulièrement vrai dans des cas d'utilisation atypiques où des limites agrégées peuvent entrer en jeu - et il y a des moments où vous vous heurtez brutalement à ces scénarios sans avertissement.
Nous avons rencontré une telle limite vendredi lorsque notre volume de requêtes DNS a créé un schéma d'utilisation du réseau pour lequel notre type d'instance n'était pas préparé. Cependant, parce que cette limite n'était pas évidente dans la documentation ou les métriques standard disponibles, nous ne savions pas que nous l'avions atteinte. Ce que nous avons observé était un taux de pannes DNS très élevé, ce qui à son tour a entraîné des retards intermittents à différents points de notre architecture.
Approfondir sur DNS
Pourquoi notre utilisation de DNS est-elle spéciale ? Eh bien, cela a beaucoup à voir avec la façon dont l'e-mail fonctionne, par rapport au modèle de contenu pour lequel AWS a été à l'origine conçu. La livraison de contenu basée sur le Web fait largement usage de ce qui pourrait être considéré comme des scénarios d'