我们在用户毫无察觉的情况下将 Prisma Accelerate 迁移到了 IPv6

序言

我们应该首先简要介绍一下 Prisma Accelerate 的工作原理。我们早就应该深入探讨 Prisma Accelerate，因此我们将总结关键的架构要点。

Prisma Accelerate 构建于跨 Cloudflare 和 AWS 基础设施的混合云架构之上。Prisma Accelerate 的缓存、授权和请求路由方面发生在边缘，使用 Cloudflare Workers。这为部署在世界各地的应用程序带来了始终如一的快速缓存命中。边缘不太适合维护连接池和优化到位于单个区域的数据库的往返，因此 Prisma Accelerate 为每个项目在最靠近数据库的 AWS 区域中运行一个 EC2 实例。我们选择将项目完全隔离到他们自己的 EC2 实例，原因有很多，包括安全性、性能和工作负载隔离。

这些 EC2 实例以前使用 IPv4 网络，并被分配一个公共 IPv4 地址以进行外部通信。这种设置很简单：在 Prisma Accelerate 支持的 16 个区域中的每个区域中都有一个 VPC，每个 VPC 都有一个子网。EC2 实例是如何编排的变得更有趣，但我们将留到另一篇文章中讨论。

重要的结论是，Prisma Accelerate 在数千个 EC2 实例上运行，这些实例会随着使用模式的变化而进行配置和停用。每个实例每月额外增加 3.60 美元将影响我们为用户提供经济高效的解决方案的能力。我们需要消除公共 IPv4 地址。

IPv6 万物

任何希望过渡到仅 IPv6 的人都应该知道，IPv4 和 IPv6 是不同的、不兼容的协议。仅具有 IPv4 地址的机器无法与仅 IPv6 的机器通信，反之亦然。重要的是评估您的工作负载正在与哪些外部服务通信，并确定这些服务是否公布 IPv6 地址。

乍一看，Prisma Accelerate 似乎适合快速切换到 IPv6。所有传入流量首先通过基于 Cloudflare Worker 的边缘网络路由，该网络为我们的用户公布 IPv4 和 IPv6 地址（感谢 Cloudflare！）。从 Cloudflare 到 AWS 的通信发生在我们的内部网络中，该网络也支持 IPv4 和 IPv6。

挑战在于连接到用户的数据库。事实证明，许多流行的数据库提供商不公布 IPv6 地址。超过一半的 Prisma Accelerate 用户依赖于仅 IPv4 的数据库。这很不幸，因为这意味着使 Prisma Accelerate 的 EC2 工作负载仅使用 IPv6 不是一个选项。尽管如此，我们仍然需要消除 AWS 新征收的 IPv4 地址成本。

进入 DNS64 和 NAT64

我是 90 年代的孩子。我花了大量时间坐在 CRT 前玩 N64 🕹️。不幸的是，这并没有让我为 DNS64/NAT64 做好准备。

尽管 IPv4 和 IPv6 不兼容，但可以将从 IPv6 到 IPv4 的传出流量进行转换。特殊的 IPv6 范围 64:ff9b::/96 被指定用于称为 DNS64 的协议。DNS64 将 IPv4 地址编码为 IPv6 地址。当仅 IPv6 的服务器对 DNS64 名称服务器执行 DNS 查询时，它会将 IPv4 A 记录转换为 IPv6 AAAA 记录。然后，仅 IPv6 的服务器将向 DNS64 IPv6 地址发送请求。

仅 DNS64 只能编码和解码 IPv4 地址。另一个主机（通常是网关）必须侦听 DNS64 IPv6 地址以接收请求并将其代理到目标 IPv4。此过程称为 NAT64。网络路由配置被配置为将 64:ff9b::/96 范围路由到 NAT64 网关，因此所有仅 IPv6 的主机都不知道 DNS64/NAT64 过程。在 NAT64 就位的情况下，只有 NAT64 网关需要公共 IPv4 地址才能与外部仅 IPv4 的服务器通信。

这里有一个我们没有尽早发现的情况：显式 IPv4 地址不会被 DNS64 编码，因为它们不会经过 DNS 解析。我们有少量 Prisma Accelerate 用户在其连接字符串中使用了直接 IPv4 地址。最初的推出影响了一些这些用户。为了缓解这种情况，我们在 Cloudflare Workers 中的编排工作流程中添加了一些代码，以检测 IPv4 并使用 DNS64 对其进行转换，然后再将其传递给 EC2 实例。DNS64 转换是一个简单的函数，只需几行代码即可实现。

IPv6 优先

