介紹
今天，我們正式宣佈：繼 S3 WAL、EBS/Regional EBS WAL[1] 之後，AutoMQ 將在 2025 年的 12 月的新版本中全面支持以 AWS FSx 作為新的 WAL 存儲選項。AutoMQ 本身是一款完全兼容 Apache Kafka 協議、基於 S3 對象存儲構建的新一代 Diskless Kafka，通過自研的「WAL + 對象存儲」創新流存儲引擎，將寫入日誌與大規模持久化存儲解耦，在保證 Kafka 語義和穩定性的同時，大幅降低存儲成本、簡化運維，並已在行業內獲得廣泛認可。隨着 FSx WAL 的引入，AWS 上的 AutoMQ 終於補齊了關鍵的一塊拼圖：在 AWS 上，你可以在一套真正 Diskless 的 Kafka 方案中，同時兼顧消除跨 AZ 流量成本、多 AZ 級別容災能力以及接近本地磁盤體驗的低延遲。
Diskless Kafka 的延遲挑戰
近些年來，隨着 S3 API 憑藉極致低成本、彈性與共享存儲特性，逐漸成為雲上數據基礎設施的新標準，基於對象存儲重構流存儲引擎的 Diskless Kafka 方案開始興起。自 AutoMQ 在 2023 年率先提出基於共享存儲的 Kafka 架構以來，Diskless Kafka 已經成為 data streaming 領域的一股重要趨勢：在雲上，它天然具備計算與存儲解耦、按需彈性擴縮容、以及顯著的成本優勢。尤其是藉助共享存儲消除跨 AZ 流量費用，在 AWS、GCP 等主流公有云上，多 AZ 部署的 Kafka 集羣每月可以節省數千到數萬美元的網絡成本，這一點已經獲得大量雲上 Kafka 客户的高度認可，也是推動他們考慮遷移到 Diskless Kafka 方案的核心驅動力之一。
但 Diskless Kafka 也面臨一個根本性挑戰：如果只是簡單拋棄本地磁盤，把所有數據直接同步寫入對象存儲，就會徹底喪失 Kafka 最重要的能力之一——低延遲。對象存儲的設計目標是高可靠與高吞吐，而不是亞毫秒級寫入延遲。通常情況下，直接寫 S3 這類對象存儲的平均寫入延遲在 200–500ms 區間，即便使用諸如 S3 Express One Zone（S3 E1Z）這類最新產品，寫入延遲依然大約在 150ms 左右。對於微服務鏈路、撮合引擎、風控決策、實時風控等延遲敏感的金融與交易場景，這樣的延遲是遠遠不能接受的，也極大限制了市面上大多數 “對象存儲直寫型” Diskless Kafka 的適用範圍，使其更多隻能用於可觀測性、日誌採集、準實時事件流分析等對端到端延遲要求不那麼嚴苛的場景。
AutoMQ 在 2023 年提出並實踐了一條不同的技術路徑：基於「WAL 加速層 + 對象存儲」的共享存儲架構。通過在對象存儲之前引入一層高性能、低延遲的共享存儲作為 Write-Ahead Log（WAL），AutoMQ 將寫入路徑與低成本的對象存儲解耦，在保證 Kafka 語義的前提下，將大部分寫入與讀熱點落在低延遲存儲上，再以批量方式異步刷新到對象存儲，從而實現了真正意義上的低延遲 Diskless Kafka。這種架構有兩大關鍵價值：一是利用雲上低延遲共享存儲顯著提升寫入與讀取性能；二是通過 WAL 做批量聚合寫入，降低 S3 API 調用次數，進一步提升吞吐並控制成本。在 GCP、Azure 等支持 Regional EBS（或等價多 AZ 共享塊存儲）的雲上，基於 Regional EBS 的 WAL + 對象存儲架構，被業界普遍認為是當前 Diskless Kafka 的“理想形態”。
真正的技術難題出現在 AWS 上。與 GCP、Azure 不同，AWS 一直缺乏類似 Regional EBS 這種多 AZ 共享塊存儲服務，這意味着在 AWS 上構建低延遲的 Diskless Kafka 架構時，我們過去只能在 EBS 和 S3 之間做艱難取捨：
- 使用 EBS 做 WAL，可以獲得較好延遲，但仍然逃不開跨 AZ 複製帶來的網絡成本和複雜性；
- 直接用 S3 做 WAL，可以徹底避免跨 AZ 網絡流量成本，但端到端延遲難以滿足延遲敏感業務的需求。
這也是為什麼在很長一段時間裏，Diskless Kafka 在 AWS 上始終存在“要麼便宜但不夠快，要麼夠快但不夠便宜”的結構性短板。
為了解決這一矛盾，AutoMQ 在調研了 AWS 生態下的多種共享存儲服務後，最終選擇了 AWS FSx for NetApp ONTAP 作為 WAL 層的關鍵基礎設施。FSx ONTAP 既是一個跨 AZ 高可用的共享文件存儲服務，又可以在多 AZ 部署場景下實現低於 10ms 級別的平均寫入延遲，同時在計費模型上不疊加跨 AZ 流量費，完美契合 Diskless Kafka 對“低延遲 + 共享存儲 + 多 AZ”的複合訴求。藉助 AutoMQ 的 WAL 抽象，我們只需要一些固定容量的 FSx 作為高性能 WAL 空間，就可以將寫入先持久化到 FSx WAL 上，再批量刷寫到 S3，從而在 AWS 上首次實現：
- 保持 Diskless Kafka 的所有優勢：計算存儲分離、彈性擴縮、S3 級別的低成本；
- 消除跨 AZ 流量成本，支持多 AZ 部署與容災；
- 同時獲得接近本地盤體驗的低延遲寫入與消費。
這使得 AutoMQ 成為目前 AWS 上少有的、在成本、多 AZ 高可用與低延遲三個維度上幾乎沒有明顯短板的 Diskless Kafka 方案，也真正打開了 Diskless Kafka 在延遲敏感業務場景的應用空間。
FSx 如何消除跨AZ 流量費
要理解 FSx 如何幫助 AutoMQ 消除 Kafka 跨 AZ 流量費，可以先從“我們到底改了 Kafka 的哪一層”入手，再看 FSx 在這個新架構裏的具體職責。Apache Kafka 本身可以被拆分為三層：網絡層負責處理 KafkaApis 請求；計算層包含事務、壓縮、去重、LogCleaner 等核心邏輯，佔 Kafka 代碼的絕大部分；最底層是存儲層，通過 LocalLog 和 LogSegment 將無限長日誌落到本地文件系統。AutoMQ 保留了 Kafka 原生的網絡層和計算層代碼，只在存儲層的 LogSegment 這一非常薄的切面上，將本地磁盤替換為基於 “S3 + 低延遲 WAL（FSx）” 的共享存儲引擎，並在網絡層之上增加了一個 Zone‑routing interceptor。FSx 以區域級共享卷的形式承擔持久 WAL 的角色，所有寫入首先順序落到 FSx，再異步下沉到 S3。
在多 AZ 部署下，傳統 Kafka 的跨 AZ 流量主要來自三部分：三副本複製、跨 AZ 消費、以及跨 AZ 寫入。AutoMQ 通過單副本 + 雲存儲（S3/FSx）來承擔持久化與多 AZ 可用性，天然消除了集羣內三副本帶來的複製流量；再結合 rack‑aware 調度，可以讓消費者優先就近讀取，避免消費側跨 AZ。剩下最難的一塊，是生產者寫入導致的跨 AZ 流量。這裏 FSx 起到了關鍵作用：作為共享 WAL，它讓不同 AZ 的 Broker 可以“對着同一份日誌寫”，不需要在 Broker 之間再做數據複製；同時，Zone‑routing interceptor 會將跨 AZ 寫入“就地代理”到本 AZ 的 Broker，只把極少量控制信息跨 AZ 發送，而真正的大數據塊始終在本 AZ 寫入 FSx 並最終落到 S3。通過這套設計，AutoMQ 在保留 Kafka 協議兼容和跨 AZ 高可用的前提下，將跨 AZ 數據面流量壓縮到接近理論下限。
從結果上看，這個架構讓 AutoMQ 在 AWS 上實現了三個目標：
- 通過 FSx 提供的低延遲 WAL，保持接近本地盤的寫入與讀取體驗；
- 通過區域共享存儲和 Zone‑routing 機制，將跨 AZ 數據面流量壓縮到幾乎為零，僅保留少量控制消息；
- 通過 S3 承擔主存儲，繼續享受 Diskless Kafka 在成本和彈性上的全部優勢。
更多實現細節可以參考： How does AutoMQ implement a sub-10ms latency Diskless Kafka?
收益
引入 FSx 之後，AutoMQ 在 AWS 上的 Diskless 架構不再需要在“極致低延遲”和“極致低成本”之間做取捨：一方面，繼續保持存算分離、消除跨 AZ 數據面流量和基於 S3 的超低存儲成本；另一方面，只需少量、固定容量的 FSx 作為區域級低延遲 WAL，就可以把端到端延遲拉回到適配微服務、金融交易等核心實時場景的水平。下面我們分別從性能和成本兩個維度來説明這一組合方案帶來的收益。
性能解讀
從架構上看，AutoMQ + FSx 解決的是“跨 AZ 高可用場景下，如何在不引入跨 AZ 複製流量的前提下繼續獲得本地盤級別延遲”的問題。我們選擇 AWS 提供的 FSx for NetApp ONTAP Multi‑AZ 部署模式：在同一 Region 內由 FSx 在兩個 AZ 內託管一對 HA 節點，對外暴露為一個區域級共享文件系統，所有 Broker 都將其掛載為唯一的持久 WAL 設備。基於這層區域級共享 WAL，整個系統在高可用、彈性和網絡成本上形成了一個新的平衡點：
- FSx 提供接近本地 EBS 的隨機 IO 能力，同時在多個 AZ 之間自動冗餘，天然滿足跨 AZ 高可用要求；
- AutoMQ Broker 仍然是無狀態的計算節點，可以按負載彈性伸縮，而熱數據寫入全部匯聚到 FSx 上，再異步下沉到 S3；
- 由於數據不再在 Broker 之間複製，跨 AZ 的數據面流量基本被消除，只保留控制面通信。
在這樣的前提下，我們在 AWS us-east-1 用一個典型的高吞吐場景來測試端到端性能：
- 環境：6 台 m7g.4xlarge 作為 Broker，FSx ONTAP 採用 Multi‑AZ 雙節點部署，二代，配置 1,024 GiB 容量、4,000 預置 IOPS、1,536 MB/s 吞吐；
- 負載模型：4:1 讀寫比，64 KB 消息，持續 460 MB/s 寫入、1,840 MB/s 讀取，模擬線上高併發微服務和實時計算任務的混合壓力；
- 結果：寫入平均延遲 6.34 ms、P99 17.50 ms；端到端平均延遲 9.40 ms、P99 28.00 ms。
這組數據可以這樣理解：在保證跨 AZ 容災、完全存算分離、以 S3 作為主存儲的前提下，AutoMQ 通過一個固定大小的 FSx 層，把 Diskless Kafka 的 平均寫入延遲從“幾百毫秒量級”拉回到“ 10 毫秒以下”，接近傳統本地盤 Kafka 的體驗。這意味着，客户不需要再為“是否能用 Diskless 架構承載核心業務”擔心——包括鏈路複雜的微服務調用、毫秒級敏感的風控決策與訂單撮合等場景，都可以在 AutoMQ + FSx 上獲得既穩定又可預測的延遲表現。
成本解讀
在成本層面，AutoMQ 的核心設計是：用少量 FSx 構建一個可靠的區域級持久 WAL，用海量 S3 承接長期數據，從而形成與傳統 Kafka 完全不同的成本結構。
- FSx 只承擔高可靠、低延遲的持久 WAL 職責，用來承載最新一段寫入日誌，而不會用來長時間堆積業務數據；
- S3 負責存放絕大部分歷史數據，是集羣實際容量擴展的主要載體，主數據始終在 S3 上，整體存儲單價穩定在對象存儲量級；
- 由於副本冗餘集中在 FSx 與 S3 的服務級高可用上，AutoMQ 不再需要在 Broker 之間做日誌複製，也不需要跨 AZ 複製數據，從根源上降低了存儲和區域間流量開銷。
得益於這種分層設計，即便是 10 Gbps 寫入、50 節點規模的 AutoMQ 集羣，在 FSx 上也只需要不到 100 GB 的 WAL 空間；而在 1 Gbps 寫入 / 1 Gbps 消費、TTL 3 天的典型場景下，只需 6 台 m7g.4xlarge 和 2×1536 GB 的 FSx 即可滿足性能與可靠性需求。也就是説，雖然 FSx 單位容量價格更高，但我們只需要一小塊、基本固定容量的 FSx 用於 WAL，這部分成本與業務 TTL 長短、歷史數據規模幾乎無關，不會像傳統 Kafka 那樣隨着保留週期拉長而指數式增加副本存儲費用。同時，通過架構上取消跨 AZ 日誌複製和大部分跨 AZ 數據面流量，AutoMQ 避免了傳統 Kafka 在多 AZ 部署中鉅額的網絡與複製成本，使得整體 TCO 依然由廉價的 S3 存儲和按需伸縮的計算實例主導，而不是被大規模高價塊存儲和跨 AZ 帶寬費用綁架。
接下來我們通過下面這個具體的價格例子來説明價格優勢（單位：月）。從這組對比數據可以更直觀地看出 FSx 在整體成本結構中的價值：在生成端 P99 < 10ms 的同等延遲目標下，傳統 Apache Kafka 需要依賴大量高規格實例、三副本存儲以及跨 AZ 複製才能勉強達標，單月總成本高達約 22.7 萬美元，其中絕大部分支出都被昂貴的塊存儲和區域間流量吞噬。而 AutoMQ BYOC + FSx 通過固定容量 FSx WAL + S3 的架構，將副本冗餘下沉到 FSx/S3 的服務級高可用上，不再在 Broker 之間做日誌複製，也幾乎不產生跨 AZ 數據面流量，在提供同等級別（甚至更可預測）的亞 10ms 生成延遲的前提下，總成本僅約 1.8 萬美元量級，整體節省接近 10×。
與 AutoMQ 開源（S3 直寫）的方案相比，引入 FSx 後雖然新增了約 8,000 美元的 FSx 成本，但 S3 API 調用開銷顯著下降，同時將 P99 從近 900ms 直接拉回到幾十毫秒量級，完成了“以極小的額外成本換取接近本地盤體驗的低延遲”的升級。這也説明，在 AWS 上選擇 AutoMQ + FSx，本質上是用一個可控、線性可預估的 FSx 成本，換取傳統 Kafka 難以實現的低延遲、多 AZ 高可用和跨 AZ 流量成本近乎歸零的綜合收益。
AutoMQ BYOC x FSx: 雲市場試用
安裝 AutoMQ BYOC 控制面
你可以參考 AutoMQ 官方文檔[2] 從 AWS Marketplace 完成 AutoMQ 控制面的安裝。
創建集羣
登入 AutoMQ 控制面的 Dashboard，點擊 Create Instance 按鈕開始創建集羣流程。
在集羣創建步驟 Network Specs 部分選擇 3 AZ 部署。在 AWS 上，如果選擇單 AZ 部署，我們仍然首先推薦使用 EBS WAL，它具有最佳的性能、成本表現。在多 AZ 部署的時候，考慮到跨 AZ 網絡傳輸成本，你可以選擇 S3 WAL 或者 FSx WAL。關於 AutoMQ 選擇不同 WAL 時在成本、性能上的差異請參考官方文檔[3]。
選擇多 AZ 部署以後，你可以在計算存儲規格中勾選FS WAL 然後對集羣容量進行配置。
當你選擇 EBS WAL 或 S3 WAL 等選項時，集羣的容量規劃被簡化為僅需配置一個參數：AKU（AutoMQ Kafka Unit）。你無需再為如何選擇 EC2 實例類型、規格和數量而操心，AutoMQ 會自動為你挑選經過充分壓測驗證、在性能與成本之間最優的 EC2 實例組合，並確保集羣能夠穩定滿足平台所承諾的吞吐性能指標。例如，在 3 AKU 的配置下，AutoMQ 承諾可提供 60 MB/s 寫入、60 MB/s 讀取、2,400 RPS，以及不少於 3,375 個分區。通過將底層容量與算力抽象為 AKU，AutoMQ 將傳統 Kafka 部署中複雜而易出錯的容量規劃過程收斂為一個清晰可量化的指標；關於 AKU 的設計理念、基準測試方法和容量換算規則，可參考 AutoMQ 官方文檔獲取詳細説明[4]。
在本示例中我們選擇 FSx WAL，除了配置 AKU 之外，還需要額外選擇 Amazon FSx for NetApp ONTAP 的實例規格和數量。AutoMQ 已對不同 FSx ONTAP 實例規格進行了系統化的性能壓測與驗證，用户無需從 IOPS、帶寬、容量等維度自行做複雜規劃，只需根據目標寫入吞吐量，結合下表即可快速估算所需 FSx 實例數量。在當前配置中，我們選擇了 3 AKU（可支持 60 MB/s 的讀取與寫入），只需搭配 1 個 384 MBps 規格的 FSx 實例即可滿足 WAL 寫入性能需求。
- FSx 384MBps 規格，提供 150MiB/s Kafka 寫入
- FSx 768MBps 規格，提供 300MiB/s Kafka 寫入
- FSx 1536MBps 規格，提供 600MiB/s Kafka 寫入
讀寫測試
集羣創建完成後，你可以在集羣詳情頁面查看集羣的基礎信息，並按需對集羣容量進行彈性調整。
- FSx： 得益於 AutoMQ 存算分離的共享存儲架構，主數據全部持久化在對象存儲之上，FSx 僅用於加速 WAL 等熱路徑 I/O。你可以通過增加或減少 FSx 實例數量進行水平擴容，而無需像傳統 Kafka 那樣進行繁重的分區遷移和數據搬移，從而以業務無感的方式提升或收縮 FSx 可用容量與帶寬。
- AKU： 在完成 FSx 實例調整後，你可以進一步調整 AKU 的數量，使集羣的最大處理能力與 FSx 能夠提供的最大寫入能力相匹配，實現計算與存儲的解耦伸縮和整體資源利用率的最優化。
在本示例中，我們使用 AutoMQ 基於 OpenMessaging[5] 封裝的 perf 工具[6]來進行性能測試。我們在同一 VPC 內的一台 EC2 上發起瞭如下的測試負載。
KAFKA_HEAP_OPTS="-Xmx2g -Xms2g" ./bin/automq-perf-test.sh \
--bootstrap-server 0.kf-t1rf19ju6yrtl9fh.fsx-test-wanshao.automq.private:9092,1.kf-t1rf19ju6yrtl9fh.fsx-test-wanshao.automq.private:9092,2.kf-t1rf19ju6yrtl9fh.fsx-test-wanshao.automq.private:9092 \
--producer-configs batch.size=0 \
--consumer-configs fetch.max.wait.ms=1000 \
--topics 10 \
--partitions-per-topic 128 \
--producers-per-topic 1 \
--groups-per-topic 1 \
--consumers-per-group 1 \
--record-size 52224 \
--send-rate 160 \
--warmup-duration 1 \
--test-duration 5 \
--reset以下是本次示例場景下的讀寫性能測試結果，供參考。從實際測試數據可以看到，FSx 的寫入延遲與原生 Apache Kafka 處於同一量級，能夠滿足絕大多數對端到端延遲敏感的事件流與實時處理場景的要求。
總結
在這篇文章中，我們展示了 AutoMQ 在 AWS 上引入 FSx 作為 WAL 層之後，如何在保持 Diskless Kafka 架構全部優勢的前提下，把端到端延遲拉回到適配核心實時業務的水平：一方面，藉助「FSx + S3」的共享存儲架構，AutoMQ 實現了真正意義上的存算分離、多 AZ 高可用以及跨 AZ 數據面流量幾乎為零；另一方面，通過在 FSx 上構建一個小而高效的區域級 WAL，將寫入與讀熱點全部收斂到低延遲共享存儲，再異步下沉到 S3，從根源上重塑了 Kafka 在雲上的性能與成本結構。本次示例中，我們也對基於 FSx 的 AutoMQ 進行了簡單的性能驗證，可以穩定實現亞 10ms 級別的平均寫入延遲和幾十毫秒量級的端到端延遲，同時繼續享受 S3 級別的低成本存儲和無狀態 Broker 帶來的極致彈性伸縮能力。
如果你正在評估如何在 AWS 上為微服務、金融交易、風控決策等延遲敏感業務構建一套真正雲原生、低成本、可橫向擴展的 Kafka 基礎設施，歡迎直接在 AWS Marketplace [8]上一鍵部署並體驗 AutoMQ 搭配 FSx 的方案，親自驗證 Sub-10ms Latency Diskless Kafka 在你的生產環境中的表現與價值。
參考資料
[1] AutoMQ WAL Storage
[2] Guide: Install AutoMQ from AWS Marketplace
[3] AutoMQ's WAL Storage
[4] AutoMQ's AKU definition
[5] The OpenMessaging Benchmark Framework
[6] AutoMQ's Open Source Perf Tool
[7] AutoMQ AWS Marketplace
