Coinbase如何改造基礎設施中Kafka？

• 建立一個全功能的Kafka控制平面，以實現多叢集
• 硬化我們自制的Kafka資料平面 - 流媒體SDK
• 改善Kafka的上機體驗
• 擁抱Kafka Rest Proxy和schema Registry
• 在Databricks中開發流處理解決方案

MSK 多叢集聯合
與許多多租戶系統一樣，Kafka 也存在嘈雜的鄰居問題。例如，由於頁面快取汙染，滯後的消費者可能會影響其他對延遲要求苛刻的客戶端。此外，Kafka 叢集不會無限擴充套件，在某些時候，使用者將不得不將一些主題解除安裝到新叢集.

儘管 MSK（Amazon Managed Streaming for Apache Kafka）對網路分裂（單個可用區中斷）具有一定程度的容忍度，但跨區域故障轉移理論上可以將 Kafka 叢集的可用性從99.9%提高到 99.9999%。 
這些事實促使我們尋找彈性多叢集拓撲。憑藉對 AWS MSK 的累積知識，我們成功克服了跨 VPC Kafka 連線的網路挑戰。2022 年，在指定的流式 AWS 賬戶中啟動了一些新的 MSK 叢集。

今天，除了名為 <data-platform-primary> 的大型多租戶 MSK 叢集之外，還有一個服務專用的 MSK 叢集，用於追求極端延遲目標。我們正在積極地將 CDC（變更資料捕獲）管道和可觀察性指標遷移到兩個新的 MSK 叢集，在主叢集中只留下事件和釋出/訂閱訊息。將指標管道從 Kinesis 遷移到 Kafka 可以顯著節省相關的 AWS 成本，並改善延遲和可靠性。最終，相似類別的主題將位於同一組 MSK 叢集中。

每個類別都有一些不同的特徵——例如，CDC 事件是強排序的，而其他事件型別和釋出/訂閱訊息通常是弱排序的。釋出/訂閱訊息具有更嚴格的延遲和可用性要求。

功能齊全的 Kafka 控制平面
我們開發了一個 Kafka 控制平面用於以下目的

• 向指定的 MSK 叢集提供主題
• 管理 MSK 叢集上的主題 ACL
• 向 Kafka 客戶端和 SSO 使用者驗證和授權主題訪問
• 在 gRPC 和 REST 端點中公開主題和叢集後設資料

Kafka 資料平面 - Streaming SDK
Coinbase 的服務使用 Streaming SDK 作為資料平面與不同的訊息系統互動，即 Kafka、Kinesis、SQS 和 SNS。對於 Kafka 通訊，SDK 會定期到達 Kafka 控制平面以重新整理主題和叢集後設資料，如前所述。服務所有者免於 Kafka 客戶端配置的麻煩。SDK 配備斷路器，能夠根據負載均衡演算法重定向訊息 { na | 故障轉移 | 輪詢 | 複製 } 在區域 MSK 中斷的情況下。它本質上是 Kafka 叢集聯邦的一種輕型形式，有利於具有高可用性和低延遲要求的關鍵任務服務之間的非同步通訊。
稍微深入一點，典型的釋出/訂閱主題是弱排序的，訊息生產者可以在提供主題的 MSK 叢集之間自由切換，只要消費者端訂閱所有這些叢集。多個 Spark 流同時寫入Databricks 中的同一個 Delta 表沒有問題，這使得我們的動態路由方案可以端到端地用於資料流管道。
Streaming SDK 為 Kafka 生產者提供了固定和預先調整的設定，進一步簡化了入職體驗。內建的 Protobuf 序列化程式會自動在Confluent Schema Registry上註冊 Protobuf 模式以進行模式驗證和實施。在可觀察性方面，SDK 會自動發出包括延遲、成功/失敗率、訊息大小和其他健康指標的指標，以便於監控和警報。

豐富的安全模型
Kafka 主題ACL被編碼為 YAML 檔案並由 Kafka 控制平面管理。

