How bitdrift scaled to 121 million concurrent gRPC connections on Amazon CloudFront for live telemetry sporting events

如何通过 Amazon CloudFront 实现 1.21 亿个并发 gRPC 连接以支持体育赛事实时遥测 | AWS 架构博客

如何通过 Amazon CloudFront 实现 1.21 亿个并发 gRPC 连接以支持体育赛事实时遥测

当 1.21 亿部移动设备在直播开始后几秒内持续建立 gRPC 连接时，DNS 记录背后的路由策略比正常流量水平时对系统扩展性的影响要大得多。错误的策略会导致所有连接集中到单个源端点，将扩展成功转变为服务中断。由前 Lyft 基础设施工程师创立的移动可观测性平台 bitdrift，在为 T20 世界杯板球系列赛的重要客户交付实时遥测数据时，亲身体验到了这一点。当比赛开始时，Amazon CloudFront 成功应对了从接近零到每秒 11 万次请求峰值的流量激增。

bitdrift 与 AWS 账户团队在生产压力下诊断出连接集中模式。解决方案仅需一次 DNS 集中性调整：从加权路由迁移至多值答案路由。这一变更使 bitdrift 的多网络负载均衡器（NLB）架构实现负载均衡，最终以零服务器端错误为 1.21 亿台设备提供服务。

bitdrift 是一家由前 Lyft 工程师创立的移动可观测性平台，其轻量级 Capture 性能导向 SDK 从数百万台移动设备中提供实时遥测数据。当 bitdrift 接入一家其应用提供 T20 世界杯板球比赛直播的重要客户时，他们遇到了前所未见的扩展性问题：比赛开始后几秒内，流量从接近零激增至数千万个并发 gRPC 连接。

DNS 解析不平衡

2026 年 2 月下旬早期事件期间，bitdrift 在 CloudFront 和 NLB 源端点之间峰值负载下出现错误。AWS 账户团队（SA、AM、TAM、CloudFront 服务团队和 Amazon Route 53 专家）确定根本原因：Route 53 的加权路由策略每次 DNS 响应只返回单个 IP 地址。这导致所有 CloudFront 缓存主机在 TTL 有效期内解析到相同源端点，产生雷击效应，使单个 NLB 被流量压垮。

由 TTL 驱动的流量集中

在 Route 53 中使用加权路由时，每个 DNS 查询只返回单个 IP 地址。对于 CloudFront 的规模而言，这意味着所有边缘节点会在 DNS TTL 有效期内将源端点解析到相同的负载均衡器。这种集中效应会导致单个 NLB 吸收所有流量，直到 TTL 过期并发生新的解析。即使客户将 NLB IP 从 2 个扩展到 6 个，问题依然存在，因为加权路由仍每次响应只返回单个 IP。所有 CloudFront 边缘节点在 TTL 有效期内都解析到相同源端点，使增加更多源端点看似毫无效果。

与短暂的 HTTP 请求不同，gRPC 连接是长时连接，会在连接时解析的源上累积。这意味着，当 DNS 配置导致无状态流量出现轻微不均衡时，持久连接会引发灾难性的过载。即使客户将 NLB IP 从 2 个扩展到 6 个，问题依然存在。加权路由每次响应只返回单个 IP，所有 CloudFront 边缘节点在 TTL 期间都会解析到相同源。这使得增加更多源似乎没有任何效果。

架构图

下图展示了端到端架构，从 CloudFront 边缘节点通过 Route 53 到多区域 NLB 队列。

图 1. Amazon Route 53 是 CloudFront 与多可用区网络负载均衡器（NLB）队列之间的源面向 DNS 路由层。当 CloudFront 边缘节点需要访问源时，它们通过 Route 53 解析源域名，Route 53 会将流量导向 AZ-1、AZ-2 和 AZ-3 中的适当 NLB。每个 NLB 随后会将连接转发到其对应的 Amazon 弹性 Kubernetes 服务（Amazon EKS）工作负载，这些工作负载运行在虚拟私有云（VPC）中。在加权路由下，Route 53 每次 DNS 查询只返回单个 IP，导致所有边缘节点在每个 TTL 窗口内汇聚到同一个 NLB，从而产生雷击效应。

解决方案：多值答案路由

多值答案路由每次 DNS 查询可返回最多 8 个 IP 地址，并为每条记录内置健康检查。CloudFront 边缘节点可以在首次 DNS 解析时立即分散连接到多个源，消除单一源瓶颈。

客户侧的更改非常简单：

• bitdrift 从加权路由切换到多值答案路由，该路由每次 DNS 响应返回最多 8 个 IP，内置健康检查可立即将源连接分散到多个 NLB。

客户无需更改任何代码或重新设计架构。只需一次 DNS 配置更新，即可处理 1.21 亿个并发设备且零错误。

改变前后对比

