我们遇到了我们用于主要DNS集群的EC2实例的未文档化的实际限制。根据传统规格（处理器、内存等）对云实例进行大小调整通常会像您预期的那样工作，但有时这种传统硬件模型并不适用。
我们如何追踪到 AWS 中不寻常的 DNS 故障
我们围绕着这样的想法构建了SparkPost：像我们这样的云服务需要自身是云原生的。这不仅仅是姿态。正是我们的云架构支持了SparkPost服务的可扩展性、弹性和可靠性。这些品质是我们在Amazon Web Services (AWS)之上构建我们的基础设施的主要原因——这也是我们能够为客户提供任何其他企业无法比拟的服务水平和突发速率保证的原因。
但我们不假装不会受到意外错误或可用技术限制的挑战。上周五，我们遇到了类似情况，这起事件导致我们的服务出现间歇性缓慢，以及一些客户的交付延迟。
首先让我说，这个问题在同一天就得到了解决。此外，没有邮件或相关数据丢失。但是，如果由于这个问题邮件的交付变慢，请接受我的歉意（事实上，是我们整个团队的歉意）。这次事件强化了我们需要有全面的备份策略，不论是使用PostgreSQL数据库备份还是其他数据保护方法，以确保在基础设施挑战期间能够持续业务。我们知道你依赖我们，而当我们没有达到你期望的水平时，这会令人沮丧。
一些公司会试图将类似服务降级的问题掩盖并希望没有人注意到。你可能在过去使用过的服务中经历过这种情况。我知道我也有过。但这不是我们做生意的方式。
我还想写这次事件是因为另一个原因：我们对我们的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是第一个从一开始就为云构建的电子邮件传递服务。这种云原生方法是我们为云基础设施设计电子邮件API的基础，确保开发人员的可扩展性和可靠性。我们从真正的云平台发送的电子邮件比任何人都多，而有时候这意味着要进入未知领域。计算机科学的一个基本事实是，直到规模化后，您才知道会遇到什么挑战。我们在AWS上发现了一个，但我们的快速响应很好地证明了云所带来的灵活性。这也是我们对客户的承诺。
无论您是在AWS上构建自己的基础设施，还是作为SparkPost的客户利用我们的基础设施，我希望上周五发生的事情及其解决方式的说明对您有所帮助。
