Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -

1,451 views

Published on

Apache Kafka Meetup Japan #5 ( https://kafka-apache-jp.connpass.com/event/104465/ ) での発表資料です。

Published in: Technology
  • If you’re struggling with your assignments like me, check out ⇒ www.HelpWriting.net ⇐. My friend sent me a link to to tis site. This awesome company. After I was continuously complaining to my family and friends about the ordeals of student life. They wrote my entire research paper for me, and it turned out brilliantly. I highly recommend this service to anyone in my shoes. ⇒ www.HelpWriting.net ⇐.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -

  1. 1. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 2018年12月18日 Yahoo! JAPANのデータパイプラインで 起きた障害とチューニング ヤフー株式会社 データ&サイエンスソリューション統括本部 データプラットフォーム本部データデリバリー部パイプライン 橘 拓馬
  2. 2. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 自己紹介 2 橘 拓馬 2018年度新卒 • 8月からパイプラインチームに 配属され、Apache Kafkaを扱い始める IoT周りが好き
  3. 3. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 目次 3 1. はじめに 2. チューニングの実例 1. Request Handler が重い 2. 長時間連続運転すると突然プロセスダウン 3. まとめ
  4. 4. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. はじめに ヤフーは多種多様なサービスを抱え、 多数のユーザ様に利用していただいている デイリーユニークブラウザ数(FY17) 平均9053万ブラウザ アプリ合算デイリーアクティブユーザ数(FY17) 平均4249万人 ※各種指標はhttps://about.yahoo.co.jp/ir/jp/archives/data/より引用 運営サービス数 100超 4 より良いサービスを提供するために、 各サービスから生み出される大量のデータを横断的に活用できるよう 分析基盤に集約するシステムとしてApache Kafkaを活用
  5. 5. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. デイリーユニークブラウザ数(FY17) 平均9053万ブラウザ アプリ合算デイリーアクティブユーザ数(FY17) 平均4249万人 運営サービス数 100超 より良いサービスを提供するために、 各サービスから生み出される大量のデータを横断的に活用できるよう 分析基盤に集約するシステムとしてApache Kafkaを活用 はじめに ヤフーは多種多様なサービスを抱え、 多数のユーザ様に利用していただいている デイリーユニークブラウザ数(FY17) 平均9053万ブラウザ アプリ合算デイリーアクティブユーザ数(FY17) 平均4249万人 ※各種指標はhttps://about.yahoo.co.jp/ir/jp/archives/data/より引用 5 例:複数のサービスからユーザのWeb行動ログを収集、 最もユーザが興味の持ちそうな関連コンテンツをレコメンド サービスA サービスB サービスC あなたへの オススメ … 行動を分析
  6. 6. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. そのままでは理想通りに動いてくれない • Request Handlerが重い • 長時間連続運転すると突然プロセスがダウン パフォーマンスや安定性の問題が複数発生 6
  7. 7. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. Request Handler が重い
  8. 8. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 発生状況 複数存在するクラスタのうち一部だけ Request Handler のIdle%が低い 8 R/W Produce Request FetchConsumer Request Request Handler File System … Kafka Broker (一部省略) 多くのクラスタでのIdle%は90%以上 Idle% 30%を割るクラスタが発生
  9. 9. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 原因調査 各種設定の調査 Idle%が高いクラスタと低いクラスタの設定の違いを確認 • Kafka Broker • JVM • OS • ネットワーク →大きくパフォーマンスに影響する設定の違いはない Brokerに記録されたoffset情報を見てみると offset: 23400841903 … offset: 23400841904 … offset: 23400841905 … offset: 42847546267 … offset: 42847546279 … offset: 42847546291 … 通常のクラスタ 問題のクラスタ offsetの刻み幅がクラスタで異なる 9 +12 +1
  10. 10. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 原因調査 10 各種設定の調査 Idle%が高いクラスタと低いクラスタの設定の違いを確認 • Kafka Broker • JVM • OS • ネットワーク →大きくパフォーマンスに影響する設定の違いはない Brokerに記録されたoffset情報を見てみると offset: 23400841903 … offset: 23400841904 … offset: 23400841905 … offset: 42847546267 … offset: 42847546279 … offset: 42847546291 … 通常のクラスタ 問題のクラスタ +12 +1全クラスタのProducerで producer.properties の batch.size の値は同一 offsetの刻み幅がクラスタで異なる
  11. 11. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 答えはProducerに Producer1台あたりの req/sec< Partition数という構成が原因 Producer Broker … … Partitioner Produce RequestMessage Batch Producerは全てのPartitionに メッセージを振り分け linger.ms以内に 溜まるバッチの大きさが1 Request Handlerが 高負荷に 11
  12. 12. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. パラメータ調整/構成変更で対処? Producerの数を減らせば良い? • ビジネス要件で不可能 • サービスのサーバ群が高可用性とパフォーマンスの両立を求めているため、 サーバ台数 (= Producerの台数) が非常に多い。 • Producer1台あたりの req/secは少なく、台数が多い構成を変更できない Partitionを減らせばいい? • Kafkaの機能制約 • Partitionを減らすオペレーションはKafkaでは簡単にできない linger.msを長くすればいい? • ビジネス要件で不可能 • レイテンシが大きくなり、転送のリアルタイム性が犠牲になる 12
  13. 13. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. Keyed Messageの導入で解決 Producer Broker … … Keyed Message Keyed Message ProducerごとにKeyを設定 Producer1台あたりのreq/secが少ないのにも関わらずPartition数が多い → 1台のProducerからのメッセージは全て同じPartitionにProduceされるように ProducerごとにKeyの値を固定 linger.ms以内に溜まるBatchSizeを大きくできる!→ 解決 13 Partitioner Partition
  14. 14. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 長時間運用時の プロセスダウン
  15. 15. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 発生状況 使用したFile Descriptor をKafka Brokerが 掴み続け、解放されないクラスタが存在 →掴み続けたまま放置(数ヶ月)すると File Descriptorの上限に当たりプロセスダウン 通常のクラスタ (逐次解放しているため低位安定) 問題のクラスタ (解放できず増加しつづける) 15
  16. 16. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 原因調査 通常のクラスタに比べ、lsとlsofの差分が大きい をそれぞれ比較 16 # kafka.logs.dir 配下のファイル数 $ ls –l $KAFKA_LOGS_DIR | wc –l 25000 #プロセスが掴んでいるファイル数 $ sudo lsof -p `sudo jps |grep Kafka|cut -d " " -f 1`| wc -l 100000 # kafka.logs.dir 配下のファイル数 $ ls –l $KAFKA_LOGS_DIR | wc –l 5500 #プロセスが掴んでいるファイル数 $ sudo lsof -p `sudo jps |grep Kafka|cut -d " " -f 1`| wc -l 5700 通常のクラスタ 問題のクラスタ ・Kafka Brokerのkafka.logs.dir 配下ファイル数 ・Kafka Brokerが掴んでいるファイル数
  17. 17. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 原因調査 $ sudo lsof -p `sudo jps |grep Kafka|cut -d " " -f 1` java 6184 kafka … ….timeindex.deleted (deleted) java 6184 kafka … ….index.deleted (deleted) java 6184 kafka … ….timeindex.deleted (deleted) … JVMのGCで解放されるはずのFile Descriptor(FD)を保持し続けている 中身を確認 17 ・Kafka Brokerのkafka.logs.dir 配下ファイル数 ・Kafka Brokerが掴んでいるファイル数 をそれぞれ比較 # kafka.logs.dir 配下のファイル数 $ ls –l $KAFKA_LOGS_DIR | wc –l 25000 #プロセスが掴んでいるファイル数 $ sudo lsof -p `sudo jps |grep Kafka|cut -d " " -f 1`| wc -l 100000 # kafka.logs.dir 配下のファイル数 $ ls –l $KAFKA_LOGS_DIR | wc –l 5500 #プロセスが掴んでいるファイル数 $ sudo lsof -p `sudo jps |grep Kafka|cut -d " " -f 1`| wc -l 5700 通常のクラスタ 問題のクラスタ
  18. 18. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. KafkaのLog RetentionとFile Descriptorの関係 18 JVM File System FD FD … Open … ….index Open • KafkaはLogファイルを定期的にRetentionする ….index.deleted
  19. 19. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. KafkaのLog RetentionとFile Descriptorの関係 19 JVM File System FD … … (Openしていた) FD ….index.deleted (deleted) • KafkaはLogファイルを定期的にRetentionする • LinuxのFile SystemはRetention後存在しなくなったLogファイルに `(deleted)`とマーキング Open
  20. 20. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. KafkaのLog RetentionとFile Descriptorの関係 20 JVM File System FD … … FD GC時に解放 • KafkaはLogファイルを定期的にRetentionする • LinuxのFile SystemはRetention後存在しなくなったLogファイルに `(deleted)`とマーキング • マーキングされたファイルを参照するFDは、 GC(Young GC / Mixed GC / etc.)の際に解放される Open
  21. 21. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. GCはどれだけ起きている? $ cat kafkaServer-gc.log XX:XX:XX : [GC concurrent-root-region-scan-start] XX:XX:XX : [GC concurrent-root-region-scan-end, 0.0607977 secs] XX:XX:XX : [GC concurrent-mark-start] XX:XX:XX : [GC concurrent-mark-end, 0.0638311 secs] XX:XX:XX : [GC remark 2018-06-22T03:25:15.973+0900: 46088.225: [Finalize Marking, 0.0123461 secs] XX:XX:XX : [GC cleanup 12G->12G(32G), 0.0169348 secs] XX:XX:XX : [GC pause (G1 Evacuation Pause) (mixed), 0.0065863 secs] GCのログを確認 通常のクラスタ : Mixed GC の発生ログ 問題のクラスタ : Mixed GC が発生していなかった deleted ファイルの解放をするにはMixed GCが必要と推測 21
  22. 22. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. なぜGCの頻度が違うのか? 22 クラスタごとのreq/secの違いが原因 req/secの多いクラスタでは Kafka Brokerで確保するオブジェクトの数や容量も多くなる Young GCの実行頻度が多い $ cat kafkaServer-gc.log | grep young … 17:08:55.853 … [GC pause (G1 Evacuation Pause) (young), … 17:08:57.611 … [GC pause (G1 Evacuation Pause) (young), … 17:08:59.396 … [GC pause (G1 Evacuation Pause) (young), … 17:09:01.185 … [GC pause (G1 Evacuation Pause) (young), … 17:09:03.005 … [GC pause (GCLocker Initiated GC) (young), … 数秒おき Old領域内の使用容量が Mixed GC発生閾値まで上昇しやすい Old領域使用量 Mixed GC発生
  23. 23. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. なぜGCの頻度が違うのか? 23 クラスタごとのreq/secの違いが原因 問題のクラスタは、req/secが少なく Kafka Brokerで確保するオブジェクトの数や容量も少ない Young GCの実行頻度が少ない Old領域内の使用容量が Mixed GC発生閾値まで上昇しない Old領域使用量 $ cat kafkaServer-gc.log | grep young … 16:49:46.896 … [GC pause (G1 Evacuation Pause) (young), … 16:51:35.529 … [GC pause (GCLocker Initiated GC) (young), … 16:53:23.188 … [GC pause (G1 Evacuation Pause) (young), … 16:55:11.849 … [GC pause (G1 Evacuation Pause) (young), … 16:56:59.696 … [GC pause (G1 Evacuation Pause) (young), … 数「分」おき Mixed GCが発生する前にFDの数が上限に達する
  24. 24. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. JVMのGCを起こさせることで解決 GCが発生するよう設定変更 問題のクラスタでJVM起動オプション `-XX:InitiatingHeapOccupancyPercent`の値を変更する(小さくする) ことでGCを発生しやすくするように変更 問題のクラスタが掴んでいるFile Descriptorの解放に成功 → 解決 24 Mixed GC発生
  25. 25. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 参考 KafkaのGCに長時間を要する問題(修正済み) (https://issues.apache.org/jira/browse/KAFKA-4614) 上記issueでは forceUnmap() を実行することで 参照先がなくなったら強制的に解放して解決 →結果としてFDも強制的に解放されるように Kafka本体で先行してGCに関する問題が指摘 25 チームではissue適用前のKafkaを一部で運用しているため GCの閾値チューニングで解放を実行
  26. 26. Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. まとめ 26 • メッセージの流量や性質に起因するパフォーマンス低下も 存在するため、日頃から設定や構成だけではなく 「どのようにデータを流しているか」も 確認しておくことが重要 • アプリケーションレベルだけでは原因が見つからない場合も あるため、JVM,OSやネットワークなど多くのレイヤの 知識や経験を活用することが解決への近道

×