控制平面負責在所有 MSK 叢集中傳播讀寫 ACL 策略。而 user-read 由Kafdrop和AKHQ獲取，以確定 SSO 使用者是否對該主題的訊息具有讀取許可權。

讓卡夫卡體驗愉快

Kafdrop是一個方便的 UI 工具，用於顯示叢集和主題配置、消費者組和滯後以及不同主題的訊息。當與 Confluent Schema Registry 整合時，Kafdrop 以 JSON 格式顯示protobuf訊息，而無需匯入 protoc 生成的庫。

AKHQ於 2022 年初引入 Coinbase 以支援多 MSK 叢集，我們對其管理能力和整合功能印象深刻。在 Github 中分叉 AKHQ 允許我們透過連線我們的 Kafka 控制平面來自定義其安全性，這決定了使用者的訪問級別。AKHQ 日復一日地執行以下操作：

• 根據使用者的要求清空主題
• 刪除架構登錄檔中的 protobuf 架構，以在引入中斷架構更改時取消阻止訊息釋出
• 根據使用者請求刪除消費者組
• 為消費者組重置提交的偏移量
• 更新不受控制平面監督的主題動態配置

與命令列工具相比，Kafdrop 和 AKHQ 都受到使用者的歡迎，因為測試和除錯變得更加容易。

Confluent REST 代理和架構登錄檔
對於使用缺乏生產級 Kafka 客戶端庫的程式語言開發的服務，Confluent REST Proxy是推薦的互動方式。
為了鼓勵使用結構化資料，並作為Kafka Connect的要求，我們釋出了用於輕鬆註冊 protobuf 模式的工具。非向後相容的模式更改將阻止生產者端的訊息釋出，以防止工程師破壞下游資料管道。

Kafka 流媒體管道
Coinbase 開發了一個本土流式攝取和資料庫複製框架 SOON（Spark cOntinuOus iNgestion），用於將來自各種資料來源的 Kafka 訊息攝取到 Delta Lake。為了解決舊的基於 Airflow 的 Kafka 到 Snowflake ETL 管道中的可擴充套件性和延遲挑戰，SOON 透過Spark 結構化流提供近乎實時的攝取效能，並支援以下用例的快速上線：

• Append-only場景（只支援insert）
• Merge CDC(Change Data Capture)場景（支援插入、更新和刪除）
• 合併非CDC場景（支援insert和update）
• Append-only 和 Merge 非 CDC 場景的資料回填

Kafka 事件和緩解措施
為了正確路由或接收關於特定主題的訊息，Kafka 客戶端必須瞭解代理拓撲以找出託管各個分割槽的代理。客戶端必須透過後設資料 API 呼叫以可配置的節奏重新整理資訊。當代理的請求佇列被後設資料請求飽和時，生產請求將被阻塞，從而影響 Kafka 生產者的吞吐量。此外，高 TLS 連線率通常會導致代理 CPU 使用率升高和 Kafka 效能下降。這些問題是由客戶端服務行為不當引起的，例如，我們發現 AWS Lambda 不斷為處理的每個請求建立新的 Kafka 連線。
Kafka broker 可以承受的 TLS 連線數是有限制的。以下是另一家雲提供商推薦的最大 TLS 連線數： 

這些數字與我們對 MSK 的觀察結果非常吻合——一個型別為 kafka.m5.12xlarge 的代理節點可以處理大約 30000 個 TLS 連線。找到正確的 Kafka 訊息金鑰幫助我們減少了代理連線數。例如，所有 Coinbase 服務發出的可觀察性指標都被攝取到指定 Kafka 叢集內 512 個分割槽的同一主題中。如果沒有指定訊息金鑰，每個Telegraf sidecar 將連線到所有代理以進行迴圈，從而導致可怕的 TLS 連線計數和過度配置的 MSK 叢集。選擇 EC2 例項 ID 作為訊息金鑰有效地將代理連線減少到每個 EC2 例項一個。