主页
2024 年 4 月 29 日星期一，Braze 平台的美国集群几乎完全中断，全部或部分中断持续了近 11 个小时，影响了客户对我们仪表板的访问以及数据处理和消息发送。 在 Braze 13 年的历史中，这是我们第一次也是唯一一次发生如此严重的事件。 我们与客户的关系建立在信任的基础上，我们始终对构建弹性系统感到非常自豪，这些系统使我们的平台即使在苛刻的工作负载下也能保持可用性和性能。 在这次中断期间，我们未能兑现这一承诺，对于这对我们每一位客户造成的影响，我们深表歉意。
为了帮助您更好地了解发生的情况和原因，我将提供有关我们的架构的一些重要背景信息，详细描述中断的原因，引导您完成我们已经做出的更改，并概述我们将要开展的工作并在近期和未来实施。
Braze 为我们的八个美国集群中的每一个集群维护独立的服务器组。 Braze US 01 至 07 集群托管在 Amazon Web Services (AWS) 上，而 Braze US 08 集群托管在 Microsoft Azure 上。 在每种环境中，Braze 都使用多个可用区，并且系统的每个部分都有冗余。 如果出现可用区故障，我们会定期、透明地禁用受损可用区的路由和处理。 这使得我们能够在云服务提供商中断期间可靠地维持服务交付能力。
除少数例外，美国的每个集群都有自己的专用基础设施，除了在给定云区域的所有环境中使用的少数组件之外，这些集群彼此之间高度隔离，以降低风险一个集群的中断会影响其他集群。
由于 Braze 平台实时处理工作负载的强度，自 2013 年以来，我们与 Rackspace 合作托管定制配置的硬件来运行 MongoDB 数据库，以补充对 AWS 和 Azure 的使用。 我们的 AWS 和 Azure 环境配置了 AWS Direct Connect 和 Azure ExpressRoute 私有云连接器，通过专用光纤电缆将云环境连接到 Rackspace 数据中心维护的内部网络。 这种加密连接由支持多个接口的网络链接提供支持，每秒传输超过 100 GB 的网络流量，可在我们的云和 Rackspace 环境之间提供高性能的访问。
我们在 Rackspace 中的自定义环境是数百台物理服务器的所在地，这些服务器存放在专用于 Braze 的机柜中。 此设置包括冗余电源和冗余架顶交换机。 架顶式交换机是位于服务器机架中的网络设备，并将同一服务器机架中的设备和服务器连接在一起。 这些交换机至少每年进行一次故障转移测试，不会产生影响； 去年的测试于2023年8月3日成功举行。在这个自定义环境中，我们维护了数以万计的MongoDB数据库虚拟化容器。 与我们的云环境类似，我们在不同美国集群上的容器之间保持高度的物理隔离，以最大程度地减少中断并降低一个容器可能影响数据库中其他容器的风险。
世界标准时间 4 月 29 日 09:15，连接到我们的 Rackspace 服务器机柜的主 Cisco Nexus 网络交换机出现部分故障。 故障交换机发生故障时，不会通过故障转移自动激活辅助网络交换机，而是将故障交换机保留为主交换机。
网络交换机通过将网络数据包（称为“帧”）转发到目的地来路由流量。 为了有效地做到这一点，这些交换机保持对将设备连接在一起的网络拓扑的了解。 网络路由经常会根据各个组件的故障或速度缓慢而动态变化。 当这些变化发生时，交换机和其他网络设备相互通信以保持对网络拓扑的准确了解。
在大型网络中，设备之间通常会存在多条路径，这可能会导致路由“环路”（即数据包无法在其预期目的地停止，而是环回其起源地的情况）。 循环可能会造成“广播风暴”，流量最终无限循环，使网络链路饱和并导致中断。 为了防止这种情况发生，交换机被编程为发送有助于识别冗余链路的消息。 这些消息称为生成树桥协议数据单元 (BPDU)，并且是称为生成树协议 (STP) 的网络协议的一部分。 然后，交换机使用此信息来阻止流量端口，以防止在路由流量时出现环路。 如果物理链路或交换机发生故障，STP 有助于提供冗余，因为它可用于识别可发送流量的其他物理链路，并将先前的被动（即阻塞）链路提升为主动，以维持连接。
4 月 29 日事件发生时，交换机开始出现故障，它开始不断转发拓扑更改通知和 BPDU，使这些更改通知充斥网络。 这些数据包传播到分布交换机和其他交换机，导致生成树交换环路，从而导致网络完全中断。 虽然 STP 已到位，通过阻止检测到环路的网络端口来减少网络环路，但在 4 月 29 日的事件中，来自故障交换机的生成树流量错误转发导致网络中的其他交换机重新分析其生成树拓扑。 然后，由于其他交换机检测到来自故障交换机的高优先级 BPDU 数据包，分布交换机开始在先前阻塞的端口上转发，从而导致交换环路，导致网络过载并导致网络瘫痪。
由于此活动，Rackspace 数据中心工程师于世界标准时间 09:20 左右收到有关意外网络连接问题的警报，并开始解决该问题。 在世界标准时间 09:39 到 10:03 之间，Rackspace 数据中心工程师暂停了网络交换机，重新启动主交换机，并强制服务器机柜中的网络接口卡 (NIC) 故障转移到辅助交换机。 NIC 故障转移后，Braze 环境中的物理服务器的连接已恢复。
Braze 使用的 MongoDB 数据库允许数据跨多个数据库服务器存储，这些服务器被称为“分片”。 MongoDB 提供了名为“mongoS”的路由服务，该服务处理来自 Braze 平台服务的查询，确定分片集群中相关数据的位置，然后将查询路由到适当的 MongoDB 数据库。 Braze 拥有数百个不同的 MongoDB 数据库，包括超过 15,000 个“mongoD”进程，这些进程是运行数据库并存储特定 MongoDB 分片数据的程序。
每个数据库分片由一个主 mongoD 进程和至少两个辅助 mongoD 进程组成，可在发生故障时提供高可用性。 每个 mongoS 服务器都与它可以将查询路由到的每个 mongoD 保持网络连接。 这些 mongoD 进程还连接到其配置中的主进程和辅助进程； 这称为副本集。 如果 mongoS 无法连接到给定的 mongoD，它将将该进程标记为离线并安排重试。 同样，如果 mongoD 无法在一秒内连接到其副本集的其他 mongoD 成员，它将超时，将这些进程标记为离线，并安排重试。
在网络循环期间，由于我们的 MongoDB 进程无法正常连接，因此每个进程都将其所有关联进程标记为离线。 也就是说，每个 mongoS 进程将其所有关联的 mongoD 进程标记为离线，每个 mongoD 进程将其相关的副本集成员标记为离线。 然而，即使 Rackspace 恢复了与物理服务器的网络连接，mongoS 或 mongoD 进程也没有重新建立与其他已标记为离线的进程的所有连接。
此时，为了协助我们的 Rackspace 数据库管理员 (DBA) 团队的修复工作，Braze DevOps 团队开始快速调试和测试恢复连接的方法。 我们的调查确定，唯一可用的选择是重新启动虚拟化容器中近 16,000 个 mongoD 和 6,000 多个 mongoS 进程中的每一个。 考虑到这项工作的规模巨大，而且事实上不存在自动化来快速重启如此多的容器，Rackspace 工程师在事件期间编写了新代码来创建动态自动化功能。
不幸的是，随着重启进程的加快，域名系统 (DNS) 系统中出现了另一个问题。 当 mongoS 和 mongoD 进程上线时，它们会在称为 DNS 查找的过程中向 DNS 解析器请求信息。 由于重新启动速度驱动的连续 DNS 查找，DNS 服务器负载过重，导致 mongoS 层在重新连接到 mongoD 进程时出现连接超时。 为了适应这种不断增长的负载，我们的 Rackspace 团队增加了 DNS CPU 容量，但随后被迫再次重新启动 mongoS 层，以便创建从每个 mongoS 到其关联的 mongoD 进程的健康连接。
世界标准时间 17:05 左右，重启过程允许一些集群开始恢复在线状态。 随着数据库性能恢复和集群稳定，Braze 继续提高数据处理和消息发送能力； 然而，由于先前无法提供，导致大量积压，使这项工作变得复杂。
考虑到我们的 Rackspace 数据库环境（由数百个不同的数据库组成）的规模和复杂性、中断的持续时间以及由此产生的积压量（代表数十亿条消息和数十亿个摄取的数据点），恢复过程需要-我们正常恢复过程的即时调整。 这是必要的，以确保数据库资源与持续的处理需求保持平衡，包括引入大量的总体处理能力。
然而，这样做时，Braze 达到了 AWS 对我们能够配置的虚拟 CPU 数量的限制，阻止我们添加任何额外的服务器容量。 Braze 团队与我们的 AWS 团队迅速升级了这种情况，并获得了增长，使我们的工程师能够将我们的服务器处理能力扩展到创纪录的水平，这比我们之前在 Black 上达到的最大容量高出 50% 以上2023 年星期五。
到 UTC 时间 20:30，除 US 01、US 03 和 US 08 之外的所有美国集群均已完成积压处理，其余集群的处理速度达到或高于事件前一天的峰值速度。 几个小时内，所有集群都恢复到实时处理状态，我们宣布事件已解决。
在此类事件中，清晰、频繁的沟通至关重要。 虽然技术问题一般很少发生，而且如此严重的问题对于 Braze 来说是闻所未闻的，但我们始终尽力与受影响的各方进行清晰、快速的沟通。
在这种情况下，我们沟通策略的指导原则是诚实、透明和信任。 我们知道，我们只有一次机会对正在发生的事情诚实和直率，而事件的透明度（无论是在当时还是在事件解决后）对于维持信任至关重要。 归根结底，我们希望客户相信 Braze 将始终尽我们所能来解释、补救并防止任何事件再次发生。
在事件发生期间，我们使用状态页面来管理通信并定期提供有关情况的更新； 我强烈鼓励客户从该页面注册更新，以便跟上最新情况。 在 4 月 29 日的中断期间，我们通过我的联合创始人兼首席执行官 Bill Magnuson 发来的电子邮件对这些频繁的状态页面更新进行了补充。 该消息已发送给所有 Braze 仪表板用户，并提供给我们的客户团队，以便根据需要与其他客户利益相关者共享。
在此事件之前，我们的经验使我们相信，由于我们有冗余的网络交换机，我们的网络具有弹性。 然而，这次中断表明我们的网络拓扑（十多年来一直为我们提供了良好的支持）很容易发生灾难性故障。 现在很明显，未来必须加强它。
自事件发生以来，Braze 和 Rackspace 已更换并更换了故障交换机，并且 Rackspace 工程团队已完成了对 Braze 服务所依赖的网络基础设施的全面审核。 虽然硬件故障非常难以预测，尤其是在保修期内的设备，但可以通过监控来检测异常情况并确保快速响应。 两个团队现在正在合作做出改变，以防止未来的网络循环，即使在设备出现故障的情况下也是如此。 一些网络更改需要时间来实施，因为我们计划对网络拓扑进行有意义的更改，以进一步提高对环路的保护。 我们还向 Cisco 和 MongoDB 开立了支持票证，以更好地了解我们经历的故障场景，并提高 mongoD 和 mongoS 进程在网络故障后自我修复的能力。
自事件发生以来，我们一直与 Rackspace 保持日常联系，以针对近期变化采取行动并进行更大规模的网络增强，并将继续这样做，直到我们确信已经实现了改进的、更具弹性的网络设计。
我想再次对这一事件及其对您的业务以及您与客户的关系的影响表示歉意。 Braze 不可用的时间是不可接受的。 我们的工程领导和执行团队完全致力于做出所有必要的改变，以尽可能快速有效地识别和解决中断漏洞，以便我们能够再次赢得您作为可靠和高效合作伙伴的信任。
— 乔恩