| 方面 | 改变前（加权路由） | 改变后（多值答案路由） | |------|------------------|------------------| | 每个 DNS 查询返回的 IP 数量 | 1 | 8 | | 源负载分布 | 每个 TTL 窗口内所有流量指向单一 NLB | 立即分散到多个 NLB | | 突发流量下的行为 | 单一 NLB 被压垮 | 均匀分布，无单一过载点 | | 峰值负载下的错误 | CloudFront 与 NLB 之间的源错误 | 零服务器端错误 | | 客户端所需更改 | — | 仅需 DNS 配置更新 |

结果与关键指标

修复前，CloudFront 缓存主机在每个 DNS TTL 窗口（60 秒）内将源域名解析到单一 NLB IP。在流量激增期间，这会将所有源连接导向单一负载均衡器，超出其容量。

在 2 月 27 日事件（1400 万并发连接）中，约 80% 的请求因 HTTP 500 错误失败。尽管扩展到 4 个 NLB IP，3 月 1 日问题再次出现。加权路由仍然每次 DNS 响应只返回一个 IP，因此直到更改路由策略前，增加更多源均无效果。

3月4日切换至多值答案路由后，CloudFront缓存主机立即开始同时解析所有6个源IP。在随后的峰值事件中，源连接错误为零。到3月8日的最终比赛时，bitdrift处理了1.21亿个唯一设备和每秒11万+峰值请求，且没有服务器端错误。

关键指标

• 单场体育赛事期间有1.21亿个唯一设备。
• 每秒峰值请求达11万+。
• 成功应对了100倍的流量激增（从接近零到峰值仅需数秒）。
• 无服务器端错误。
• 客户端变更最小：仅需更新DNS配置。

切换前后的性能对比

改进总结

| 指标 | 切换前（3月1-2日） | 切换后（3月7-9日） | 改进 | |------|------------------|------------------|------| | 峰值5xx错误率 | 79.80% | 0.033% | 99.96%降低（2,418倍提升） | | 平均5xx错误率 | 1.87% | 0.003% | 99.84%降低（623倍提升） | | 峰值5分钟请求量 | 169M | 49.3M | 不同事件规模 | | 请求/秒峰值 | 563K | 164K | | | 平均4xx错误率 | 0.014% | 0.007% | 降低50% | | 服务器端故障 | 多个源故障 | 零 | 100%消除 | | 唯一设备数（3月8日） | 1.21亿 | |

技术操作指南

要将Route 53源记录从加权路由切换为多值答案路由，请按照以下步骤操作。如果您使用CloudFront和多个源负载均衡器，此配置可确保从第一个请求开始流量均匀分布在所有负载均衡器上。

先决条件

开始之前，请确保您具备以下条件：

• 具有Route 53和CloudFront访问权限的AWS账户。
• 您域名的Route 53托管区域。
• 两个或更多作为CloudFront源的NLB。
• 使用源域名配置的CloudFront分发。
• 安装AWS命令行界面（AWS CLI）（可选，用于CLI步骤）。

步骤1：识别当前源记录

首先检查当前源域名的记录情况。

在控制台中：

• 打开Route 53控制台。
• 在左侧导航栏中选择托管区域。
• 选择您的托管区域（例如，origin.example.com）。
• 找到源域名的记录（例如，origin.example.com）。
• 注意路由策略。如果显示为Weighted，本指南适用于您。

使用CLI：

aws route53 list-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --query "ResourceRecordSets[?Name=='origin.example.com.']"

您将看到类似以下内容：

[
  {
    "Name": "origin.example.com.",
    "Type": "A",
    "SetIdentifier": "nlb-1",
    "Weight": 50,
    "AliasTarget": {
      "DNSName": "nlb-1-abcdef.elb.us-east-1.amazonaws.com.",
      "HostedZoneId": "Z26RNL4JYFTOTI",
      "EvaluateTargetHealth": true
    }
  },
  {
    "Name": "origin.example.com.",
    "Type": "A",
    "SetIdentifier": "nlb-2",
    "Weight": 50,
    "AliasTarget": {
      "DNSName": "nlb-2-ghijkl.elb.us-east-1.amazonaws.com.",
      "HostedZoneId": "Z26RNL4JYFTOTI",
      "EvaluateTargetHealth": true
    }
  }
]

步骤2：为每个源创建健康检查

多值答案路由要求每个记录都附加健康检查。主要优势是不健康的源会自动从DNS响应中移除。

• 在Route 53中，左侧导航栏选择健康检查。
• 选择创建健康检查。
• 配置：
• 名称：nlb-1-health-check。
• 监控对象：端点。
• 指定端点方式：域名。
• 协议：TCP（如果源支持，也可使用HTTP/HTTPS）。

• 域名：nlb-1-abcdef.elb.us-east-1.amazonaws.com。

• 端口：您的源站端口（例如 443）。

• 请求间隔：10 秒（快速）适用于突发流量模式。

• 故障阈值：3。

• 为每个 NLB 重复此操作。

aws route53 create-health-check \
  --caller-reference "nlb-1-health-$(date +%s)" \
  --health-check-config '{
    "Type": "TCP",
    "FullyQualifiedDomainName": "nlb-1-abcdef.elb.us-east-1.amazonaws.com",
    "Port": 443,
    "RequestInterval": 10,
    "FailureThreshold": 3
  }'

