我们已将 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 优先架构为未来的 Web 进行了优化，同时继续为纯 IPv4 数据库提供出色的支持。我们正在积极与我们的合作伙伴合作，以改善整个数据库生态系统中 IPv6 的采用状况。我们的团队很高兴能与 Prisma Accelerate 一起站在创新的前沿，并期待更多令人兴奋的产品问世。

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