Kafka 拔掉 ZooKeeper 的計畫

目前 Kafka cluster 還是會需要透過 ZooKeeper 處理不少資料,但眾所皆知的,ZooKeeper 實在是不好維護,所以 Kafka 官方從好幾年前就一直在想辦法移除對 ZooKeeper 的相依性。

這篇算是其中一塊:「Kafka Needs No Keeper」。

真的自己架過 Kafka cluster 就會知道其中的 ZooKeeper 很不好維護,尤其是 Apache 官方版本的軟體與文件常常脫勾,設定起來就很痛苦。所以一般都會用 Confluent 出的包裝,裡面的 ZooKeeper 軟體與 Confluent 自己寫的文件至少都被測過,不太會遇到官方文件與軟體之間搭不上的問題。

另外一個常見的痛點是,因為 Kafka 推動拔掉 ZooKeeper 的計畫推很久了 (好幾年了),但進展不快,所以有時候會發現在 command line 下,有些指令會把 API endpoint 指到 ZooKeeper 伺服器上,但有些指令卻又指到 Kafka broker 上,這點一直在邏輯上困擾很久,直到看到官方的拔除計畫 (但又不快) 才理解為什麼這麼不一致...

給需要的人參考,當初在架設 Kafka cluster 時寫下來的筆記:「Confluent」。

AWS 也把 Kafka 包出來當服務了...

AWS 發表把 Kafka 包起來當服務賣的 Amazon MSK:「Introducing Amazon Managed Streaming for Kafka (Amazon MSK) in Public Preview」。

另外 Kafka 所需的 ZooKeeper 部份已經被包進去了,不需要另外付費:

You do not pay for Apache Zookeeper nodes that Amazon MSK provisions for you, or data transfer that occurs between brokers and nodes within clusters.

目前看起來只提供 us-east-1 區域使用。

zetcd:用 etcd 跑 ZooKeeper 架構

在「zetcd: running ZooKeeper apps without ZooKeeper」這邊介紹了用 etcd 當作 ZooKeeper 伺服器。程式碼在「Serve the Apache Zookeeper API but back it with an etcd cluster」這邊可以看到。

不過可以看到有不少 overhead:

但 etcd 用 Go 寫 (省下 JVM tuning?),可能是個不錯的誘因...

Netflix 開發的 Delayed Queue

原來這個叫做 Delayed Queue,難怪之前用其他關鍵字都找不到什麼資料... (就不講其他關鍵字了 XD)

Netflix 發表了他們自己所開發的 Delayed Queue:「Distributed delay queues based on Dynomite」。

本來的架構是用 Cassandra + Zookeeper 來做:

Traditionally, we have been using a Cassandra based queue recipe along with Zookeeper for distributed locks, since Cassandra is the de facto storage engine at Netflix.

但可以馬上想到不少問題,就如同 Netflix 提到的:

Using Cassandra for queue like data structure is a known anti-pattern, also using a global lock on queue while polling, limits the amount of concurrency on the consumer side as the lock ensures only one consumer can poll from the queue at a time.

所以就改放到 Netflix 另外開發的 Dynamite 上:

Dynomite, inspired by Dynamo whitepaper, is a thin, distributed dynamo layer for different storage engines and protocols. Currently these include Redis and Memcached. Dynomite supports multi-datacenter replication and is designed for high availability.

後端是 RedisMemcached 的系統,可以對抗整個機房從 internet 上消失的狀態。

在設計上則是「保證會跑一次」,也就是有可能會有多次的情況,用 Dyno Queues 系統的人必需要考慮進去:

4. At-least-once delivery semantics

雖然整篇講的頗輕鬆,但實際看起來還是很厚重... 暫時還是不會用吧 :o

用 Docker 測試 Mesos

照著「Deploy a Mesos Cluster with 7 Commands Using Docker」上面的方法做,遇到一些小狀況,解決後總算是搞定了。

文章作者的目的是利用 Docker 在不弄髒環境下讓人很容易上手測試,不需要處理一堆 Java 以及設定檔的問題。讓沒有用過的人可以感受一下 MesosMarathon 的界面與操作。

總共會跑起四個 docker instance,分別是 ZooKeeper、Mesos Master、Marathon、Mesos Slave Container。

我遇到的問題是我在 Ubuntu 上面的 UFW 設為 default deny,造成這四隻程式之間溝通不良,最後是針對 docker0 這個 interface 放行:

# ufw allow in on docker0

有些感覺之後就可以看官網看更進階的功能操作。

Pinterest 對 ZooKeeper 的用法

在「ZooKeeper Resilience at Pinterest」這篇文章裡面,Pinterest 的人說明內部是怎麼使用 ZooKeeper,其中對我來說最重要的是這張圖:

程式不直接接觸 ZooKeeper 取得資料,而是透過 daemon 寫到 local disk 的資料取得。這樣當 ZooKeeper 失敗時仍然可以保持一定的服務 (因為 local disk cache),而避免服務中斷。

當然,這跟資料的性質有關,不是所有的資料型態都可以接受 cache。這種解法常常是在穩定性不是可以自己控制 (這個例子裡是 ZooKeeper),而且遇到問題時不希望整個服務就爆炸...

但這個思路每次看過每次都會忘記,寫下來不知道會不會比較容易想起來 :o