Más contenido relacionado
La actualidad más candente (20)
Similar a Kafka 0.10.0 アップデート、プロダクション100ノードでやってみた #yjdsnight (20)
Más de Yahoo!デベロッパーネットワーク (20)
Kafka 0.10.0 アップデート、プロダクション100ノードでやってみた #yjdsnight
- 2. 自己紹介
• 氏名
• 森谷 大輔
• 業務
• 社内ストリーム処理PFの構築
• ストリームなアプリケーションの開発
• ストリーム周りで使う
• Kafka, Storm,
Cassandra, Elasticsearch
2
- 6. Yahoo! JAPAN のストリーム処理プラットフォーム
6
• 様々なデータソースをリアルタイムに各サービスに提供、サービス
の価値に貢献
アプリログ
ソーシャルログ
Weblog
IoT
Photo by insidetwit https://www.flickr.com/photos/insidetwit/
・異常検知 ・ウィンドウ集計
・オンライン機械学習 ・ETL
- 9. Kafkaクラスタバージョンアップ
• 今月頭、プラットフォームで稼働しているKafka(broker)クラスタの内1つを
Kafka 0.10.0 にバージョンアップデートした
• クラスタ概要
• 管轄している producer client もAPIバージョンアップ、Scala client ではなく Java client に
9
それまでのKafkaバージョン 0.8.1.1
クラスタ規模 100+ 物理ノード
(サーバあたり)ディスク SAS 4発
ネットワーク 1Gb Ethernet
メモリ 64GBMEM
CPU 12 core
<groupId>org.apache.kafka</groupId>
<artifactId>kafka_2.10</artifactId>
<version>0.8.1.1</version>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>0.10.0.0</version>
- 10. Why 0.8.1.1 → 0.10.0 ?
• Kafkaクラスタへの書き込み性能向上見込み
• 普通にユーザが新しいOSSのclientを使えるようにしたい
• 新しいメッセージフォーマットに付与されたtimestampを使って audit がした
い
• auditは過去もしていたのだがtimestampは独自producerライブラリをユーザに使ってもらう
ことで付与させていた
10
- 12. リリースに踏み切る後押し理由
• 今回のアップデートは短期間で進めるのに好条件だった
• 背景にKafka 0.7 → 0.8バージョンアップ時の苦い経験
• 互換性の無いAPI変更
• プラットフォーム側がコントロールできないほど多い利用者
• 原則ダウンタイム不可
• 何を検証すべきか、どんなオペレーションが発生するかノウハウが無い
• 想定外の高コストに・・・
• しかし今回クラスタのアップデート条件は
• 0.8 client → 0.10 serverは互換性あり
• 利用者が少なく密な連携が可能
• リリース時ダウンタイム、損失が可能
• 前回の反省、ノウハウがある
12
いけるっ・・・
- 16. broker耐障害性検証
• 特にproducerでbroker故障時に想定外に大量損失したりしないか見る
• かなりアナログなチェック手段
• ちゃんと損失する想定のところはこれで損失が判明、valueさえ見ればいつ損失したかも簡単にわかって安心感がある
• 想定の損失で済んだため冗長性の問いの答えはOKに
• ちなみにリーダーのpartitionをリアサインしても若干損失する
16
producer
value = timestamp
timestamp生成
ファイル書き出し
produce
broker
broker
consumer
ファイル書き出し
consume
1472131704003
1472131704001
1472131704000
・・・
1472131704003
1472131704000
・・・
sort
diff
ack = 1
- 17. 性能検証
• ボトルネックになっていた broker への書き込み能力は 0.8.1.1 から
0.10.0 で 約8倍の向上を計測した
• よって性能要件についての問いの答えはOKになった
• producer でgzip圧縮しているユースケースならではの話
• 想定通りbrokerで解凍再圧縮が回避されているからだと思われる
• 注意
• 圧縮に関わる性能テストは同じ内容のメッセージにすると圧縮率がものすごく良くなって意味
のないテストと化す
• 本番ログを一定量ファイルに書き出し、検証producerはそれを読んでproduceするようにした
17
- 20. 戸惑ったこと①
• リリース時までパーティションの配置を正確に考えていなくてリリース時
間がかかった
• 例えば replication factor = 2 でも、オペレーションで一気に10台落としても大
丈夫なようにパーティション配置を考える必要がある
• 若干の損失が許容できるなら unclean leader election を有効にしていれば全
レプリカが落ちても問題ないことは後で知った
• broker.idは自動採番でふったがその後ホスト名連番と合わせたくなった
• log.dirsに配置されているmeta.propertiesファイルのbroker.idを書き換えて再起
動したら変更できた
20