我們在無人察覺的情況下將 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、Prisma Pulse 以及更多令人興奮的即將推出的產品一起站在創新的前沿。

今天的深入探討完全是關於我們從內部網路上的 IPv4 切換到 IPv6。在下一篇文章中，我將深入探討 Prisma Accelerate 架構。我們將探索我們如何通過從 Kubernetes 遷移到 Cloudflare + EC2 來節省資金並提高正常運行時間。敬請關注或註冊以獲取提醒。