How We Tracked Down Unusual DNS Failures in AWS

We’ve built SparkPost around the idea that a cloud service like ours needs to be cloud-native itself. That’s not just posturing. It’s our cloud architecture that underpins the scalability, elasticity, and reliability that are core aspects of the SparkPost service. Those qualities are major reasons we’ve built our infrastructure atop 亚马逊网络服务（AWS）—and it’s why we can offer our customers service level and burst rate guarantees unmatched by anyone else in the business.

But we don’t pretend that we’re never challenged by unexpected bugs or limits of available technology. We ran into something like this last Friday, and 该事件 led to intermittent slowness in our service and delivery delays for some of our customers.

首先让我说，这个问题在当天就得到了解决。此外，没有任何电子邮件或相关数据丢失。然而，如果因为这个问题，你的电子邮件的交付速度减慢了，请接受我的道歉（事实上，是我们整个团队的道歉）。我们知道你依赖我们，当我们的表现没有达到你所期望的水平时，这是很令人沮丧的。

Some companies are tempted to brush issues like a service degradation under the rug and hope no one notices. You may have experienced that with services you’ve used in the past. I know I have. But that’s not how we like to do business.

我想写这个事件还有一个原因：我们在AWS的云架构上学到了一些非常有趣和有价值的东西。构建其他云服务的团队可能有兴趣了解一下。

TL;DR

我们遇到了我们用于主要DNS集群的EC2实例的未记录的实际限制。根据传统的规格（处理器、内存等）确定云实例的大小，通常和你所期望的一样，但有时传统的硬件模型并不适用。这在非典型的使用案例中尤其如此，在这些案例中，总量限制可能会发挥作用--有时你会在没有警告的情况下一头撞上这些场景。

我们在周五遇到了这样的限制，当时我们的DNS查询量创造了一种网络使用模式，而我们的实例类型并没有准备好。然而，由于该限制在文档或标准指标中并不明显，我们不知道我们已经达到了它。我们观察到的是一个非常高的DNS故障率，这反过来又导致了我们架构中不同点的间歇性延迟。

深入挖掘DNS

为什么我们的DNS使用很特别？嗯，这与电子邮件的工作方式有很大关系，与AWS最初设计的内容模式相比。基于网络的内容交付大量使用可能被认为是经典的入站 "拉动 "场景：客户端请求数据，无论是HTML，视频流，还是其他任何东西，从云端。但是像SparkPost这样的消息服务提供商的使用情况是AWS通常情况的例外。在我们的案例中，我们做了很多向外推送的流量：特别是电子邮件（和其他消息类型，如短信或移动推送通知）。而这种推送式的流量在很大程度上依赖于DNS。

如果你熟悉DNS，你可能知道，它通常是相当轻量级的数据。要请求一个给定的HTML页面，你首先要问在互联网上哪里可以找到这个页面，但这个请求只是你检索的内容的一小部分。

Email, however, makes exceptionally heavy use of DNS to look up delivery domains—for example, SparkPost sends many billions of emails to over 1 million unique domains 每个月. For every email we deliver, we have to make a minimum of two DNS lookups, and the use of DNS “txt” records for anti-phishing technologies like SPF and DKIM means DNS also is required to receive mail. Add to that our more traditional use of AWS API services for our apps, and it’s hard to exaggerate how important DNS is to our infrastructure.

All of this means we ran into an unusual condition in which our growing volume of outbound messages created a DNS traffic volume that hit an aggregate network throughput limit on instance types that otherwise seemed to have sufficient resources to service that load. And as 对Dyn DNS基础设施的拒绝服务攻击 last year demonstrated, when DNS breaks, everything breaks. (That’s something anyone who builds systems that rely on DNS already knows painfully well.)

突如其来的DNS问题引发了我们的运营和可靠性工程团队的反应，以确定问题。他们与我们在亚马逊的合作伙伴合作，在AWS运营方面进行了升级。通过合作，我们确定了原因和解决方案。我们部署了一个容量更大的名称服务器集群，更加注重网络容量，可以满足我们的DNS需求，而不会遇到吞吐量的红线。幸运的是，由于所有这些都是在AWS内部进行的，我们可以快速启动新的实例，甚至调整现有实例的大小。DNS恢复了正常的行为，查询失败停止了，我们（和外向信息传递）回到了正轨。

为了在未来缓解这一具体问题，我们也在进行DNS架构的改变，以更好地隔离我们的核心组件，使其不受遇到类似的、意外的阈值的影响。我们还在与亚马逊团队合作，以确定适当的监测模式，这将给我们足够的警告，在类似事件影响到我们的任何客户之前，将其消灭。

AWS and the Cloud’s Silver Lining

我不想掩饰这一事件对我们客户的影响。但是，我们能够识别出潜在的问题，即我们的用例与AWS基础设施的意外互动，然后在很短的时间内找到解决方案，这与我们如何建立SparkPost以及我们与亚马逊团队的良好关系有很大关系。

SparkPost’s superb operations corps, our Site Reliability Engineering (SRE) team, and our principal technical architects work with Amazon every day. ǞǞǞ strengths of AWS’ infrastructure has given us a real leg up 优化SparkPost的云计算架构. Working so closely with AWS over the past two years also has taught us a lot about spinning up AWS infrastructure and running quickly, and we also have the benefit of deep support from the AWS team.

如果我们不得不在传统的数据中心模式下解决类似的限制，这样的事情可能需要几天甚至几周才能完全解决。这种敏捷性和响应性只是我们将我们的业务建立在云和AWS上的两个原因。我们公司共同拥有的云计算专业知识是很难得的。亚马逊一直是我们的一个伟大的商业伙伴，我们对我们在AWS堆栈中所做的事情感到非常自豪。

SparkPost是第一个从一开始就为云计算而建立的电子邮件发送服务。我们比任何人都更多地从一个真正的云平台上发送电子邮件，有时这意味着进入未知的领域。这是计算机科学的一个基本真理，在你遇到挑战之前，你不知道在规模上会出现什么挑战。我们在AWS上发现了一个问题，但我们的快速反应是一个很好的例子，说明云的灵活性使之成为可能。这也是我们对客户的承诺。

无论你是在AWS上建立自己的基础设施，还是利用我们的优势的SparkPost客户，我希望这个关于上周五发生的事情的解释，以及我们如何解决它，都是有用的。