我们已将 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 利用 NAT64，采用我们称之为“IPv6 优先”的方法。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 来节省成本并提高正常运行时间。敬请期待，或注册以获取通知。