Kafka 0.10.0 アップデート、プロダクション100ノードでやってみた #yjdsnight
•
2 gostaram•2,772 visualizações
D&S Data Night vol.03 http://yahoo-ds-event.connpass.com/event/37040/ 発表資料
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Kafka 0.10.0 アップデート、プロダクション100ノードでやってみた #yjdsnight
Semelhante a Kafka 0.10.0 アップデート、プロダクション100ノードでやってみた #yjdsnight (20)
Mais de Yahoo!デベロッパーネットワーク
Mais de Yahoo!デベロッパーネットワーク (20)
Último
Kafka 0.10.0 アップデート、プロダクション100ノードでやってみた #yjdsnight
- 1. 2016年8月31日 1 ヤフー株式会社 D&S データプラットフォーム本部 森谷 大輔 Kafka 0.10.0 アップデート プロダクション100ノードでやってみた
- 2. 自己紹介 • 氏名 • 森谷 大輔 • 業務 • 社内ストリーム処理PFの構築 • ストリームなアプリケーションの開発 • ストリーム周りで使う • Kafka, Storm, Cassandra, Elasticsearch 2
- 3. 本日の話 • Yahoo! のストリーム処理プラットフォームで稼働しているある1つ のKafkaクラスタを 0.8.1.1 から0.10.0 にバージョンアップした話 • 0.10.0 の機能等にフォーカスした話はしません（この後のセッショ ンにもあるし） • 稼働中の0.8系や0.9系クラスタからアップデートする人や新規導入 でリリースする人の検討の一助になればと思います 3
- 4. アジェンダ • Y! のストリーム処理プラットフォームとKafka • アップデート経緯 • 検証、リリース • アップデートを通して戸惑ったこと • まとめ 4
- 5. アジェンダ • Y! のストリーム処理プラットフォームとKafka • アップデート経緯 • 検証、リリース • アップデートを通して戸惑ったこと • まとめ 5
- 6. Yahoo! JAPAN のストリーム処理プラットフォーム 6 • 様々なデータソースをリアルタイムに各サービスに提供、サービス の価値に貢献 アプリログ ソーシャルログ Weblog IoT Photo by insidetwit https://www.flickr.com/photos/insidetwit/ ・異常検知 ・ウィンドウ集計 ・オンライン機械学習 ・ETL
- 7. Kafka採用理由 • LinkedInで実績がある • Stormと相性が良い • 高可用性 • Hadoopとも連携できる • とりあえずデータを投げればサービスをまたがって再利用可能 • consumer group と offset という素晴らしい概念 7
- 8. アジェンダ • Y! のストリーム処理プラットフォームとKafka • アップデート経緯 • 検証、リリース • アップデートを通して戸惑ったこと • まとめ 8
- 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
- 11. Kafkaクラスタへの書き込み性能向上見込み • 投入ログの種類が増えることになったが、見積もったら現在のクラスタでは broker への書き込み性能限界にかかる • もうサーバは買わない、ソフト面で解決したい • 対象クラスタのボトルネックは producer で圧縮したデータが broker で解凍 再圧縮されることに端を発していた • 一定の保持期限を維持するためにgzip圧縮を採用していた • 0.10では解消 • 大幅にクラスタの能力は向上するはずだという目論見があった • このクラスタは実は性能問題のためreplication factor=1にしていて、その状態でも冗長性を担保するため にclientライブラリを自作し、ユーザに使うことを強制していた（やめたい） 11
- 12. リリースに踏み切る後押し理由 • 今回のアップデートは短期間で進めるのに好条件だった • 背景にKafka 0.7 → 0.8バージョンアップ時の苦い経験 • 互換性の無いAPI変更 • プラットフォーム側がコントロールできないほど多い利用者 • 原則ダウンタイム不可 • 何を検証すべきか、どんなオペレーションが発生するかノウハウが無い • 想定外の高コストに・・・ • しかし今回クラスタのアップデート条件は • 0.8 client → 0.10 serverは互換性あり • 利用者が少なく密な連携が可能 • リリース時ダウンタイム、損失が可能 • 前回の反省、ノウハウがある 12 いけるっ・・・
- 13. アジェンダ • Y! のストリーム処理プラットフォームとKafka • アップデート経緯 • 検証、リリース • アップデートを通して戸惑ったこと • まとめ 13
- 15. • 何を検証すればいい？ • ドキュメントに書いてあるから検証しなくてもいいということはない、しかし細かくやったらキリがない • 自信があればやらないし、自信がなければやる、細かいところは正直運用勘 時間とリスクを天秤 broker視点の検証 問い 答え 今使われている client は冗長性を担保しつつ問題無く動く？ Yes これから使うことが決まっている client は冗長性を担保しつつ問題無く動く？ Yes 性能要件、サーバを増やさなくてもしばらく後まで耐えれる？ Yes 今までの日常オペレーションと同じことができる？ Yes 想定のリリースオペレーションはアップデート条件にかなう？ Yes 15
- 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
- 19. アジェンダ • Y! のストリーム処理プラットフォームとKafka • アップデート経緯 • 検証、リリース • アップデートを通して戸惑ったこと • まとめ 19
- 20. 戸惑ったこと① • リリース時までパーティションの配置を正確に考えていなくてリリース時 間がかかった • 例えば replication factor = 2 でも、オペレーションで一気に10台落としても大 丈夫なようにパーティション配置を考える必要がある • 若干の損失が許容できるなら unclean leader election を有効にしていれば全 レプリカが落ちても問題ないことは後で知った • broker.idは自動採番でふったがその後ホスト名連番と合わせたくなった • log.dirsに配置されているmeta.propertiesファイルのbroker.idを書き換えて再起 動したら変更できた 20
- 21. 戸惑ったこと② • 特定のconsumer groupのオフセットリセットしたい要望があるんだけど 0.10ではどうやるの？ • 0.8系まではZooKeeperにオフセットが書かれる前提だったので今までは対象のznode を削除するというオペレーションをしていた • 0.9系からはKafkaにオフセットが書き込まれる前提、どうするのか？ • FAQに書いてあるが新しいJava consumerを使っていればseekメソッドで柔軟にオフ セットが変更できる • FAQは読んでおいた方がいい、ドキュメントの中でも重要度が高い 21
- 22. アジェンダ • Y! のストリーム処理プラットフォームとKafka • アップデート経緯 • 検証、リリース • アップデートを通して戸惑ったこと • まとめ 22
- 23. まとめ • Y! のストリーム処理プラットフォームで稼働しているあるKafkaク ラスタを0.8.1.1から0.10.0にバージョンアップした • 一番の目的は性能ボトルネックの改善 • ユーザ要件は短期間で検証、アップデートする上で都合が 良かった • アップデートをする上で何を検証するべきか考えた • 性能検証ではこのユースケースにおいてはbrokerへの書き 込み能力が8倍に向上した 23