759 Views
December 04, 18
スライド概要
Bonfire Backend #2 ( https://yj-meetup.connpass.com/event/107235/ ) での発表資料です。
2023年10月からSpeaker Deckに移行しました。最新情報はこちらをご覧ください。 https://speakerdeck.com/lycorptech_jp
Apache Kafkaによるログ転送と パフォーマンスチューニング 2018年12月4日 ヤフー株式会社 データ&サイエンスソリューション統括本部 データプラットフォーム本部デリバリー部パイプライン Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 橘 拓馬
自己紹介 橘 拓馬 2018年度新卒 • 8月からパイプラインチームに 配属され、Apache Kafkaを扱い始める IoT周りが好き Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 2
目次 1. はじめに 2. What is Kafka 3. パフォーマンス改善の実例 4. まとめ Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 3
はじめに ヤフーは多種多様なサービスを抱え、 多数のユーザ様に利用していただいている デイリーユニークブラウザ数(FY17) 運営サービス数 100超 9053万ブラウザ 平均 アプリ合算デイリーアクティブユーザ数(FY17) 平均 4249万人 より良いサービスを提供するために、 各サービスから生み出される大量のデータを横断的に活用 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. ※各種指標はhttps://about.yahoo.co.jp/ir/jp/archives/data/より引用 4
はじめに ヤフーは多種多様なサービスを抱え、 例:複数のサービスからユーザのWeb行動ログを収集、 多数のユーザ様に利用していただいている 最もユーザが興味の持ちそうな関連コンテンツをレコメンド デイリーユニークブラウザ数(FY17) あなたへの サービスA オススメ 平均 ブラウザ 運営サービス数 サービスB 100超 サービスC 9053万 アプリ合算デイリーアクティブユーザ数(FY17) … 行動を分析 平均 4249万人 より良いサービスを提供するために、 各サービスから生み出される大量のデータを横断的に活用 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. ※各種指標はhttps://about.yahoo.co.jp/ir/jp/archives/data/より引用 5
大量のデータ活用の課題 誰もが横断的に活用するためには、各サービス/サーバに 保存されている大量のログデータを 1つの分析基盤に集約するのが効率的… データをサーバから 取得するだけで超大変… 大量のサーバとデータたち Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 6
大量のデータ活用の課題 各サーバに散らばっているデータを連携したり、 分析基盤に転送するためにメッセージングシステムが必要 サーバ間の データ転送を担う 大量のサーバとデータたち Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. メッセージングシステム 分析基盤 7
大量のデータ活用の課題 パイプラインチームでは、Apache Kafkaを メッセージングシステムとして採用 大量のサーバとデータたち Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. Apache Kafka 分析基盤 8
予備知識 pub/sub型メッセージングシステム 複数の送信者が送信したデータを中継者(Broker)が 全て受け取り、データを利用したい複数の受信者が中継者から 購読することで多対多のメッセージングを実現するシステム Publisher Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. Broker Subscriber 9
予備知識 pub/sub型メッセージングシステム Brokerという中継者を置くことでスケールアウトに伴う煩雑さを 撤廃、複数のサーバ間でデータを簡単に利活用できるように 利用したい項目のデータのみ 購読(Subscribe) 最終的な受け手を気にすることなく 送信(Publish) Publisher Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. Broker Subscriber 10
What is Kafka① : LinkedInで開発された pub/sub型分散メッセージングシステム 最終的な受け手を気にすることなく 送信(Produce) →受信者の増減による設定変更は無 Producer Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. Apache Kafka (Broker Cluster) 利用したい項目のデータのみ 購読(Consume) →利用データの変更は項目の設定のみ Consumer 11
What is Kafka② Kafkaの特徴 • Brokerは複数のサーバを使用して分散システムとして稼働させることが可能 • メッセージの処理単位を複数に分割できる仕組みを持つため Consumer側のアプリケーションも分散処理が可能 • 可用性・スケールアウト性を確保 • メッセージを自分のDiskへ書き込みつつ 他サーバへもレプリケーションすることで、データの永続性を担保 • 何らかの理由でConsumerの処理が一時停止してもリトライが可能 • Apache Foundationが提供するデータ分析エンジンとの親和性が高い • Apache Hadoop, Apache Spark, Apache Storm, Apache Flink etc... Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 12
Kafkaとパフォーマンス 分散メッセージングシステムは パフォーマンスに影響を与える要素が非常に広範囲 →思ったような性能が出ない場合、確認箇所が多い • アーキテクチャそのもの • OS(特にI/O周り) • Kafka実装 • ネットワーク • 各種設定 • ハードウェア (Producer-Broker-Consumerの繋ぎ方が悪い?) (コードのどこかの処理が重い?) (要件と相性の悪い設定が記述されている?) • JVM (JVMに負荷がかかる設定になっている?) Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. (ファイルシステムが悪い?) (帯域が足りない?遅延が多い?) (性能不足?) 実際に社内で遭遇した事例を 紹介します 13
「一部だけ」リクエストを 捌ききれない Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.
発生状況 一部のKafka Broker Clusterだけ Request Handler がリクエストを捌ききれない Producer / Consumerからの リクエストを基に実際にFile Systemに 読み書きするスレッド (スレッドのアイドル率が低い) R/W Produce Request Consume Request Request Handler Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. Kafka Broker File System (一部省略) 15
発生状況 一部のKafka Broker Clusterだけ Request Handler がリクエストを捌ききれない (スレッドのアイドル率が低い) 多くのクラスタでのアイドル率は90%以上 アイドル率30%を割るクラスタが発生 R/W Produce Request Consume Request Request Handler Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. Kafka Broker File System (一部省略) 16
原因調査 各種設定の調査 負荷の高いクラスタと低いクラスタの設定の違いを確認 • Kafka Broker • OS • JVM • ネットワーク →パフォーマンスに影響する設定の違いはない Brokerの動作ログを確認した結果、以下の動作の違いを発見 1回のリクエストで 12メッセージ受信 1回のリクエストで 1メッセージ受信 通常のクラスタ 問題のクラスタ リクエスト1回で受け取るメッセージの個数が違う Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 17
Kafkaのバッチングについて Kafkaには1回の送信に複数のメッセージをまとめて送信する バッチング機能がある → 指定メッセージ数貯まるまで or 一定時間経過まで メッセージを溜め込む バッチングの大きさ(BatchSize)を大きく →処理効率高、遅延は増大 今回はKafka ProducerのBatchSize設定も全て一緒 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 18
Kafkaのバッチングについて Kafkaには1回の送信に複数のメッセージをまとめて送信する バッチング機能がある → 指定メッセージ数貯まるまで or 一定時間経過まで メッセージを溜め込む 時間内にメッセージが殆ど溜まっていない!!! バッチングの大きさ(BatchSize)を大きく →処理効率高、遅延は増大 今回はKafka ProducerのBatchSize設定も全て一緒 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 19
答えはProducerに 1台あたりの秒間メッセージ数が少ないのにも関わらずPartition数が多い 並列処理するための単位 Producerはラウンドロビンで全ての Partitionにメッセージを振り分け Partitioner Message … … Message Request Handlerが 高負荷に 指定時間内に Batch Producer (複数台) Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 溜まるBatchSizeが1 Broker 20
パラメータ調整/構成変更で対処? Producerの数を減らせば良い? • ビジネス要件で不可能 • • サービスのサーバ群が高可用性とパフォーマンスの両立を求めており、 Producerの台数が非常に多い。 1台あたりの流量は少なく、台数が多い構成を変更できない Partitionを減らせばいい? • Kafkaの機能制約 • Partitionを減らす操作はKafkaでは簡単にできない タイムアウトを長くすればいい? • ビジネス要件で不可能 • 遅延が長くなり、転送のリアルタイム性が犠牲になる Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 21
送信先partitionを固定 (keyed message) ProducerごとにKeyを設定 秒間メッセージ数が少ないのに多くのPartitionに分散していることが問題 同一のProducerから送信するメッセージは全て同じPartitionに振り分けられるように メッセージにKeyを付与できる Partitioner 同じKeyを持つデータは 全て同じPartitionに振り分けられる … … Keyed Message Keyed Message Batch Producer Broker 一定時間内に溜まるBatchSizeを大きくできる! → 無事解決 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 22
まとめ 分散メッセージングシステムは パフォーマンスに影響する要素が多く、 原因特定や切り分けの難易度が高い • 動作ログと設定を眺めながら、 「この設定でこんな動きになるっけ?」 という違和感を嗅ぎ分けることが解決への近道 • メッセージの流量や性質に起因するパフォーマンス低下も 存在するため、日頃から設定や構成だけではなく 「どのようにデータを流しているか」も確認しておくことも重要 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 23