Le jour où notre DNS a atteint une limite non documentée dans AWS
Oiseau
7 févr. 2017
Ingénierie
1 min read
Points Clés
SparkPost a rencontré une limite de débit réseau non documentée sur un type d'instance AWS EC2 spécifique qui alimentait son cluster DNS principal.
Le dimensionnement traditionnel des instances (CPU, RAM, disque) n’a pas révélé ce goulot d’étranglement car le problème était lié au trafic réseau DNS agrégé, et non à une pénurie de ressources.
L'utilisation du DNS pour les emails sortants à haut volume est exceptionnellement lourde : SparkPost génère des millions de requêtes DNS pour l’acheminement des domaines, l’authentification (SPF/DKIM) et les interactions avec l'API AWS.
L’échec DNS n’était pas dû à des réponses DNS mal formées - en fait, les seuils de capacité réseau au niveau de l'instance ont été silencieusement dépassés, entraînant des échecs de requêtes généralisés.
Comme AWS ne documente pas explicitement ces limites réseau douces, diagnostiquer le problème a nécessité une collaboration approfondie entre l’équipe SRE de SparkPost et les ingénieurs AWS.
L'équipe a résolu le problème en migrant les services DNS vers des types d'instances plus grands avec une plus grande largeur de bande réseau et en repensant certaines parties de l’architecture DNS pour une meilleure isolation et un meilleur basculement.
Aucune donnée ni message client n'a été perdu, mais l'événement a souligné comment les architectures cloud-native peuvent atteindre des limites inattendues à grande échelle — et à quelle vitesse elles peuvent être corrigées grâce à l'élasticité AWS.
Points forts des Q&A
Que s'est-il passé ?
Le cluster DNS de SparkPost a atteint un plafond de débit réseau AWS inattendu, entraînant l'échec intermittent des recherches DNS — ce qui a retardé la livraison des emails.
Pourquoi DNS a-t-il cassé du tout ?
Le DNS est extrêmement dépendant pour les e-mails sortants. Chaque envoi nécessite plusieurs recherches (MX, TXT, SPF, DKIM), donc un volume d'envoi élevé = un trafic DNS massif.
Ce modèle de trafic a dépassé une limite non documentée sur le type d'instance EC2 hébergeant les serveurs de noms.
Comment le DNS pour les emails est-il différent des applications web ?
Web apps principalement tirent du contenu (les clients demandent des données).
Services de livraison d'email poussent le trafic, déclenchant beaucoup plus de recherches DNS — souvent des milliards par mois.
L'email dépend du DNS pour le routage, la validation de sécurité, et la basculement.
Comment la défaillance s'est-elle manifestée ?
Les requêtes DNS ont commencé à échouer ou à expirer
Les files d'attente de livraison se sont accumulées
La latence a augmenté dans certaines parties du système
Rien n'a été perdu — juste retardé.
Pourquoi était-ce difficile à diagnostiquer?
La limite n'était pas documentée
La surveillance AWS ne montrait pas explicitement le goulot d'étranglement
Toutes les métriques traditionnelles (CPU, RAM, disque) semblaient normales
Le problème n'est apparu que sous un modèle de trafic DNS spécifique et à volume élevé.
Comment SparkPost l'a-t-il réparé ?
Mise à niveau vers les types d'instances EC2 avec des plafonds de débit réseau plus élevés
Réorganisé les clusters DNS pour être plus résilients aux pics de trafic agrégés
Travaillé avec AWS pour identifier de meilleurs modèles de signal/alerte afin de détecter cela plus tôt
Les données ou le courrier du client ont-ils été perdus ?
Non — seule la livraison a ralenti. Une fois que le DNS s'est stabilisé, tout le courrier a repris une livraison normale.
Quelle est la leçon plus large?
Même dans le cloud, vous pouvez rencontrer des contraintes de mise à l'échelle invisibles — mais les conceptions natives du cloud vous offrent la flexibilité de récupérer rapidement.
L'élasticité, le partenariat avec AWS et les pratiques SRE solides rendent possible une récupération rapide.
Comment nous avons suivi des défaillances DNS inhabituelles dans AWS
Nous avons construit SparkPost autour de l'idée qu'un service cloud comme le nôtre doit être natif du cloud. Ce n'est pas seulement un discours. 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 raisons principales pour lesquelles nous avons bâti notre infrastructure au sommet de Amazon Web Services (AWS) — et c'est pourquoi nous pouvons offrir à nos clients des garanties de niveau de service et de taux d'éclatement inégalées par quiconque dans le domaine.
Mais nous ne prétendons pas que nous ne sommes jamais confrontés à des bugs inattendus ou aux limites de la technologie disponible. Nous avons rencontré un problème de ce type vendredi dernier, et cet incident a conduit à 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, je vous prie d'accepter mes excuses (en fait, les excuses de toute notre équipe). Cet incident a renforcé l'importance d'avoir des stratégies complètes de sauvegarde en place - que vous utilisiez les sauvegardes de la base de données PostgreSQL ou d'autres méthodes de protection des données pour assurer la continuité des activités lors de défis d'infrastructure. Nous savons que vous comptez sur nous, et il est frustrant lorsque nous ne fonctionnons pas au niveau que vous attendez.
Certaines entreprises sont tentées de passer des problèmes comme une dégradation de service sous le tapis et espèrent que personne ne le remarque. Vous avez peut-être 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 ainsi que nous aimons faire des affaires.
Je voulais également écrire à propos de cet incident pour une autre raison : nous avons appris quelque chose de vraiment intéressant et précieux sur notre architecture cloud AWS. Les équipes qui développent d'autres services cloud pourraient être intéressées à l'apprendre.
Nous avons construit SparkPost autour de l'idée qu'un service cloud comme le nôtre doit être natif du cloud. Ce n'est pas seulement un discours. 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 raisons principales pour lesquelles nous avons bâti notre infrastructure au sommet de Amazon Web Services (AWS) — et c'est pourquoi nous pouvons offrir à nos clients des garanties de niveau de service et de taux d'éclatement inégalées par quiconque dans le domaine.
Mais nous ne prétendons pas que nous ne sommes jamais confrontés à des bugs inattendus ou aux limites de la technologie disponible. Nous avons rencontré un problème de ce type vendredi dernier, et cet incident a conduit à 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, je vous prie d'accepter mes excuses (en fait, les excuses de toute notre équipe). Cet incident a renforcé l'importance d'avoir des stratégies complètes de sauvegarde en place - que vous utilisiez les sauvegardes de la base de données PostgreSQL ou d'autres méthodes de protection des données pour assurer la continuité des activités lors de défis d'infrastructure. Nous savons que vous comptez sur nous, et il est frustrant lorsque nous ne fonctionnons pas au niveau que vous attendez.
Certaines entreprises sont tentées de passer des problèmes comme une dégradation de service sous le tapis et espèrent que personne ne le remarque. Vous avez peut-être 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 ainsi que nous aimons faire des affaires.
Je voulais également écrire à propos de cet incident pour une autre raison : nous avons appris quelque chose de vraiment intéressant et précieux sur notre architecture cloud AWS. Les équipes qui développent d'autres services cloud pourraient être intéressées à l'apprendre.
Nous avons construit SparkPost autour de l'idée qu'un service cloud comme le nôtre doit être natif du cloud. Ce n'est pas seulement un discours. 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 raisons principales pour lesquelles nous avons bâti notre infrastructure au sommet de Amazon Web Services (AWS) — et c'est pourquoi nous pouvons offrir à nos clients des garanties de niveau de service et de taux d'éclatement inégalées par quiconque dans le domaine.
Mais nous ne prétendons pas que nous ne sommes jamais confrontés à des bugs inattendus ou aux limites de la technologie disponible. Nous avons rencontré un problème de ce type vendredi dernier, et cet incident a conduit à 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, je vous prie d'accepter mes excuses (en fait, les excuses de toute notre équipe). Cet incident a renforcé l'importance d'avoir des stratégies complètes de sauvegarde en place - que vous utilisiez les sauvegardes de la base de données PostgreSQL ou d'autres méthodes de protection des données pour assurer la continuité des activités lors de défis d'infrastructure. Nous savons que vous comptez sur nous, et il est frustrant lorsque nous ne fonctionnons pas au niveau que vous attendez.
Certaines entreprises sont tentées de passer des problèmes comme une dégradation de service sous le tapis et espèrent que personne ne le remarque. Vous avez peut-être 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 ainsi que nous aimons faire des affaires.
Je voulais également écrire à propos de cet incident pour une autre raison : nous avons appris quelque chose de vraiment intéressant et précieux sur notre architecture cloud AWS. Les équipes qui développent 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. Dimensionner les instances cloud en fonction des spécifications traditionnelles (processeur, mémoire, etc.) fonctionne généralement comme prévu, 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 globales peuvent entrer en jeu, et il arrive que vous vous retrouviez dans ces scénarios sans avertissement.
Nous avons atteint 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, comme 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 très élevé d'échecs DNS, ce qui a entraîné à son tour des retards intermittents à différents points de notre architecture.
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 prévu, 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 globales peuvent entrer en jeu, et il arrive que vous vous retrouviez dans ces scénarios sans avertissement.
Nous avons atteint 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, comme 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 très élevé d'échecs DNS, ce qui a entraîné à son tour des retards intermittents à différents points de notre architecture.
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 prévu, 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 globales peuvent entrer en jeu, et il arrive que vous vous retrouviez dans ces scénarios sans avertissement.
Nous avons atteint 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, comme 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 très élevé d'échecs DNS, ce qui a entraîné à son tour des retards intermittents à différents points de notre architecture.
Approfondir le DNS
Pourquoi notre utilisation du DNS est-elle spéciale ? Eh bien, cela a beaucoup à voir avec le fonctionnement des e-mails, comparé au modèle de contenu pour lequel AWS a été initialement conçu. La diffusion de contenu basée sur le web fait un usage intensif de ce que l’on pourrait considérer comme des scénarios classiques de « pull » entrants : un client demande des données, qu'il s'agisse de HTML, de flux vidéo ou de n'importe quoi d'autre provenant du 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 push de trafic sortant : spécifiquement, des e-mails (et d'autres types de messages comme les SMS ou les notifications push mobiles). Et ce trafic de type push repose fortement sur le DNS.
Si vous êtes familier avec le DNS, vous savez peut-être qu'il s'agit généralement de 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 représente une fraction de la taille du contenu que vous récupérez.
L'e-mail, cependant, utilise exceptionnellement le DNS de manière intensive pour rechercher les domaines de livraison - par exemple, SparkPost envoie plusieurs milliards d'e-mails vers plus d'un million de domaines uniques chaque mois. Pour chaque e-mail que nous livrons, nous devons effectuer un minimum de deux consultations DNS, et l'utilisation de records DNS « txt » pour des technologies anti-phishing comme SPF et DKIM signifie que le DNS est également requis pour recevoir des mails. Ajoutez à cela notre utilisation plus traditionnelle des services API d'AWS pour nos applications, et il est difficile d'exagérer l'importance du DNS pour notre infrastructure.
Tout cela signifie que nous avons rencontré 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 agrégé sur des types d'instances qui semblaient autrement avoir des ressources suffisantes pour traiter cette charge. Et comme les attaques par déni de service sur l'infrastructure DNS de Dyn l'an dernier l’ont démontré, lorsque le DNS tombe en panne, tout tombe en panne. (C'est quelque chose que quiconque construit des systèmes s'appuyant sur le DNS sait déjà très bien.)
Les problèmes soudains de DNS ont déclenché une réponse de nos équipes d'exploitation et d'ingénierie de la fiabilité pour identifier le problème. Ils ont collaboré avec nos partenaires chez Amazon pour escalader du côté des opérations AWS. En travaillant ensemble, nous avons identifié la cause et une solution. Nous avons déployé un cluster de serveurs de noms de plus grande capacité avec un plus grand accent sur la capacité réseau pouvant répondre à nos besoins DNS sans dépasser les lignes rouges pour le débit. Heureusement, comme tout cela était dans AWS, nous avons pu lancer les nouvelles instances et même redimensionner les instances existantes très rapidement. Le DNS a repris un comportement normal, les échecs de consultation ont cessé, et nous (et 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 de rencontres avec des seuils similaires, inattendus. Nous travaillons également avec l'équipe d'Amazon pour déterminer des modèles de surveillance appropriés qui nous donneront un avertissement adéquat pour prévenir un incident similaire avant qu'il n'affecte un de nos clients.
Sujet | Charge de travail typique AWS | Charge de travail des e-mails sortants de SparkPost |
|---|---|---|
Modèle de trafic | Surtout des demandes de « pull » entrants (pages web, API, médias) | Fort trafic de « push » sortant (milliards d'e-mails) |
Dépendance au DNS | Légère : 1 à 2 consultations par demande de contenu | Très forte : plusieurs consultations DNS par e-mail + vérifications TXT SPF/DKIM |
Volume de requêtes | Prévisible et proportionnel à l'activité des utilisateurs | Explose avec des campagnes sortantes ciblant des millions de domaines |
Type de goulot d'étranglement | Limites du CPU, de la mémoire ou du stockage | Limites de débit réseau agrégé sur les types d'instances |
Mode de défaillance | Latence dégradée ou délai d'expiration de l’API | Échecs de consultation DNS causant des retards de livraison |
Visibilité | Limites généralement documentées et apparentes dans les métriques | Le plafond de débit n'était pas documenté et invisible dans CloudWatch |
Approche d'atténuation | Dimensionner les ressources des instances ou ajouter une mise en cache | Migrer vers des familles d'instances à plus haut débit + refonte de l'architecture DNS |
Pourquoi notre utilisation du DNS est-elle spéciale ? Eh bien, cela a beaucoup à voir avec le fonctionnement des e-mails, comparé au modèle de contenu pour lequel AWS a été initialement conçu. La diffusion de contenu basée sur le web fait un usage intensif de ce que l’on pourrait considérer comme des scénarios classiques de « pull » entrants : un client demande des données, qu'il s'agisse de HTML, de flux vidéo ou de n'importe quoi d'autre provenant du 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 push de trafic sortant : spécifiquement, des e-mails (et d'autres types de messages comme les SMS ou les notifications push mobiles). Et ce trafic de type push repose fortement sur le DNS.
Si vous êtes familier avec le DNS, vous savez peut-être qu'il s'agit généralement de 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 représente une fraction de la taille du contenu que vous récupérez.
L'e-mail, cependant, utilise exceptionnellement le DNS de manière intensive pour rechercher les domaines de livraison - par exemple, SparkPost envoie plusieurs milliards d'e-mails vers plus d'un million de domaines uniques chaque mois. Pour chaque e-mail que nous livrons, nous devons effectuer un minimum de deux consultations DNS, et l'utilisation de records DNS « txt » pour des technologies anti-phishing comme SPF et DKIM signifie que le DNS est également requis pour recevoir des mails. Ajoutez à cela notre utilisation plus traditionnelle des services API d'AWS pour nos applications, et il est difficile d'exagérer l'importance du DNS pour notre infrastructure.
Tout cela signifie que nous avons rencontré 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 agrégé sur des types d'instances qui semblaient autrement avoir des ressources suffisantes pour traiter cette charge. Et comme les attaques par déni de service sur l'infrastructure DNS de Dyn l'an dernier l’ont démontré, lorsque le DNS tombe en panne, tout tombe en panne. (C'est quelque chose que quiconque construit des systèmes s'appuyant sur le DNS sait déjà très bien.)
Les problèmes soudains de DNS ont déclenché une réponse de nos équipes d'exploitation et d'ingénierie de la fiabilité pour identifier le problème. Ils ont collaboré avec nos partenaires chez Amazon pour escalader du côté des opérations AWS. En travaillant ensemble, nous avons identifié la cause et une solution. Nous avons déployé un cluster de serveurs de noms de plus grande capacité avec un plus grand accent sur la capacité réseau pouvant répondre à nos besoins DNS sans dépasser les lignes rouges pour le débit. Heureusement, comme tout cela était dans AWS, nous avons pu lancer les nouvelles instances et même redimensionner les instances existantes très rapidement. Le DNS a repris un comportement normal, les échecs de consultation ont cessé, et nous (et 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 de rencontres avec des seuils similaires, inattendus. Nous travaillons également avec l'équipe d'Amazon pour déterminer des modèles de surveillance appropriés qui nous donneront un avertissement adéquat pour prévenir un incident similaire avant qu'il n'affecte un de nos clients.
Sujet | Charge de travail typique AWS | Charge de travail des e-mails sortants de SparkPost |
|---|---|---|
Modèle de trafic | Surtout des demandes de « pull » entrants (pages web, API, médias) | Fort trafic de « push » sortant (milliards d'e-mails) |
Dépendance au DNS | Légère : 1 à 2 consultations par demande de contenu | Très forte : plusieurs consultations DNS par e-mail + vérifications TXT SPF/DKIM |
Volume de requêtes | Prévisible et proportionnel à l'activité des utilisateurs | Explose avec des campagnes sortantes ciblant des millions de domaines |
Type de goulot d'étranglement | Limites du CPU, de la mémoire ou du stockage | Limites de débit réseau agrégé sur les types d'instances |
Mode de défaillance | Latence dégradée ou délai d'expiration de l’API | Échecs de consultation DNS causant des retards de livraison |
Visibilité | Limites généralement documentées et apparentes dans les métriques | Le plafond de débit n'était pas documenté et invisible dans CloudWatch |
Approche d'atténuation | Dimensionner les ressources des instances ou ajouter une mise en cache | Migrer vers des familles d'instances à plus haut débit + refonte de l'architecture DNS |
Pourquoi notre utilisation du DNS est-elle spéciale ? Eh bien, cela a beaucoup à voir avec le fonctionnement des e-mails, comparé au modèle de contenu pour lequel AWS a été initialement conçu. La diffusion de contenu basée sur le web fait un usage intensif de ce que l’on pourrait considérer comme des scénarios classiques de « pull » entrants : un client demande des données, qu'il s'agisse de HTML, de flux vidéo ou de n'importe quoi d'autre provenant du 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 push de trafic sortant : spécifiquement, des e-mails (et d'autres types de messages comme les SMS ou les notifications push mobiles). Et ce trafic de type push repose fortement sur le DNS.
Si vous êtes familier avec le DNS, vous savez peut-être qu'il s'agit généralement de 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 représente une fraction de la taille du contenu que vous récupérez.
L'e-mail, cependant, utilise exceptionnellement le DNS de manière intensive pour rechercher les domaines de livraison - par exemple, SparkPost envoie plusieurs milliards d'e-mails vers plus d'un million de domaines uniques chaque mois. Pour chaque e-mail que nous livrons, nous devons effectuer un minimum de deux consultations DNS, et l'utilisation de records DNS « txt » pour des technologies anti-phishing comme SPF et DKIM signifie que le DNS est également requis pour recevoir des mails. Ajoutez à cela notre utilisation plus traditionnelle des services API d'AWS pour nos applications, et il est difficile d'exagérer l'importance du DNS pour notre infrastructure.
Tout cela signifie que nous avons rencontré 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 agrégé sur des types d'instances qui semblaient autrement avoir des ressources suffisantes pour traiter cette charge. Et comme les attaques par déni de service sur l'infrastructure DNS de Dyn l'an dernier l’ont démontré, lorsque le DNS tombe en panne, tout tombe en panne. (C'est quelque chose que quiconque construit des systèmes s'appuyant sur le DNS sait déjà très bien.)
Les problèmes soudains de DNS ont déclenché une réponse de nos équipes d'exploitation et d'ingénierie de la fiabilité pour identifier le problème. Ils ont collaboré avec nos partenaires chez Amazon pour escalader du côté des opérations AWS. En travaillant ensemble, nous avons identifié la cause et une solution. Nous avons déployé un cluster de serveurs de noms de plus grande capacité avec un plus grand accent sur la capacité réseau pouvant répondre à nos besoins DNS sans dépasser les lignes rouges pour le débit. Heureusement, comme tout cela était dans AWS, nous avons pu lancer les nouvelles instances et même redimensionner les instances existantes très rapidement. Le DNS a repris un comportement normal, les échecs de consultation ont cessé, et nous (et 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 de rencontres avec des seuils similaires, inattendus. Nous travaillons également avec l'équipe d'Amazon pour déterminer des modèles de surveillance appropriés qui nous donneront un avertissement adéquat pour prévenir un incident similaire avant qu'il n'affecte un de nos clients.
Sujet | Charge de travail typique AWS | Charge de travail des e-mails sortants de SparkPost |
|---|---|---|
Modèle de trafic | Surtout des demandes de « pull » entrants (pages web, API, médias) | Fort trafic de « push » sortant (milliards d'e-mails) |
Dépendance au DNS | Légère : 1 à 2 consultations par demande de contenu | Très forte : plusieurs consultations DNS par e-mail + vérifications TXT SPF/DKIM |
Volume de requêtes | Prévisible et proportionnel à l'activité des utilisateurs | Explose avec des campagnes sortantes ciblant des millions de domaines |
Type de goulot d'étranglement | Limites du CPU, de la mémoire ou du stockage | Limites de débit réseau agrégé sur les types d'instances |
Mode de défaillance | Latence dégradée ou délai d'expiration de l’API | Échecs de consultation DNS causant des retards de livraison |
Visibilité | Limites généralement documentées et apparentes dans les métriques | Le plafond de débit n'était pas documenté et invisible dans CloudWatch |
Approche d'atténuation | Dimensionner les ressources des instances ou ajouter une mise en cache | Migrer vers des familles d'instances à plus haut débit + refonte de l'architecture DNS |
AWS et la lueur d'espoir 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'utilisation avec l'infrastructure AWS, puis à trouver une solution très rapidement, a beaucoup à voir avec 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 tous les jours. Les atouts de l'infrastructure d'AWS nous ont vraiment donné un 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 aussi beaucoup appris sur la mise en place de l'infrastructure AWS et l'exécution rapide, et nous bénéficions également 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 cela 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 basé notre activité sur le cloud et AWS. Ensemble, le type d'expertise en cloud que partagent nos entreprises 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'email qui a été conçu pour le cloud dès le départ. Cette approche native du cloud est fondamentale à la façon dont nous concevons nos API email pour l'infrastructure cloud, garantissant évolutivité et fiabilité pour les développeurs. Nous envoyons plus d'emails depuis 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 apparaissent à grande échelle tant que vous ne les avez pas rencontrés. 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 de la façon dont nous l'avons résolu, a été utile.
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'utilisation avec l'infrastructure AWS, puis à trouver une solution très rapidement, a beaucoup à voir avec 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 tous les jours. Les atouts de l'infrastructure d'AWS nous ont vraiment donné un 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 aussi beaucoup appris sur la mise en place de l'infrastructure AWS et l'exécution rapide, et nous bénéficions également 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 cela 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 basé notre activité sur le cloud et AWS. Ensemble, le type d'expertise en cloud que partagent nos entreprises 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'email qui a été conçu pour le cloud dès le départ. Cette approche native du cloud est fondamentale à la façon dont nous concevons nos API email pour l'infrastructure cloud, garantissant évolutivité et fiabilité pour les développeurs. Nous envoyons plus d'emails depuis 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 apparaissent à grande échelle tant que vous ne les avez pas rencontrés. 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 de la façon dont nous l'avons résolu, a été utile.
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'utilisation avec l'infrastructure AWS, puis à trouver une solution très rapidement, a beaucoup à voir avec 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 tous les jours. Les atouts de l'infrastructure d'AWS nous ont vraiment donné un 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 aussi beaucoup appris sur la mise en place de l'infrastructure AWS et l'exécution rapide, et nous bénéficions également 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 cela 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 basé notre activité sur le cloud et AWS. Ensemble, le type d'expertise en cloud que partagent nos entreprises 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'email qui a été conçu pour le cloud dès le départ. Cette approche native du cloud est fondamentale à la façon dont nous concevons nos API email pour l'infrastructure cloud, garantissant évolutivité et fiabilité pour les développeurs. Nous envoyons plus d'emails depuis 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 apparaissent à grande échelle tant que vous ne les avez pas rencontrés. 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 de la façon dont nous l'avons résolu, a été utile.
