我們已將 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 來節省成本並提高正常執行時間。敬請期待，或註冊以獲取通知。