我们如何追踪到 AWS 中不寻常的 DNS 故障
我们围绕一个理念构建了 SparkPost：像我们这样的云服务需要本身也是云原生的。这不仅仅是一种姿态。支撑 SparkPost 服务的可扩展性、弹性和可靠性的，是我们的云架构。这些特性是我们将基础设施建立在 亚马逊网络服务 (AWS) 之上的主要原因——这也是我们能够为客户提供行业内无人能及的服务水平和突发速率保证的原因。
但是我们并不假装我们从未受到意外错误或可用技术限制的挑战。上周五我们遇到了这样的情况，那次事件导致我们的服务和部分客户的交付延迟出现间歇性缓慢。
首先让我说，这个问题在同一天就解决了。此外，没有任何电子邮件或相关数据丢失。然而，如果因为这个问题导致您的电子邮件交付速度慢，请接受我的歉意（其实，是我们整个团队的歉意）。我们知道您依赖我们，当我们没有达到您期望的水平时，这非常令人沮丧。
一些公司可能会试图将服务降级等问题掩盖起来，希望没人注意到。您可能在过去使用的服务中经历过这种情况。我知道我经历过。但这不是我们做生意的方式。
我还想就这个事件写另一个原因：我们对 AWS 云架构学到了一些非常有趣和有价值的东西。其他构建云服务的团队也可能对此有所兴趣。
摘要
我们遇到了我们用于主要 DNS 集群的 EC2 实例的未记录实用限制。基于传统规格（处理器、内存等）来调整云实例通常会如您所预期的那样工作，但有时传统的硬件模型并不适用。这在非常规使用案例中尤其如此，聚合限制可能会起作用——而且有时您在没有警告的情况下就会遭遇这些情况。
上周五，当我们的 DNS 查询量创建了一种我们的实例类型未准备好的网络使用模式时，我们遇到了这样的限制。然而，由于这个限制在文档或标准可用指标中并不明显，我们并不知道我们遇到了它。我们观察到的 DNS 故障率非常高，进而导致我们架构中不同点的间歇性延迟。
深入探讨 DNS
为什么我们的 DNS 使用是特别的？好吧，这与电子邮件的工作方式有很大关系，与 AWS 最初设计的内容模型相比。基于网络的内容交付大量使用被认为是经典的外部“拉取”场景：客户端请求数据，无论是 HTML、视频流还是其他任何内容，来自云端。但是，对于像 SparkPost 这样的消息服务提供商的用例而言，则是对通常的 AWS 场景的例外。在我们这儿，我们进行大量的外部流量推送：具体来说，电子邮件（以及其他消息类型，如 SMS 或移动推送通知）。而这种推送型流量在很大程度上依赖于 DNS。
如果您熟悉 DNS，您可能知道，它通常是相当轻量的数据。请求特定的 HTML 页面时，您首先必须询问该页面在互联网上的位置信息，但该请求的大小仅占您检索到的内容的一小部分。
然而，电子邮件在查找交付域时异常依赖 DNS——例如，SparkPost 每个月向超过 100 万个独特域发送数十亿封电子邮件 。对于每封我们发送的电子邮件，我们必须至少进行两次 DNS 查询，并且为了反钓鱼技术（如 SPF 和 DKIM）使用 DNS “txt” 记录也意味着 DNS 必须被用于接收邮件。再加上我们对 AWS API 服务的更传统使用，很难夸大 DNS 对我们基础设施的重要性。
所有这些意味着，我们遇到了一个不寻常的情况，我们日益增长的外部消息量产生了一个 DNS 流量量，达到了一种实例类型的聚合网络吞吐量限制，而那些实例类型本身似乎有足够的资源来处理这种负载。正如 去年的 Dyn DNS 基础设施遭遇的拒绝服务攻击 所证明的那样，当 DNS 崩溃时，一切都崩溃了。（这对任何构建依赖于 DNS 的系统的人来说，都已经是一个非常痛苦的事实。）
突发的 DNS 问题触发了我们的运营和可靠性工程团队的响应，以确定问题所在。他们与亚马逊的合作伙伴合作，推动 AWS 运营方面的升级。通过合作，我们找到了原因和解决方案。我们部署了一组容量更大的名称服务器，更加专注于网络容量，以满足我们的 DNS 需求，而不会触及吞吐量的红线。幸运的是，由于所有这些都在 AWS 内部，我们可以非常迅速地启动新的实例，甚至调整现有实例的大小。DNS 恢复了正常行为，查询故障停止了，我们（以及外部消息交付）又回到了正轨。
为了在未来减轻针对这一特定问题的影响，我们还对 DNS 架构进行更改，以更好地隔离我们的核心组件，避免类似意外阈值带来的影响。我们还在与亚马逊团队合作，确定适当的监控模型，以便在事件影响到我们的客户之前，给予我们充分的警告。
AWS 与云的积极一面
我不想掩盖这一事件对我们客户的影响。但我们能够确定根本问题是我们用例与 AWS 基础设施之间的意外交互——然后在非常短的时间内找到解决方案——在很大程度上与我们如何构建 SparkPost 以及我们与亚马逊团队的良好关系有关。
SparkPost 杰出的运营团队，我们的站点可靠性工程 (SRE) 团队，以及我们主要的技术架构师每天都与亚马逊一起工作。AWS 基础设施的优势使我们在 优化 SparkPost 的云架构方面获得了真正的优势。在过去两年与 AWS 密切合作的过程中，我们也学到了很多关于快速启动 AWS 基础设施和快速运行的知识，同时还得到了 AWS 团队的深度支持。
如果我们不得不在传统数据中心模型中处理类似的限制，这样的事情可能需要几天甚至几周才能完全解决。这种灵活性和响应能力只是我们将业务建立在云和 AWS 上的两个原因。我们两家公司共享的云专业知识是难得的。亚马逊一直是我们很好的商业伙伴，我们为与 AWS 堆栈的合作感到自豪。
SparkPost 是从一开始就为云构建的第一个电子邮件送达服务。我们从一个真正的云平台上发送的电子邮件数量超过任何人，有时这意味着进入未知的领域。这是计算机科学的一个基本事实，您不知道在规模上会面临什么挑战，直到您遭遇它们。我们在 AWS 上找到了一个，但我们的快速响应是云所带来的灵活性的一个很好的例证。这也是我们对客户的承诺。
无论您是在 AWS 上构建自己的基础设施，还是 SparkPost 的客户，利用我们的服务，我希望这篇关于上周五发生的事情以及我们如何解决它的解释对您有所帮助。