Kafkaを使った マイクロサービス基盤 part2 ＋運用して起きたトラブル集

Kafkaを使った マイクロサービス基盤 part2 ＋運用して起きたトラブル集

1. 1. Kafkaを使った マイクロサービス基盤 part2 ＋運用して起きたトラブル集 @matsu_chara 2016/5/31 Apache Kafka Meetup Japan #1 at Yahoo! JAPAN
2. 2. 今日のスライド http://www.slideshare.net/matsu_chara/kafka-part2
3. 3. part1のスライド http://xuwei-k.github.io/slides/kafka-matsuri/#1
4. 4. 自己紹介 • @matsu_chara • Ponylang非公式エバンジェリスト活動 • Scala新卒研修用テキスト
5. 5. 話すこと • Kafkaを使ったイベントハブについて • イベントハブとしてのKafka • 現在のシステム構成 • Kafkaの設定 • Kafka運用時辛かった事例 • TopicとPartition数増大による性能劣化 • FullGC発生によるPublish失敗 • Raidコントローラエラー発生事件
6. 6. • 利用用途の違いでKafkaのチューニングは どう変わるのか • 運用・性能面で困ったことを共有 話すこと
7. 7. Kafkaを使ったEventHubについて
8. 8. よくあるKafkaの使われ方 • ユーザーアクティビティログ・メトリクスの集約 => availability重視 • イベントハブ(受け取ったデータをロストしないこと が最重要) => durabilityを重視
9. 9. よくあるKafkaの使われ方 • ユーザーアクティビティログ・メトリクスの集約 => availability重視 • イベントハブ(受け取ったデータをロストしないこと が最重要) => durabilityを重視
10. 10. イベントハブとしてのKafka • 社内システム連携・メッセージングのための基盤
11. 11. イベントハブとしてのKafka • 社内システム連携・メッセージングのための基盤 サービス ニコ動/ニコ生とか Publisher 別システム 別サービスなど Subscriber
12. 12. イベントハブとしてのKafka • Publisherが直接1:Nで配信するのは大変 • 様々な温かみが生まれた歴史… • 各種サービスから情報を集約したいチームが出てきた 時に対応するコスト • 性能を各サービスでスケールさせるコスト
13. 13. イベントハブとしてのKafka • 社内システム連携・メッセージングのための基盤 サービス ニコ動/ニコ生など Publisher 他サービス メール通知など Subscriber
14. 14. イベントハブとしてのKafka • Kafkaを中心にしてデータを集約 • Kafkaのスケーラビリティにより、色々なサービスが情報 をsubscribe可能になる • publisherのシステム的な都合にsubscriberが影響さ れない（密結合を防ぐ）
15. 15. 現在のシステム • Scala/Play/akka • 運用開始から半年ちょっと • Kafka 0.9(クラスタは一つ。まだあまり大きくない)
16. 16. 現在のシステム • HTTPでイベントを受け取りKafkaへpublish • KafkaからsubscribeしHTTP/AMQPで通知 HTTP AMQP HTTP
17. 17. Protocol Buffers on Kafka • イベントのシリアライザは • 社内システム間連携の基盤として、メッセージの 互換性を保障・調整する役割も担いたい • 互換性維持のやりやすさを考慮して採用 • grpcも併せて社内のデータ交換形式の統一をし ていきたい
18. 18. Kafkaの設定 • データを失わないことを重視 • Netflixの事例と方向性が異なる 項目名 default値 Netflix 設定値 acks 1 1 all replication.factor - 2 3 min.insync.replica 1 ? 2
19. 19. Kafkaの設定 その他の設定はpart1で紹介。 もっとチューニングしたいけど機能追加の兼ね合いがあるので隙を見てやっ ていきたい もっと詳細な情報 http://xuwei-k.github.io/slides/ kafka-matsuri/#34 clouderaの資料 http://www.cloudera.com/ documentation/kafka/latest/topics/ kafka_ha.html
20. 20. Kafka運用辛かった事例
21. 21. TopicAndPartition増大による 性能劣化 • partitionが増えるとPublish完了までの時間が悪化 • replication factorにも依存 • レプリケーションが主な原因のようなので num.replica.fetchers などをチューニングする
22. 22. TopicAndPartition増大による 性能劣化 topicをたくさん作り、1topicにのみ100万件publishしたときのqps • グラフはHDDで計測したもの。SSDでも傾向自体は変化なし。 0 2000 4000 6000 8000 0100002000030000400005000060000 TopicAndPartiton qps
23. 23. TopicAndPartition増大による 性能劣化 • 現在はイベント頻度が高すぎないものに関しては partition数を1にして対処（必要に応じて増やす） • partition数の目安は1brokerあたり
 （100 * broker台数 * replication factor） 程度？
 (記事参照) 詳細 http://www.confluent.io/blog/how-to- choose-the-number-of-topicspartitions- in-a-kafka-cluster/
