我们在AWS中遇到DNS未记录限制的那一天
鸟
2017年2月7日
工程
1 min read
关键要点
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实践使快速恢复成为可能。
我们如何在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最初设计的内容模型。基于Web的内容交付大量使用经典的入邦“拉”场景：客户端请求数据，无论是HTML，视频流，还是其他内容，从云端获取。但是像SparkPost这样的消息服务提供商的用例是对常规AWS场景的例外。在我们的案例中，我们做了大量的出站流量推动：特别是电子邮件（以及其他消息类型，如SMS或移动推送通知）。而这种推式流量非常依赖于DNS。
如果你熟悉DNS，你可能知道它通常是相当轻量级的数据。要请求给定的HTML页面，你首先必须询问该页面在互联网上可以找到的位置，但该请求只是你检索到的内容大小的一小部分。
然而，电子邮件则对DNS有着特别密集的使用，用于查找发送域——例如，SparkPost每个月向超过100万个独特域名发送数十亿封电子邮件。对于我们发送的每封电子邮件，我们必须至少进行两次DNS查询字典，并且对于反钓鱼技术如SPF和DKIM，DNS也是接收邮件所必需的。加上我们对AWS API服务的更多传统使用，它很难夸大DNS对我们基础设施的重要性。
这一切意味着我们遇到了一种不寻常的情况，即我们增长的出站消息量产生了DNS流量，其在实例类型上达到了聚合网络吞吐量限制，否则这些实例类型似乎有足够的资源来承载这种负载。正如去年对Dyn DNS基础设施的拒绝服务攻击所显示的那样，当DNS崩溃时，一切都会崩溃。（这也是任何构建依赖于DNS的系统的人都了解的痛苦问题。）
突如其来的DNS问题触发了我们的运营和可靠性工程团队的响应，以识别问题。我们与亚马逊的合作伙伴团队合作，以提升AWS运营方面的紧急程度。在合作中，我们找到了原因和解决方案。我们部署了具有更大网络容量的集群中的大容量名称服务器，能够满足我们的DNS需求，而不会达到吞吐量的红线。幸运的是，由于这一切都是在AWS内部进行的，我们可以迅速增加新的实例，甚至重新调整现有实例的大小。DNS恢复了正常行为，查询失败停止，我们（以及出站消息交付）回到了正轨。
为了缓解未来这一特定问题，我们还在对DNS体系结构进行更改，以更好地将我们核心组件从相似、意外的门槛影响中隔离开来。我们还与亚马逊团队合作，确定适当的监控模型，为我们在类似事件影响到任何客户之前提供足够的警告。
题目 | 典型AWS工作负载 | SparkPost的出站电子邮件工作负载 |
|---|---|---|
流量模式 | 大多是入邦“拉”请求（网页、API、媒体） | 重度出邦“推”流量（数十亿封电子邮件） |
DNS依赖 | 轻度：每个内容请求1-2次查询 | 非常沉重：每封邮件多次DNS查询 + SPF/DKIM TXT检查 |
查询量 | 可预测并与用户活动成比例 | 随目标数百万域的出站活动激增 |
瓶颈类型 | CPU、内存或存储限制 | 实例类型的聚合网络吞吐量限制 |
失败模式 | 延迟降低或API超时 | DNS查找失败导致交付延迟 |
可见性 | 限制通常记录并显示在指标中 | 吞吐量上限未记录并在CloudWatch中不可见 |
缓解方法 | 扩大实例资源或增加缓存 | 迁移到带宽更高的实例系列 + DNS架构重新设计 |
为什么我们的DNS使用特别？这与电子邮件的工作方式有很大关系，相对于AWS最初设计的内容模型。基于Web的内容交付大量使用经典的入邦“拉”场景：客户端请求数据，无论是HTML，视频流，还是其他内容，从云端获取。但是像SparkPost这样的消息服务提供商的用例是对常规AWS场景的例外。在我们的案例中，我们做了大量的出站流量推动：特别是电子邮件（以及其他消息类型，如SMS或移动推送通知）。而这种推式流量非常依赖于DNS。
如果你熟悉DNS，你可能知道它通常是相当轻量级的数据。要请求给定的HTML页面，你首先必须询问该页面在互联网上可以找到的位置，但该请求只是你检索到的内容大小的一小部分。
然而，电子邮件则对DNS有着特别密集的使用，用于查找发送域——例如，SparkPost每个月向超过100万个独特域名发送数十亿封电子邮件。对于我们发送的每封电子邮件，我们必须至少进行两次DNS查询字典，并且对于反钓鱼技术如SPF和DKIM，DNS也是接收邮件所必需的。加上我们对AWS API服务的更多传统使用，它很难夸大DNS对我们基础设施的重要性。
这一切意味着我们遇到了一种不寻常的情况，即我们增长的出站消息量产生了DNS流量，其在实例类型上达到了聚合网络吞吐量限制，否则这些实例类型似乎有足够的资源来承载这种负载。正如去年对Dyn DNS基础设施的拒绝服务攻击所显示的那样，当DNS崩溃时，一切都会崩溃。（这也是任何构建依赖于DNS的系统的人都了解的痛苦问题。）
突如其来的DNS问题触发了我们的运营和可靠性工程团队的响应，以识别问题。我们与亚马逊的合作伙伴团队合作，以提升AWS运营方面的紧急程度。在合作中，我们找到了原因和解决方案。我们部署了具有更大网络容量的集群中的大容量名称服务器，能够满足我们的DNS需求，而不会达到吞吐量的红线。幸运的是，由于这一切都是在AWS内部进行的，我们可以迅速增加新的实例，甚至重新调整现有实例的大小。DNS恢复了正常行为，查询失败停止，我们（以及出站消息交付）回到了正轨。
为了缓解未来这一特定问题，我们还在对DNS体系结构进行更改，以更好地将我们核心组件从相似、意外的门槛影响中隔离开来。我们还与亚马逊团队合作，确定适当的监控模型，为我们在类似事件影响到任何客户之前提供足够的警告。
题目 | 典型AWS工作负载 | SparkPost的出站电子邮件工作负载 |
|---|---|---|
流量模式 | 大多是入邦“拉”请求（网页、API、媒体） | 重度出邦“推”流量（数十亿封电子邮件） |
DNS依赖 | 轻度：每个内容请求1-2次查询 | 非常沉重：每封邮件多次DNS查询 + SPF/DKIM TXT检查 |
查询量 | 可预测并与用户活动成比例 | 随目标数百万域的出站活动激增 |
瓶颈类型 | CPU、内存或存储限制 | 实例类型的聚合网络吞吐量限制 |
失败模式 | 延迟降低或API超时 | DNS查找失败导致交付延迟 |
可见性 | 限制通常记录并显示在指标中 | 吞吐量上限未记录并在CloudWatch中不可见 |
缓解方法 | 扩大实例资源或增加缓存 | 迁移到带宽更高的实例系列 + DNS架构重新设计 |
为什么我们的DNS使用特别？这与电子邮件的工作方式有很大关系，相对于AWS最初设计的内容模型。基于Web的内容交付大量使用经典的入邦“拉”场景：客户端请求数据，无论是HTML，视频流，还是其他内容，从云端获取。但是像SparkPost这样的消息服务提供商的用例是对常规AWS场景的例外。在我们的案例中，我们做了大量的出站流量推动：特别是电子邮件（以及其他消息类型，如SMS或移动推送通知）。而这种推式流量非常依赖于DNS。
如果你熟悉DNS，你可能知道它通常是相当轻量级的数据。要请求给定的HTML页面，你首先必须询问该页面在互联网上可以找到的位置，但该请求只是你检索到的内容大小的一小部分。
然而，电子邮件则对DNS有着特别密集的使用，用于查找发送域——例如，SparkPost每个月向超过100万个独特域名发送数十亿封电子邮件。对于我们发送的每封电子邮件，我们必须至少进行两次DNS查询字典，并且对于反钓鱼技术如SPF和DKIM，DNS也是接收邮件所必需的。加上我们对AWS API服务的更多传统使用，它很难夸大DNS对我们基础设施的重要性。
这一切意味着我们遇到了一种不寻常的情况，即我们增长的出站消息量产生了DNS流量，其在实例类型上达到了聚合网络吞吐量限制，否则这些实例类型似乎有足够的资源来承载这种负载。正如去年对Dyn DNS基础设施的拒绝服务攻击所显示的那样，当DNS崩溃时，一切都会崩溃。（这也是任何构建依赖于DNS的系统的人都了解的痛苦问题。）
突如其来的DNS问题触发了我们的运营和可靠性工程团队的响应，以识别问题。我们与亚马逊的合作伙伴团队合作，以提升AWS运营方面的紧急程度。在合作中，我们找到了原因和解决方案。我们部署了具有更大网络容量的集群中的大容量名称服务器，能够满足我们的DNS需求，而不会达到吞吐量的红线。幸运的是，由于这一切都是在AWS内部进行的，我们可以迅速增加新的实例，甚至重新调整现有实例的大小。DNS恢复了正常行为，查询失败停止，我们（以及出站消息交付）回到了正轨。
为了缓解未来这一特定问题，我们还在对DNS体系结构进行更改，以更好地将我们核心组件从相似、意外的门槛影响中隔离开来。我们还与亚马逊团队合作，确定适当的监控模型，为我们在类似事件影响到任何客户之前提供足够的警告。
题目 | 典型AWS工作负载 | SparkPost的出站电子邮件工作负载 |
|---|---|---|
流量模式 | 大多是入邦“拉”请求（网页、API、媒体） | 重度出邦“推”流量（数十亿封电子邮件） |
DNS依赖 | 轻度：每个内容请求1-2次查询 | 非常沉重：每封邮件多次DNS查询 + SPF/DKIM TXT检查 |
查询量 | 可预测并与用户活动成比例 | 随目标数百万域的出站活动激增 |
瓶颈类型 | CPU、内存或存储限制 | 实例类型的聚合网络吞吐量限制 |
失败模式 | 延迟降低或API超时 | DNS查找失败导致交付延迟 |
可见性 | 限制通常记录并显示在指标中 | 吞吐量上限未记录并在CloudWatch中不可见 |
缓解方法 | 扩大实例资源或增加缓存 | 迁移到带宽更高的实例系列 + DNS架构重新设计 |
AWS和Cloud的Silver Lining
我不想淡化此事件对我们客户的影响。但是，我们能够将根本问题辨识为我们用例与AWS基础设施之间出现的意外交互，并在短时间内找到解决方案，这与我们创建SparkPost的方式以及我们与Amazon团队的良好关系密切相关。
SparkPost卓越的运营团队、我们的站点可靠性工程（SRE）团队和我们主要的技术架构师每天都与Amazon合作。AWS基础设施的优势使我们在优化SparkPost的云架构方面具备了真正的优势。在过去的两年里，与AWS如此紧密地合作也使我们在快速运行和启动AWS基础设施方面学到了很多，我们还享有AWS团队的深度支持。
如果我们不得不在传统数据中心模式中绕过类似的限制，那么解决这样的事情可能需要几天甚至几周的时间。这种敏捷性和响应能力只是我们将业务建立在云端和AWS上的原因之一。我们公司共享的云专业知识并不容易获得。Amazon一直是我们优秀的业务合作伙伴，我们为我们在AWS技术栈上取得的成就感到非常自豪。
SparkPost是首个从一开始就为云构建的电子邮件发送服务。这种原生云的方法是我们为云基础设施设计电子邮件API的基础，确保了开发者的可扩展性和可靠性。我们比任何人都从真正的云平台发送更多的电子邮件，有时这意味着进入未知领域。计算机科学的一个基本事实是，只有在规模化运作时，你才知道会出现哪些挑战。我们在AWS上发现了一个挑战，但我们的快速反应很好地体现了云所提供的灵活性。这也是我们对客户的承诺。
无论您是在AWS上构建自己的基础设施，还是一位利用我们SparkPost的客户，我希望对上周五发生的事情以及我们如何解决问题的解释对您有帮助。
我不想淡化此事件对我们客户的影响。但是，我们能够将根本问题辨识为我们用例与AWS基础设施之间出现的意外交互，并在短时间内找到解决方案，这与我们创建SparkPost的方式以及我们与Amazon团队的良好关系密切相关。
SparkPost卓越的运营团队、我们的站点可靠性工程（SRE）团队和我们主要的技术架构师每天都与Amazon合作。AWS基础设施的优势使我们在优化SparkPost的云架构方面具备了真正的优势。在过去的两年里，与AWS如此紧密地合作也使我们在快速运行和启动AWS基础设施方面学到了很多，我们还享有AWS团队的深度支持。
如果我们不得不在传统数据中心模式中绕过类似的限制，那么解决这样的事情可能需要几天甚至几周的时间。这种敏捷性和响应能力只是我们将业务建立在云端和AWS上的原因之一。我们公司共享的云专业知识并不容易获得。Amazon一直是我们优秀的业务合作伙伴，我们为我们在AWS技术栈上取得的成就感到非常自豪。
SparkPost是首个从一开始就为云构建的电子邮件发送服务。这种原生云的方法是我们为云基础设施设计电子邮件API的基础，确保了开发者的可扩展性和可靠性。我们比任何人都从真正的云平台发送更多的电子邮件，有时这意味着进入未知领域。计算机科学的一个基本事实是，只有在规模化运作时，你才知道会出现哪些挑战。我们在AWS上发现了一个挑战，但我们的快速反应很好地体现了云所提供的灵活性。这也是我们对客户的承诺。
无论您是在AWS上构建自己的基础设施，还是一位利用我们SparkPost的客户，我希望对上周五发生的事情以及我们如何解决问题的解释对您有帮助。
我不想淡化此事件对我们客户的影响。但是，我们能够将根本问题辨识为我们用例与AWS基础设施之间出现的意外交互，并在短时间内找到解决方案，这与我们创建SparkPost的方式以及我们与Amazon团队的良好关系密切相关。
SparkPost卓越的运营团队、我们的站点可靠性工程（SRE）团队和我们主要的技术架构师每天都与Amazon合作。AWS基础设施的优势使我们在优化SparkPost的云架构方面具备了真正的优势。在过去的两年里，与AWS如此紧密地合作也使我们在快速运行和启动AWS基础设施方面学到了很多，我们还享有AWS团队的深度支持。
如果我们不得不在传统数据中心模式中绕过类似的限制，那么解决这样的事情可能需要几天甚至几周的时间。这种敏捷性和响应能力只是我们将业务建立在云端和AWS上的原因之一。我们公司共享的云专业知识并不容易获得。Amazon一直是我们优秀的业务合作伙伴，我们为我们在AWS技术栈上取得的成就感到非常自豪。
SparkPost是首个从一开始就为云构建的电子邮件发送服务。这种原生云的方法是我们为云基础设施设计电子邮件API的基础，确保了开发者的可扩展性和可靠性。我们比任何人都从真正的云平台发送更多的电子邮件，有时这意味着进入未知领域。计算机科学的一个基本事实是，只有在规模化运作时，你才知道会出现哪些挑战。我们在AWS上发现了一个挑战，但我们的快速反应很好地体现了云所提供的灵活性。这也是我们对客户的承诺。
无论您是在AWS上构建自己的基础设施，还是一位利用我们SparkPost的客户，我希望对上周五发生的事情以及我们如何解决问题的解释对您有帮助。
