Downloaded 56 times
Uploaded bymatsu_chara
Kafkaを使った マイクロサービス基盤 part2 ＋運用して起きたトラブル集
@matsu_chara 2016/5/31 Apache Kafka Meetup Japan #1 at Yahoo! JAPAN
Kafkaを使った マイクロサービス基盤 part2 ＋運用して起きたトラブル集
- 1. Kafkaを使った マイクロサービス基盤 part2 ＋運用して起きたトラブル集 @matsu_chara 2016/5/31 ApacheKafka Meetup Japan #1 at Yahoo! JAPAN
- 2.
- 3.
- 4. 自己紹介 • @matsu_chara • Ponylang非公式エバンジェリスト活動 •Scala新卒研修用テキスト
- 5. 話すこと • Kafkaを使ったイベントハブについて • イベントハブとしてのKafka •現在のシステム構成 • Kafkaの設定 • Kafka運用時辛かった事例 • TopicとPartition数増大による性能劣化 • FullGC発生によるPublish失敗 • Raidコントローラエラー発生事件
- 6.
- 7.
- 8. よくあるKafkaの使われ方 • ユーザーアクティビティログ・メトリクスの集約 => availability重視 •イベントハブ(受け取ったデータをロストしないこと が最重要) => durabilityを重視
- 9. よくあるKafkaの使われ方 • ユーザーアクティビティログ・メトリクスの集約 => availability重視 •イベントハブ(受け取ったデータをロストしないこと が最重要) => durabilityを重視
- 10.
- 11.
- 12. イベントハブとしてのKafka • Publisherが直接1:Nで配信するのは大変 • 様々な温かみが生まれた歴史… •各種サービスから情報を集約したいチームが出てきた 時に対応するコスト • 性能を各サービスでスケールさせるコスト
- 13.
- 14. イベントハブとしてのKafka • Kafkaを中心にしてデータを集約 • Kafkaのスケーラビリティにより、色々なサービスが情報 をsubscribe可能になる •publisherのシステム的な都合にsubscriberが影響さ れない（密結合を防ぐ）
- 15. 現在のシステム • Scala/Play/akka • 運用開始から半年ちょっと •Kafka 0.9(クラスタは一つ。まだあまり大きくない)
- 16.
- 17. Protocol Buffers onKafka • イベントのシリアライザは • 社内システム間連携の基盤として、メッセージの 互換性を保障・調整する役割も担いたい • 互換性維持のやりやすさを考慮して採用 • grpcも併せて社内のデータ交換形式の統一をし ていきたい
- 18. Kafkaの設定 • データを失わないことを重視 • Netflixの事例と方向性が異なる 項目名default値 Netflix 設定値 acks 1 1 all replication.factor - 2 3 min.insync.replica 1 ? 2
- 19.
- 20.
- 21. TopicAndPartition増大による 性能劣化 • partitionが増えるとPublish完了までの時間が悪化 • replicationfactorにも依存 • レプリケーションが主な原因のようなので num.replica.fetchers などをチューニングする
- 22. TopicAndPartition増大による 性能劣化 topicをたくさん作り、1topicにのみ100万件publishしたときのqps • グラフはHDDで計測したもの。SSDでも傾向自体は変化なし。 0 20004000 6000 8000 0100002000030000400005000060000 TopicAndPartiton qps
- 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. 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. 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. RAIDコントローラエラー発生事件 • 突然Kafkaへのpublishがタイムアウトし始める • ログを見るとRAIDコントローラが再起動していた •RAIDコントローラ再起動後のbrokerは正常に動作 • 最近の出来事で調査・対策の方針がまだ立ってい ない
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. RAIDコントローラエラー発生事件 • min.insync.replica=2なので1台落ちてもpublish できるという想定だった。 • しかし「brokerがackを返せない状態」で「クラスタ から離脱しなかった」ため、「acks=all」の設定により publishできなかったと思われる •brokerはzookeeperのハートビートには応答するが、 ackは返せないという状態になりうる？
- 37. RAIDコントローラエラー発生事件 • acks=2はkafka 0.9からは出来なくなっている •RAIDを使わない方針も考えられる？ • RAID以外のエラーでも同じような現象は起きうる のか？ • 自動で離脱しないなら、brokerを停止させる外部 機構が必要？
- 38. RAIDコントローラエラー発生事件 • Netflixのようにcold standbyなクラスタを用意 するのはどうなのか、調子の悪いbrokerを停止さ せるだけでは不十分？ •再現できていないので仮説ベースな部分あり • 意見募集
- 39. まとめ • 事例紹介 • 用途の違いを意識したチューニングが必要になる •Netflixのようなavailabilityを重視 • イベントバスとしてdurabilityを重視 • 運用トラブルが起きる前に、confluent/linkedin/clouderaなど の資料は一通り目を通しておくと後悔が少ない。 • 実際の運用時の環境を想定した負荷試験をしてみる