Honeycomb使用Apache Kafka為資料攝取提供高可用性緩衝管道

當您將遙測資料傳送到 Honeycomb 時，Honeycomb 的基礎架構需要先緩衝您的資料，然後再在我們的“檢索器”列式儲存資料庫中進行處理。在 Honeycomb 的整個存在過程中，我們一直使用 Apache Kafka在我們的可觀察性管道中執行此緩衝功能。

在這篇博文中，我們將回顧我們如何到達今天狀態的歷史，為什麼我們對 Kafka 軟體和硬體如此挑剔，以及我們如何認證和採用新的基於AWS Graviton2 的儲存例項。最後，在本文的最後，我們將討論在過去兩年中進行累積優化後每兆位元組吞吐量的價格下降。

Honeycomb 中 Kafka 的簡要概述

使用 Apache Kafka 在攝取和儲存之間緩衝資料，通過永續性/可靠性和我們的工程團隊在可運維性方面使我們的客戶受益。從而滿足了每天向每項服務（甚至是有狀態的服務）傳送十幾次來更快地進行創新。

Kafka 是如何幫助我們實現這些結果的？

首先，Kafka 擁有經過充分稽核、久經考驗的機制，用於保證單個訊息的排序和永續性，使我們無需花費創新成本來編寫我們自己的 Paxos/Raft 實現，也無需擔心我們攝取工作者中的低階檔案系統重新整理。

其次，Kafka 確保多個讀取器，例如負責給定分割槽的冗餘檢索器節點或計算服務級別目標 (SLO) 的Beagle 節點，可以就他們接收的資料達成一致。

第三，也是最後一點，使用 Kafka 使我們能夠將無狀態的“牧羊人”攝取工作者與有狀態的“檢索器”儲存引擎分離，使我們能夠執行滾動重啟和更新，而不會導致客戶停機。

AWS最近宣佈，由 AWS Graviton2 處理器提供支援的 Amazon EC2 Im4gn 例項系列現已全面上市，我們很高興採用它作為下一代，在未來幾年為我們的 Kafka 叢集提供支援。它還代表了我們必須使架構不可知的最後一個工作負載——Honeycomb 的每個服務現在都能夠在 amd64 和 arm64 平臺上以生產規模執行。

。。。。。

用我們的平臺工程經理 Ben Hartshorne 的話來說，Kafka 是 Honeycomb 的“跳動的心臟”，為我們 99.99% 的攝取可用性 SLO 提供動力。

在供應商響應支援請求或將我們的 Kafka 主題永遠鎖定到供應商的託管代理之前，讓我們的客戶處於降級狀態對我們來說是不可接受的。然而，這並不一定意味著我們自己完成所有的打包工作，因此在 2019 年 7 月我們進行了滾動重啟，將自打包的 Kafka 0.10.0 轉換為 Confluent Community 5.3（Kafka 2.3），使我們未來的驗證和升級路徑更容易.

適當調整 Kafka 的大小對我們來說是一個具有挑戰性但很重要的問題，因為它代表了重大的基礎設施支出和銷售成本 (COGS) 的驅動因素。Kafka 需要調整以儲存正確的資料量，並需要提供適當的網路、記憶體和計算。從歷史上看，我們的業務需求意味著保留 24 到 48 小時的資料緩衝區，以防止檢索器中的錯誤破壞客戶資料的風險。如果我們在釋出後的幾天內發現錯誤，我們可以重放和重建資料以保持資料完整性。除了長期資料完整性用例，我們還在 Kafka 緩衝的資料視窗內使用短期召回作為普通操作的一部分。

當我們重新啟動一個檢索程式來部署一個新的構建時，我們會保留它在磁碟上的資料，但它需要重放在它關閉的幾分鐘內寫入的資料。每當 AWS 淘汰託管檢索器的例項時，我們都需要讓該節點從頭開始跟上速度。一個新的檢索器節點只需要獲取其前任的最新每小時完整檔案系統快照，以及獲取快照的 Kafka 偏移量。然後，它連線到 Kafka 並重播最多兩個小時，從偏移量開始到現在。由於例項故障很少見，我們還特意使用此緩衝區並通過每週終止和更換一個檢索器節點來驗證我們的災難恢復計劃。

但是需要重播數天資料的情況很少發生，而如果我們試圖讓新的檢索器節點趕上，我們需要非常快地返回過去一小時的資料。但也許有比每年在儲存和 CPU 上花費數十萬美元更好的解決方案，除非緊急情況，否則我們不會使用它。因此，在我在 Honeycomb 工作的近三年時間裡，我們對支援 Kafka 叢集的例項配置進行了三次改進，每次都針對當時最好的可用硬體來平衡效能、成本和利用率。

。。。。

混沌工程

混沌工程利用了我們在小學學到的科學方法：

1. 觀察：這正在發生。
2. 作為一個問題：如果發生這種情況會怎樣？
3. 建立一個假設：如果發生這種情況，那麼這將會發生。
4. 進行實驗。
5. 多觀察一些。
6. 做決定。
7. 再試一次，直到想要的結果。

我們設計了實驗來證明風險，以驗證我們的假設並驗證我們使用的彈性技術將在生產中保持不變。

對於資料，Honeycomb 混合使用Kafka、Zookeeper和 Retriever（這是它自己開發的儲存引擎來持久化資料）。該公司對其其餘系統進行定期更改，但他們對其資料堆疊的更改僅少於每月一次。

大約一年前，他們開始詢問有關這些長期執行的流程的問題，例如：

• 如果其中一個意外重啟會發生什麼？
• 即使它確實正確重啟，你如何驗證資料的完整性和一致性？
• 如果一臺機器重新啟動會發生什麼？
• 他們的單點故障在哪裡？

該團隊通過在一個環境中一次僅重啟一個 Zookeeper 來開始一項實驗。然後他們觀察變化。發生了什麼？與穩態相比有任何變化嗎？

他們意識到，當他們重新啟動 Zookeeper 時，它停止向任何內部客戶傳送警報五到十分鐘。他們觀察到，他們的流程依賴於領導選舉來執行這些 Honeycomb 警報的一份副本。

Honeycomb 團隊隨後進行了另一項實驗，以確保他們正在測量的一切——他們的遙測——執行正常。如果某件事失敗了，那麼遙測應該同意它失敗了。

Honeycomb 工程師確保解決他們的節點只與第一個 Zookeeper 例項對話的問題。但是當他們重新執行實驗時，他們發現了另一個問題，該問題也導致 Zookeeper 無法正常重啟。

重複實驗使團隊更上一層樓，以便在斷電中倖存下來。

一旦您執行了幾次實驗，您就可以使用諸如 Gremlin 之類的混沌即服務工具集自動執行該實驗。或者您可以手動繼續。

通過 Gremlin，Honeycomb 現在每週至少自動重啟一個節點，以驗證 Kafka 複製是否正常工作，以及他們的系統是否可以從單個 Kafka 節點故障中恢復。

另外，Honeycomb 團隊通過混沌工程發現了系統靈活性與節省的資金之間的直接關聯。既然他們知道他們的節點可以按需重新啟動，他們可以採用搶佔式例項，這可以節省一半的成本。此外，他們不需要對這些例項效能執行主動混沌工程，因為他們現在知道他們將如何執行。

更多點選標題見原文