Prisma Accelerate 在我们称之为 IPv6 优先的方法中利用了 NAT64。Prisma Accelerate 支持的每个区域都运行一个启用了 NAT64 的 AWS NAT 网关。EC2 实例被放置到仅 IPv6 的 VPC 子网中，该子网自动从特定地址范围配置公共 IPv6 地址，不 配置 IPv4 地址。当 EC2 实例尝试连接到用户的数据库时，如果数据库也公布了 IPv6 地址，它将首选通过公共 IPv6 地址进行直接连接。否则，将解析 DNS64 地址，从而将请求通过附加的 NAT 网关路由到数据库，并通过 IPv4 进行连接。所有内部流量，包括从 Cloudflare 到 AWS 的请求，始终为 IPv6。

不幸的是，虽然这消除了 IPv4 地址成本，但它确实增加了通过 NAT 网关的额外数据传输成本。Prisma 已决定承担此成本，同时生态系统适应新的 IPv6 格局。我们做出此决定是为了使过渡尽可能对我们的用户无缝（您现在明白我们为什么选择这篇文章的标题了吗？😉）。此决定也符合我们在 Data DX 宣言 中提出的多项以开发者体验为中心的原则。

在 AWS 中使用 NAT 网关会产生额外的成本。对于许多工作负载，使用专用 IPv4 地址比使用 NAT 网关更具成本效益。对于其他工作负载，例如 Prisma Accelerate，NAT 网关是更具成本效益的解决方案。我们建议您进行自己的分析，以确定最适合您的解决方案。

未预见的情况

NAT64 解决了我们的外部网络挑战，但这仅暴露了我们在内部意外依赖 IPv4 的地方。

Prisma Accelerate 在 EC2 实例上运行进程，这些进程绑定到端口，用于从 Cloudflare 到 AWS 的通信。这些绑定侦听 IPv4 而不是 IPv6。幸运的是，这只是我们在基于 Cloudflare Workers 的编排代码中的一个简单更改，该代码动态配置 EC2 实例。

Prisma Accelerate 使用 Docker 在 EC2 实例上编排这些进程。我们最初观察到容器网络问题，但通过在本地 Docker 网络上启用 IPv6 快速解决了这些问题。

最后，一切都正常工作了，但网络调用似乎非常缓慢。经过一番挖掘（是的，使用 dig），我们确定速度缓慢是由 DNS 解析首先尝试查询 IPv4 地址，然后使用正确的 IPv6 地址引起的。这是因为我们的 EC2 基本 AMI 是在 IPv4 网络上创建的，并使用该配置还原。对 DNS 解析进行了一些调整后，速度看起来很棒。

推出

Prisma Accelerate 的分布非常广泛，因此此更改以渐进方式部署，对用户没有可见的影响。我们对此感到非常自豪。🏆

我们首先将新基础设施部署到所有区域。我们使用 Pulumi 管理基础设施，以确保我们的配置在部署中可重复，并且可供我们的团队审查。我们通过在每个区域中并排部署全新的 VPC、子网、NAT 网关……所有内容，来降低基础设施风险。

在我们修改编排代码以部署使用新基础设施的 EC2 实例之前，新基础设施一直未使用。我们按区域有条件地切换了新配置，使我们能够逐步启用它并密切监控结果。从我们的内部测试区域开始，我们按区域从使用率最低到最高逐步启用了新配置。

在一个区域中启用新配置也没有产生巨大的影响。正在运行的 EC2 实例不会立即被 Prisma Accelerate 替换。相反，随着实例被编排工作流程自然回收，旧的仅 IPv4 的实例被闪亮的新型 IPv6 优先实例所取代。Prisma Accelerate 的此属性对我们的推出至关重要，因为它最大限度地降低了对活跃用户的风险和影响。

最初的推出在数千名用户中非常顺利。是的，确实存在一些孤立的问题（墨菲定律！）。我们在计划中构建了这种可能性，使我们能够将出现问题的用户的孤立区域恢复到以前的版本，部署修复程序，然后使该区域再次恢复到 IPv6。随着时间的推移，所有用户实例都被替换，我们能够停用旧的基础设施。

结语

Prisma Accelerate 的 IPv6 优先架构为未来的 Web 进行了优化，同时继续为仅 IPv4 的数据库提供出色的支持。我们正在积极与我们的合作伙伴合作，以改善整个数据库生态系统中 IPv6 的采用状态。我们的团队很高兴能站在 Prisma Accelerate、Prisma Pulse 以及更多令人兴奋的未来产品创新的前沿。

今天的深入探讨是关于我们在内部网络上从 IPv4 切换到 IPv6。在下一篇文章中，我将深入探讨 Prisma Accelerate 架构。我们将探讨我们如何通过从 Kubernetes 迁移到 Cloudflare + EC2 来节省资金并提高正常运行时间。敬请期待或注册以获取提醒。