夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想=『夢』と、潰えた夢=『ガラクタ』の集積場です。

Apache Kafka 0.8.0の新機能/変更点

こんにちは。最近Clojureのお勉強投稿ばかりでしたが、Kafkaについて肝心なことを見落としていたので記述しておきます。

Kafkaは現在0.8.0が最新バージョンで開発が進められています。
かつ、0.8.0で大きく信頼性が向上しているようなので、実際何が新しくなったかをまとめておきます。

Kafkaは今まではKafka Brokerプロセスが落ちると該当のBrokerが保持していたパーティションは消滅していた。
だが、0.8.0系以降は「設定でレプリカ数を1にしない限りレプリカを確保する」という動作となる。
=====
尚、Kafkaのレプリカ機能はCAP定理で言えばなんとCP型。
「ネットワーク分断」という障害はほぼ発生しないとして割り切るアプローチを取っています。
=====

  • ProducerとConsumerプロセスのレプリカへの対応

KafkaはProducer⇔Broker間の通信において、Ackを返すタイミングを3段階から選択可能。
「即時」「リーダーに書きこみ完了」「全レプリカに書きこみ完了」
Consumer側は「全レプリカに書きこみ完了」したメッセージのみを取得する。

  • Consumerのデータ取得待ち時のモデル変更

今までは定期的にポーリングして確認するモデルだったが、ロングポーリング方式に変更され、ネットワークの負荷を低減している。

  • Consumer側からもパーティショニングキー確認可能

Producerがパーティショニングに使用しているキーを保持しているため、Consumer側からもパーティショニングキーがわかる。
=====
とありますが、いまいち具体的にどう動作に影響が出るかは不明です。
=====

  • Consumerの読み込み状況を管理するオフセットの変更

ログのどこまで読んだかを示すオフセットはバイトインデックスではなく論理インデックス(0,1,2,3...)に変更している。
論理インデックスはログのPoint-in-Timeと紐づけられ、従来のバイトインデックスと同様に動作する。
この変更は以下の3つの利点を持つ。尚、元々もっていたゼロコピーを生かした転送方式はそのまま維持されている。
1.その方が解決方法としてスマート
2.次のオフセットを計算することや、ファイルを逆からたどることが容易
3.Consumer側のcommitとBrokerで保持する圧縮メッセージ間のまれに発生する相互作用の解消

  • Producer側のZooKeeperへの依存除去

シンプルなクラスタ用のメタデータAPIを使うよう修正された。

  • 複数データディレクトリのサポート

JBODを用いている場合などに有効になる複数データディレクトリをサポート。

「高レベルの」Consumerに対してパーティションとオフセットを両方確認できるようにしている。

  • 自動テストの改善

チェックインごとに実行される統合パフォーマンステストシナリオを導入し、質の担保を行っている。
=====
これは実際にソースコードを確認するとレプリカやパフォーマンス系のテストコードが大量に増えています。
=====

尚、0.8.0は後方互換性はないため、バージョンアップ時にはZooKeeperのデータと旧バージョンのKafkaログデータを全て削除する必要があるそうです。

とりあえず、レプリケーションが搭載されたのが非常に大きいバージョンアップのようです。
後はつい最近になってKafkaのダウンロードページに待望のKafka-0.8.0betaのバイナリ媒体が追加されるなど、
現状もまだ結構なペースで開発は進んでいそうです。(但し、何故かScala2.8.0準拠。2.9.2用のビルドスクリプトも用意しているにも関わらず。)

・・・今まで旧0.7.0系に対してもバイナリリリースが存在しなかった方がおかしいといえばおかしいのですがw
このあたりも期待が持てますね。

この後はレプリカの方式などを調べてみます。
このあたり、他の分散系システムとの比較にもなりますしね。