我们遇到了我们用于主要DNS集群的EC2实例的未文档化的实际限制。根据传统规格（处理器、内存等）对云实例进行大小调整通常会像您预期的那样工作，但有时这种传统硬件模型并不适用。
Business in a box.
探索我们的解决方案。
与我们的销售团队交谈
我们如何追踪到 AWS 中不寻常的 DNS 故障
我们围绕这样的理念构建了SparkPost：像我们这样的云服务需要本身就是云原生的。这不仅仅是姿态。正是我们的云架构支持着SparkPost服务的可扩展性、弹性和可靠性。这些品质是我们将基础架构构建在Amazon Web Services (AWS)之上的主要原因——这也是为什么我们能够为客户提供无人能及的服务水平和突发率保证的原因。
但我们并不假装我们从未受到意外错误或可用技术限制的挑战。上周五，我们遇到了类似的问题，该事件导致我们的服务出现间歇性缓慢，并为一些客户带来了延迟。
首先，我要说的是，当天问题就已解决。而且，没有邮件或相关数据丢失。然而，如果此次问题导致您的邮件发送速度减缓，请接受我的歉意（实际上，是我们整个团队的歉意）。我们知道您依赖我们，当我们没有达到您期望的水平时，这非常令人沮丧。
一些公司倾向于将服务降级等问题抛诸脑后，希望没有人注意到。您可能在过去使用的服务中体验过这种情况。我知道我有过。但那不是我们喜欢做生意的方式。
我想写这篇关于该事件的文章还有另一个原因：我们从AWS云架构中学到了非常有趣且有价值的东西。其他正在构建云服务的团队可能会对此感兴趣。
TL;DR
深入了解DNS
为什么我们的 DNS 使用如此特别？这是因为邮箱的工作方式与 AWS 原本设计的内容模式有很大不同。基于网络的内容交付大量采用了经典的“拉取”场景：客户端从云端请求数据，无论是 HTML、视频流还是其他内容。但是像 SparkPost 这样的消息服务提供商的使用案例是 AWS 典型场景的例外。在我们的情况下，我们做了大量的对外推送流量：特别是电子邮件（以及其他消息类型，如 SMS 或移动推送通知）。而这种推送流量非常依赖于 DNS。
如果你熟悉 DNS，你可能知道它通常是相当轻量级的数据。要请求一个特定的 HTML 页面，你首先需要询问该页面可以在互联网的哪个地方找到，但该请求的大小只是你获取的内容的一小部分。
然而，电子邮件对 DNS 的使用尤其频繁，以查找投递域名——例如，SparkPost 每月发送数十亿封邮件到超过 100 万个独特的域名。对于我们发送的每封电子邮件，我们必须至少进行两次 DNS 查找，并且使用 DNS “txt” 记录来进行诸如 SPF 和 DKIM 的反钓鱼技术意味着接收邮件也需要 DNS。此外，还有我们更传统的 AWS API 服务在我们应用中的使用，可以说 DNS 对我们基础架构的重要性是不可夸大的。
这一切意味着我们遇到了一种不寻常的情况：我们不断增长的外发消息量导致 DNS 流量触及了在实例类型上的汇总网络吞吐限制，而这些实例类型似乎有足够的资源来处理这种负载。去年对 Dyn DNS 基础设施的拒绝服务攻击表明，当 DNS 出现故障时，一切都会崩溃。（这是任何构建依赖于 DNS 的系统的人都非常清楚的痛苦经验。）
突如其来的 DNS 问题促使我们的运营和可靠性工程团队做出响应以确定问题。他们与我们在 Amazon 的合作伙伴配合，在 AWS 的运营端进行升级。通过共同努力，我们找出了原因并找到了一个解决方案。我们部署了一个具有更大网络容量的新服务器集群，能够满足我们的 DNS 需求而不会触及吞吐量的红线。幸运的是，由于一切都在 AWS 内，我们能非常快速地启动新的实例，甚至调整现有实例的大小。DNS 恢复了正常行为，查找失败消失了，我们（以及外发消息投递）回到了正轨。
为防止今后出现类似问题，我们还在更改 DNS 架构，以更好地将我们的核心组件与类似、意外的阈值影响隔离开来。我们还在与 Amazon 团队合作，以确定合适的监控模型，这将为我们提供足够的警告，以在类似事件影响到任何客户之前将其扼杀在萌芽状态。
AWS 和 Cloud 的 Silver Lining
我不想对这次事件对我们的客户的影响加以粉饰。但我们能够将根本问题识别为我们用例与AWS基础设施的意外互动，然后迅速找到解决方案，这在很大程度上归功于我们如何构建SparkPost，以及我们与亚马逊团队的良好关系。
SparkPost出色的运营团队、我们的网站可靠性工程（SRE）团队以及我们的首席技术架构师每天都与亚马逊合作。AWS基础设施的优势使我们在优化SparkPost的云架构方面具有真正的优势。在过去两年中，与AWS的紧密合作也让我们学到了很多关于快速启动AWS基础设施和运行的知识，并且我们还受益于来自AWS团队的深度支持。
如果我们不得不在传统的数据中心模型中应对类似的限制，这样的问题可能需要数天甚至数周才能完全解决。这种敏捷性和响应能力是我们将业务根植于云端和AWS的原因之一。我们公司共享的这种云专业知识是难得的。亚马逊是我们的伟大业务合作伙伴，我们为与AWS平台所取得的成就感到自豪。
SparkPost是首个从一开始就为云构建的电子邮件发送服务。我们从真正的云平台发送更多邮件，有时候这意味着进入未知领域。计算机科学的一个基本事实是，只有在规模上遇到挑战时你才会意识到。我们在AWS上遇到了一个问题，但我们的快速响应是云灵活性可能性的绝佳例子。这也是我们对客户的承诺。
无论你是在AWS上构建自己的基础设施，还是作为利用我们设施的SparkPost客户，我希望这次关于上周五发生的事件及其解决方式的解释对你有所帮助。
