kafka 0.10.0 アップデート、プロダクション100ノードでやってみた #yjdsnight
Post on 09-Jan-2017
1.076 Views
Preview:
TRANSCRIPT
自己紹介
• 氏名• 森谷 大輔
• 業務• 社内ストリーム処理PFの構築
• ストリームなアプリケーションの開発
• ストリーム周りで使う• Kafka, Storm,
Cassandra, Elasticsearch
2
本日の話
• Yahoo! のストリーム処理プラットフォームで稼働しているある1つのKafkaクラスタを 0.8.1.1 から0.10.0 にバージョンアップした話
• 0.10.0 の機能等にフォーカスした話はしません(この後のセッションにもあるし)
• 稼働中の0.8系や0.9系クラスタからアップデートする人や新規導入でリリースする人の検討の一助になればと思います
3
Yahoo! JAPAN のストリーム処理プラットフォーム
6
• 様々なデータソースをリアルタイムに各サービスに提供、サービスの価値に貢献
アプリログ
ソーシャルログ
Weblog
IoT
Photo by insidetwit https://www.flickr.com/photos/insidetwit/
・異常検知 ・ウィンドウ集計・オンライン機械学習 ・ETL
Kafka採用理由
• LinkedInで実績がある
• Stormと相性が良い
• 高可用性
• Hadoopとも連携できる
• とりあえずデータを投げればサービスをまたがって再利用可能• consumer group と offset という素晴らしい概念
7
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>
Why 0.8.1.1 → 0.10.0 ?
• Kafkaクラスタへの書き込み性能向上見込み
• 普通にユーザが新しいOSSのclientを使えるようにしたい
• 新しいメッセージフォーマットに付与されたtimestampを使って audit がしたい• auditは過去もしていたのだがtimestampは独自producerライブラリをユーザに使ってもらう
ことで付与させていた
10
Kafkaクラスタへの書き込み性能向上見込み
• 投入ログの種類が増えることになったが、見積もったら現在のクラスタではbroker への書き込み性能限界にかかる• もうサーバは買わない、ソフト面で解決したい
• 対象クラスタのボトルネックは producer で圧縮したデータが broker で解凍再圧縮されることに端を発していた• 一定の保持期限を維持するためにgzip圧縮を採用していた
• 0.10では解消
• 大幅にクラスタの能力は向上するはずだという目論見があった• このクラスタは実は性能問題のためreplication factor=1にしていて、その状態でも冗長性を担保するため
にclientライブラリを自作し、ユーザに使うことを強制していた(やめたい)
11
リリースに踏み切る後押し理由
• 今回のアップデートは短期間で進めるのに好条件だった
• 背景にKafka 0.7 → 0.8バージョンアップ時の苦い経験• 互換性の無いAPI変更
• プラットフォーム側がコントロールできないほど多い利用者
• 原則ダウンタイム不可
• 何を検証すべきか、どんなオペレーションが発生するかノウハウが無い
• 想定外の高コストに・・・
• しかし今回クラスタのアップデート条件は• 0.8 client → 0.10 serverは互換性あり
• 利用者が少なく密な連携が可能
• リリース時ダウンタイム、損失が可能
• 前回の反省、ノウハウがある
12
いけるっ・・・
• 何を検証すればいい?
• ドキュメントに書いてあるから検証しなくてもいいということはない、しかし細かくやったらキリがない
• 自信があればやらないし、自信がなければやる、細かいところは正直運用勘 時間とリスクを天秤
broker視点の検証
問い 答え
今使われている client は冗長性を担保しつつ問題無く動く? Yes
これから使うことが決まっている client は冗長性を担保しつつ問題無く動く? Yes
性能要件、サーバを増やさなくてもしばらく後まで耐えれる? Yes
今までの日常オペレーションと同じことができる? Yes
想定のリリースオペレーションはアップデート条件にかなう? Yes
15
broker耐障害性検証• 特にproducerでbroker故障時に想定外に大量損失したりしないか見る
• かなりアナログなチェック手段
• ちゃんと損失する想定のところはこれで損失が判明、valueさえ見ればいつ損失したかも簡単にわかって安心感がある
• 想定の損失で済んだため冗長性の問いの答えはOKに
• ちなみにリーダーのpartitionをリアサインしても若干損失する
16
producer
value = timestamp
timestamp生成
ファイル書き出し
produce
broker
broker
consumer
ファイル書き出し
consume
1472131704003
1472131704001
1472131704000
・・・
1472131704003
1472131704000
・・・
sortdiff
ack = 1
性能検証
• ボトルネックになっていた broker への書き込み能力は 0.8.1.1 から
0.10.0 で約8倍の向上を計測した
• よって性能要件についての問いの答えはOKになった• producer でgzip圧縮しているユースケースならではの話
• 想定通りbrokerで解凍再圧縮が回避されているからだと思われる
• 注意• 圧縮に関わる性能テストは同じ内容のメッセージにすると圧縮率がものすごく良くなって意味
のないテストと化す
• 本番ログを一定量ファイルに書き出し、検証producerはそれを読んでproduceするようにした
17
戸惑ったこと①
• リリース時までパーティションの配置を正確に考えていなくてリリース時間がかかった• 例えば replication factor = 2 でも、オペレーションで一気に10台落としても大
丈夫なようにパーティション配置を考える必要がある
• 若干の損失が許容できるなら unclean leader election を有効にしていれば全レプリカが落ちても問題ないことは後で知った
• broker.idは自動採番でふったがその後ホスト名連番と合わせたくなった• log.dirsに配置されているmeta.propertiesファイルのbroker.idを書き換えて再起
動したら変更できた
20
戸惑ったこと②
• 特定のconsumer groupのオフセットリセットしたい要望があるんだけど0.10ではどうやるの?• 0.8系まではZooKeeperにオフセットが書かれる前提だったので今までは対象のznode
を削除するというオペレーションをしていた
• 0.9系からはKafkaにオフセットが書き込まれる前提、どうするのか?
• FAQに書いてあるが新しいJava consumerを使っていればseekメソッドで柔軟にオフセットが変更できる
• FAQは読んでおいた方がいい、ドキュメントの中でも重要度が高い
21
top related