我们在不知不觉中将 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 利用 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 来节省资金并提高正常运行时间。请继续关注或注册以接收提醒。