我们在无人察觉的情况下将 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，并为每个区域设置一个子网。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 地址并在将其传递给 EC2 实例之前使用 DNS64 进行转换。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 优先架构为未来网络进行了优化，同时继续为纯 IPv4 数据库提供出色的支持。我们正积极与合作伙伴合作，以促进数据库生态系统中 IPv6 的普及。我们的团队很高兴能与 Prisma Accelerate 一起走在创新的前沿，未来还将推出更多令人兴奋的产品。

今天的深入探讨主要关于我们在内部网络上从 IPv4 切换到 IPv6。在下一篇文章中，我将深入探讨 Prisma Accelerate 的架构。我们将探索如何通过从 Kubernetes 迁移到 Cloudflare + EC2 来节省成本并提高可用性。敬请关注或注册接收提醒。