第 3 步：创建多值答案记录

注意：多值答案路由需要 IP 地址记录，而非别名记录。在继续操作前，请为每个 NLB 可用区分配弹性 IP 地址 —— 应用负载均衡器不兼容此模式，因为它们不支持静态 IP 地址。

现在使用多值答案路由创建新记录。

• 选择 创建记录。

• 记录名称：origin（或您的子域名）

• 记录类型：A。

• 路由策略：多值答案。

• 值/路由流量到：输入第一个 NLB 的 IP 地址（或使用 NLB 的静态 IP）。

• 健康检查：选择为此 NLB 创建的健康检查。

• 记录 ID：nlb-1（此记录的唯一 ID）

• TTL：60 秒（保持较低值以实现更快故障转移）。

• 选择 创建记录。

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "origin.example.com.",
          "Type": "A",
          "SetIdentifier": "nlb-1",
          "MultiValueAnswer": true,
          "TTL": 60,
          "ResourceRecords": [{"Value": "10.0.1.100"}],
          "HealthCheckId": "abcd1234-5678-90ab-cdef-EXAMPLE1"
        }
      },
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "origin.example.com.",
          "Type": "A",
          "SetIdentifier": "nlb-2",
          "MultiValueAnswer": true,
          "TTL": 60,
          "ResourceRecords": [{"Value": "10.0.2.100"}],
          "HealthCheckId": "abcd1234-5678-90ab-cdef-EXAMPLE2"
        }
      }
    ]
  }'

第 4 步：删除旧的加权记录

在确认多值答案记录已正确返回（第 5 步）后，删除原始的加权路由记录。Route 53 不允许同一记录名称使用混合路由策略。旧的加权记录必须删除。

第 5 步：验证配置

dig origin.example.com +short

您应同时看到多个 IP 地址返回：

10.0.1.100
10.0.2.100
10.0.3.100

挑战总结

在生产压力下解决问题面临多个挑战：

• 火线诊断：首次故障发生在直播的 T20 世界杯比赛期间，当时有 1400 万并发连接。根本原因分析必须在实时进行，同时客户的生产流量仍在失败。

• 持久连接放大 DNS 路由问题：与短暂的 HTTP 请求不同，gRPC 连接是长寿命的，并在连接时累积到解析到的源站。这意味着 DNS 配置在无状态流量中产生轻微不均衡，会导致持久连接出现灾难性过载。

• DNS 缓存掩盖了真正的瓶颈：即使客户将 NLB IP 地址从 2 个扩展到 6 个，问题仍然存在。由于加权路由每次响应只返回单个 IP，所有 CloudFront 边缘节点在 TTL 有效期内都会解析到相同的源站。这使得增加更多源站似乎没有任何效果。

• 时间紧迫下的客户协调：客户最初不愿在下一场比赛前更改 Route 53 配置。在距离赛事仅剩数天的情况下，与 AWS 账户团队协作建立对 DNS 变更的信心，需要清晰传达根本原因和预期影响。

结论

这个案例表明，在极端规模下，看似常规的基础设施决策可能成为活动完美执行与生产故障之间的分水岭。选择 DNS 路由策略就是这样的决策。bitdrift 的架构设计是合理的：CloudFront 位于边缘，NLB 作为源站，使用 gRPC 实现高效的持久连接。但加权路由每次响应只返回单个 IP 的行为，导致了无法通过源站扩展解决的“雷击效应”。

解决方案纯粹是配置调整：将 Route 53 的路由策略从加权路由切换为多值答案路由。更改后，bitdrift 成功处理了 1.21 亿个并发设备，且没有出现任何错误。

如果你正在使用 CloudFront 并配置了多个源站负载均衡器，尤其是使用 gRPC 或 WebSocket 等持久连接协议时，请重新审视你的 Route 53 路由策略。多值答案路由可确保 CloudFront 边缘节点在首次 DNS 解析时就将源站连接分布到所有可用端点。这消除了在流量激增情况下加权路由可能造成的单源瓶颈。

如需进行赛前容量规划或与 AWS 专家讨论架构设计，请联系你的 AWS 账户团队或通过 AWS 支持服务寻求帮助。

关键要点

• 在极端规模下，DNS 路由策略的选择至关重要。加权路由与多值答案路由对 CloudFront 后端源站负载分布会产生显著影响。

• 持久连接（gRPC、WebSocket）会放大 DNS 路由问题。与连接生命周期短暂的无状态 HTTP 不同，持久连接会在连接时解析到的源站上累积。一个导致 HTTP 流量轻微不均衡的 DNS 配置错误，可能会在持久连接下引发灾难性的过载。

• 赛前容量评估阶段尽早与 AWS 服务团队沟通，可有效避免活动当天的故障。

• 通过调整 DNS 配置即可提升系统规模，无需进行架构变更。

作者简介

'"`