我们在AWS中遇到DNS未记录限制的那一天

鸟

2017年2月7日

工程

1 min read

我们在AWS中遇到DNS未记录限制的那一天

关键要点

    • SparkPost 在某个 AWS EC2 实例类型上遇到了未记录的网络吞吐量限制，该实例类型为其主要 DNS 集群供电。

    • 传统的实例大小（CPU、RAM、磁盘）并未揭示这个瓶颈，因为问题与聚合 DNS 网络流量有关，而不是资源匮乏。

    • 高容量外发邮件的 DNS 使用量异常庞大：SparkPost 为了域路由、身份验证 (SPF/DKIM) 和 AWS API 交互生成了数百万次 DNS 查找。

    • DNS 故障并非由格式错误的 DNS 响应引起，而是实例级别的网络容量阈值被悄然超出，导致广泛的查找失败。

    • 由于 AWS 没有明确记录这些软网络限制，诊断问题需要 SparkPost 的 SRE 团队与 AWS 工程师之间的深度合作。

    • 团队通过将 DNS 服务迁移到具有更大网络带宽的更大型实例类型，并重新设计部分 DNS 架构以获得更好的隔离和故障切换，解决了这一问题。

    • 没有客户数据或消息丢失，但事件突显出云原生架构在规模上可能遇到意想不到的限制——以及如何利用 AWS 弹性快速{

Q&A 精华

  • 发生了什么？

    SparkPost的DNS集群遇到了意外的AWS网络吞吐量上限，导致DNS查询间歇性失败，从而延迟了电子邮件的发送。

  • 为什么 DNS 完全崩溃了？

    DNS 对于发送电子邮件是极其依赖的。每次发送都需要多个查找（MX、TXT、SPF、DKIM），因此高发送量 = 大量的 DNS 流量。

    这种流量模式超过了托管域名服务器的 EC2 实例类型的未公开限制。

  • 电子邮件的DNS与Web应用程序有何不同？

    • Web apps 主要 拉取 内容（客户端请求数据）。

    • Email delivery services 推送 流量，触发更多的 DNS 查找——通常每月数十亿次。
      Email 依赖 DNS 进行路由、安全验证和故障转移。

  • 故障是如何表现的？

    • DNS 请求开始下降或超时

    • 传递队列积压

    • 系统部分的延迟增加
      没有丢失任何东西——只是延迟。

  • 为什么这很难诊断？

    • 限制没有被记录

    • AWS 监控没有明确显示瓶颈

    • 所有传统指标（CPU、RAM、磁盘）看起来都正常
      这个问题只在特定的高流量 DNS 流量模式下才浮现。

  • SparkPost 是如何解决这个问题的？

    • 升级到具有更高网络吞吐量上限的EC2实例类型

    • 重新构建DNS集群，以更好地抵抗总流量激增

    • 与AWS合作，以便更早地识别更好的信号/警报模式

  • 客户数据或邮件丢失了吗？

    不——只是传递速度放慢。 一旦DNS稳定，所有邮件恢复正常传递。

  • 更广泛的教训是什么？

    即使在云中，你也可能遇到看不见的扩展限制 — 但云原生设计为您提供快速恢复的灵活性。

    弹性、与AWS的合作以及强大的SRE实践使快速恢复成为可能。

我们遇到了我们用于主要DNS集群的EC2实例的未文档化的实际限制。根据传统规格（处理器、内存等）对云实例进行大小调整通常会像您预期的那样工作，但有时这种传统硬件模型并不适用。

我们如何追踪到 AWS 中不寻常的 DNS 故障

我们围绕着这样的想法构建了SparkPost：像我们这样的云服务需要自身是云原生的。这不仅仅是姿态。正是我们的云架构支持了SparkPost服务的可扩展性、弹性和可靠性。这些品质是我们在Amazon Web Services (AWS)之上构建我们的基础设施的主要原因——这也是我们能够为客户提供任何其他企业无法比拟的服务水平和突发速率保证的原因。

但我们不假装不会受到意外错误或可用技术限制的挑战。上周五，我们遇到了类似情况，这起事件导致我们的服务出现间歇性缓慢，以及一些客户的交付延迟。

首先让我说，这个问题在同一天就得到了解决。此外，没有邮件或相关数据丢失。但是，如果由于这个问题邮件的交付变慢，请接受我的歉意（事实上，是我们整个团队的歉意）。这次事件强化了我们需要有全面的备份策略，不论是使用PostgreSQL数据库备份还是其他数据保护方法，以确保在基础设施挑战期间能够持续业务。我们知道你依赖我们，而当我们没有达到你期望的水平时，这会令人沮丧。

一些公司会试图将类似服务降级的问题掩盖并希望没有人注意到。你可能在过去使用过的服务中经历过这种情况。我知道我也有过。但这不是我们做生意的方式。

我还想写这次事件是因为另一个原因：我们对我们的AWS云架构学到了非常有趣和有价值的东西。其他构建云服务的团队可能会感兴趣了解这点。

我们围绕着这样的想法构建了SparkPost：像我们这样的云服务需要自身是云原生的。这不仅仅是姿态。正是我们的云架构支持了SparkPost服务的可扩展性、弹性和可靠性。这些品质是我们在Amazon Web Services (AWS)之上构建我们的基础设施的主要原因——这也是我们能够为客户提供任何其他企业无法比拟的服务水平和突发速率保证的原因。

但我们不假装不会受到意外错误或可用技术限制的挑战。上周五，我们遇到了类似情况，这起事件导致我们的服务出现间歇性缓慢，以及一些客户的交付延迟。

首先让我说，这个问题在同一天就得到了解决。此外，没有邮件或相关数据丢失。但是，如果由于这个问题邮件的交付变慢，请接受我的歉意（事实上，是我们整个团队的歉意）。这次事件强化了我们需要有全面的备份策略，不论是使用PostgreSQL数据库备份还是其他数据保护方法，以确保在基础设施挑战期间能够持续业务。我们知道你依赖我们，而当我们没有达到你期望的水平时，这会令人沮丧。

一些公司会试图将类似服务降级的问题掩盖并希望没有人注意到。你可能在过去使用过的服务中经历过这种情况。我知道我也有过。但这不是我们做生意的方式。

我还想写这次事件是因为另一个原因：我们对我们的AWS云架构学到了非常有趣和有价值的东西。其他构建云服务的团队可能会感兴趣了解这点。

我们围绕着这样的想法构建了SparkPost：像我们这样的云服务需要自身是云原生的。这不仅仅是姿态。正是我们的云架构支持了SparkPost服务的可扩展性、弹性和可靠性。这些品质是我们在Amazon Web Services (AWS)之上构建我们的基础设施的主要原因——这也是我们能够为客户提供任何其他企业无法比拟的服务水平和突发速率保证的原因。

但我们不假装不会受到意外错误或可用技术限制的挑战。上周五，我们遇到了类似情况，这起事件导致我们的服务出现间歇性缓慢，以及一些客户的交付延迟。

首先让我说，这个问题在同一天就得到了解决。此外，没有邮件或相关数据丢失。但是，如果由于这个问题邮件的交付变慢，请接受我的歉意（事实上，是我们整个团队的歉意）。这次事件强化了我们需要有全面的备份策略，不论是使用PostgreSQL数据库备份还是其他数据保护方法，以确保在基础设施挑战期间能够持续业务。我们知道你依赖我们，而当我们没有达到你期望的水平时，这会令人沮丧。

一些公司会试图将类似服务降级的问题掩盖并希望没有人注意到。你可能在过去使用过的服务中经历过这种情况。我知道我也有过。但这不是我们做生意的方式。

我还想写这次事件是因为另一个原因：我们对我们的AWS云架构学到了非常有趣和有价值的东西。其他构建云服务的团队可能会感兴趣了解这点。

TL;DR

我们遇到了用于我们主要DNS集群的EC2实例的未记录实际限制。基于传统规格（处理器、内存等）对云实例进行大小调整通常会像预期的一样工作，但有时传统硬件模型并不适用。这在总限制可能发挥作用的非典型用例中尤为真实——有时你会在没有预警的情况下直接遇到这些情形。

我们在星期五遇到了这样的限制，当时我们的DNS查询量产生了一种我们的实例类型没有准备好的网络使用模式。然而，由于该限制在文档或可用的标准度量中并不明显，我们并不知晓我们已达到限制。我们观察到的是非常高的DNS失败率，这反过来导致我们架构中不同点的间歇性延迟。

我们遇到了用于我们主要DNS集群的EC2实例的未记录实际限制。基于传统规格（处理器、内存等）对云实例进行大小调整通常会像预期的一样工作，但有时传统硬件模型并不适用。这在总限制可能发挥作用的非典型用例中尤为真实——有时你会在没有预警的情况下直接遇到这些情形。

我们在星期五遇到了这样的限制，当时我们的DNS查询量产生了一种我们的实例类型没有准备好的网络使用模式。然而，由于该限制在文档或可用的标准度量中并不明显，我们并不知晓我们已达到限制。我们观察到的是非常高的DNS失败率，这反过来导致我们架构中不同点的间歇性延迟。

我们遇到了用于我们主要DNS集群的EC2实例的未记录实际限制。基于传统规格（处理器、内存等）对云实例进行大小调整通常会像预期的一样工作，但有时传统硬件模型并不适用。这在总限制可能发挥作用的非典型用例中尤为真实——有时你会在没有预警的情况下直接遇到这些情形。

我们在星期五遇到了这样的限制，当时我们的DNS查询量产生了一种我们的实例类型没有准备好的网络使用模式。然而，由于该限制在文档或可用的标准度量中并不明显，我们并不知晓我们已达到限制。我们观察到的是非常高的DNS失败率，这反过来导致我们架构中不同点的间歇性延迟。

深入了解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 团队合作，以确定合适的监控模型，这将为我们提供足够的警告，以在类似事件影响到任何客户之前将其扼杀在萌芽状态。

为什么我们的 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 团队合作，以确定合适的监控模型，这将为我们提供足够的警告，以在类似事件影响到任何客户之前将其扼杀在萌芽状态。

为什么我们的 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的客户利用我们的基础设施，我希望上周五发生的事情及其解决方式的说明对您有所帮助。

我不想美化此事件对我们客户的影响。但我们能够识别出这是我们的用例与AWS基础设施之间的意外交互引发的潜在问题，并在短时间内找到解决方案，这很大程度上归功于我们如何构建SparkPost，以及我们与亚马逊团队的良好关系。

SparkPost卓越的运营团队、我们的网站可靠性工程（SRE）团队以及我们的首席技术架构师每天都在与亚马逊合作。AWS基础设施的强大赋予了我们在优化SparkPost的云架构方面的真正优势。在过去两年与AWS的密切合作不仅教会了我们如何快速启动并运行AWS基础设施，还使我们受益于AWS团队的深度支持。

如果我们不得不在传统数据中心模式下绕过类似限制，解决这样的问题可能需要数天甚至数周的时间。这种敏捷性和响应能力只是我们将业务建立在云和AWS上的众多原因之一。我们的公司在云技术方面的共享专长难以复制。亚马逊一直是我们很好的业务伙伴，我们对与AWS技术堆栈共同完成的工作感到非常自豪。

SparkPost是第一个从一开始就为云构建的电子邮件传递服务。这种云原生方法是我们为云基础设施设计电子邮件API的基础，确保开发人员的可扩展性和可靠性。我们从真正的云平台发送的电子邮件比任何人都多，而有时候这意味着要进入未知领域。计算机科学的一个基本事实是，直到规模化后，您才知道会遇到什么挑战。我们在AWS上发现了一个，但我们的快速响应很好地证明了云所带来的灵活性。这也是我们对客户的承诺。

无论您是在AWS上构建自己的基础设施，还是作为SparkPost的客户利用我们的基础设施，我希望上周五发生的事情及其解决方式的说明对您有所帮助。

我不想美化此事件对我们客户的影响。但我们能够识别出这是我们的用例与AWS基础设施之间的意外交互引发的潜在问题，并在短时间内找到解决方案，这很大程度上归功于我们如何构建SparkPost，以及我们与亚马逊团队的良好关系。

SparkPost卓越的运营团队、我们的网站可靠性工程（SRE）团队以及我们的首席技术架构师每天都在与亚马逊合作。AWS基础设施的强大赋予了我们在优化SparkPost的云架构方面的真正优势。在过去两年与AWS的密切合作不仅教会了我们如何快速启动并运行AWS基础设施，还使我们受益于AWS团队的深度支持。

如果我们不得不在传统数据中心模式下绕过类似限制，解决这样的问题可能需要数天甚至数周的时间。这种敏捷性和响应能力只是我们将业务建立在云和AWS上的众多原因之一。我们的公司在云技术方面的共享专长难以复制。亚马逊一直是我们很好的业务伙伴，我们对与AWS技术堆栈共同完成的工作感到非常自豪。

SparkPost是第一个从一开始就为云构建的电子邮件传递服务。这种云原生方法是我们为云基础设施设计电子邮件API的基础，确保开发人员的可扩展性和可靠性。我们从真正的云平台发送的电子邮件比任何人都多，而有时候这意味着要进入未知领域。计算机科学的一个基本事实是，直到规模化后，您才知道会遇到什么挑战。我们在AWS上发现了一个，但我们的快速响应很好地证明了云所带来的灵活性。这也是我们对客户的承诺。

无论您是在AWS上构建自己的基础设施，还是作为SparkPost的客户利用我们的基础设施，我希望上周五发生的事情及其解决方式的说明对您有所帮助。

其他新闻

阅读更多来自此类别的内容

A person is standing at a desk while typing on a laptop.

完整的AI原生平台，可与您的业务一起扩展。

联系销售

免费开始

© 2025 Bird

联系 Support

A person is standing at a desk while typing on a laptop.

完整的AI原生平台，可与您的业务一起扩展。

联系销售

免费开始

© 2025 Bird

联系 Support

A person is standing at a desk while typing on a laptop.

完整的AI原生平台，可与您的业务一起扩展。

联系销售

免费开始

© 2025 Bird

联系 Support