24. 24. TopicAndPartition増大による 性能劣化 • Netflixも抑えているが、そちらは可用性に関するチューニング？ • 故障時のオーバーヘッドを減らす 企業 目安 参考元 confluent 2000~4000 partitions/broker
 10K~ partitions/cluster http://www.confluent.io/blog/ how-to-choose-the-number-of- topicspartitions-in-a-kafka- cluster/ Netflix 200 broker/cluster 以下
 10K partition/custer 以下 http://techblog.netflix.com/ 2016/04/kafka-inside- keystone-pipeline.html
25. 25. FullGC発生によるPublish失敗 • 負荷試験中に発生。 • メッセージサイズによる。（Kafka的には1KB程度が最も 性能がでてGCにも優しいらしい） • Javaパフォーマンスに書いてあるようなことをひたすら やっていく。 clouderaの資料 http://www.cloudera.com/documentation/kafka/latest/ topics/kafka_performance.html 実際にやったチューニング http://xuwei-k.github.io/slides/kafka-matsuri/ #61
26. 26. RAIDコントローラエラー発生事件 • 突然Kafkaへのpublishがタイムアウトし始める • ログを見るとRAIDコントローラが再起動していた • RAIDコントローラ再起動後のbrokerは正常に動作 • 最近の出来事で調査・対策の方針がまだ立ってい ない
27. 27. RAIDコントローラエラー発生事件 Event
28. 28. RAIDコントローラエラー発生事件 RAIDコントローラに 異常発生
29. 29. RAIDコントローラエラー発生事件 想定 RAIDコントローラに 異常発生
30. 30. RAIDコントローラエラー発生事件 in-sync replicaから離脱 想定
31. 31. RAIDコントローラエラー発生事件 残った2台でack 想定
32. 32. RAIDコントローラエラー発生事件 in-sync replicaのまま 現実
33. 33. RAIDコントローラエラー発生事件 in-sync replicaのまま 現実 acks=allを待って
 タイムアウト
34. 34. RAIDコントローラエラー発生事件 現実 しばらく経った後 RAIDコントローラ 再起動
35. 35. RAIDコントローラエラー発生事件 現実 3台でack しばらく経った後 RAIDコントローラ 再起動
36. 36. RAIDコントローラエラー発生事件 • min.insync.replica=2なので1台落ちてもpublish できるという想定だった。 • しかし「brokerがackを返せない状態」で「クラスタ から離脱しなかった」ため、「acks=all」の設定により publishできなかったと思われる • brokerはzookeeperのハートビートには応答するが、 ackは返せないという状態になりうる？
37. 37. RAIDコントローラエラー発生事件 • acks=2はkafka 0.9からは出来なくなっている • RAIDを使わない方針も考えられる？ • RAID以外のエラーでも同じような現象は起きうる のか？ • 自動で離脱しないなら、brokerを停止させる外部 機構が必要？
38. 38. RAIDコントローラエラー発生事件 • Netflixのようにcold standbyなクラスタを用意 するのはどうなのか、調子の悪いbrokerを停止さ せるだけでは不十分？ • 再現できていないので仮説ベースな部分あり • 意見募集
39. 39. まとめ • 事例紹介 • 用途の違いを意識したチューニングが必要になる • Netflixのようなavailabilityを重視 • イベントバスとしてdurabilityを重視 • 運用トラブルが起きる前に、confluent/linkedin/clouderaなど の資料は一通り目を通しておくと後悔が少ない。 • 実際の運用時の環境を想定した負荷試験をしてみる