Apache Kafkaによるログ転送とパフォーマンスチューニング - Bonfire Backend #2 -

Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.
2018年12月4日
ヤフー株式会社
データ＆サイエンスソリューション統括本部データプラットフォーム本部デリバリー部パイプライン
橘拓馬
Apache Kafkaによるログ転送と
パフォーマンスチューニング

自己紹介
橘拓馬
2018年度新卒
• 8月からパイプラインチームに
配属され、Apache Kafkaを扱い始める
IoT周りが好き
2

目次
3
1. はじめに
2. What is Kafka
3. パフォーマンス改善の実例
4. まとめ

はじめに
ヤフーは多種多様なサービスを抱え、
多数のユーザ様に利用していただいている
デイリーユニークブラウザ数(FY17)
平均9053万ブラウザ
アプリ合算デイリーアクティブユーザ数(FY17)
平均4249万人
より良いサービスを提供するために、
各サービスから生み出される大量のデータを横断的に活用
※各種指標はhttps://about.yahoo.co.jp/ir/jp/archives/data/より引用
運営サービス数
100超
4

より良いサービスを提供するために、
各サービスから生み出される大量のデータを横断的に活用
はじめに
ヤフーは多種多様なサービスを抱え、
多数のユーザ様に利用していただいている
デイリーユニークブラウザ数(FY17)
平均9053万ブラウザ
アプリ合算デイリーアクティブユーザ数(FY17)
平均4249万人
※各種指標はhttps://about.yahoo.co.jp/ir/jp/archives/data/より引用
運営サービス数
100超
5
例：複数のサービスからユーザのWeb行動ログを収集、
最もユーザが興味の持ちそうな関連コンテンツをレコメンド
サービスA
サービスB
サービスC
あなたへの
オススメ
… 行動を分析

大量のデータ活用の課題
誰もが横断的に活用するためには、各サービス/サーバに
保存されている大量のログデータを
１つの分析基盤に集約するのが効率的…
大量のサーバとデータたち
データをサーバから
取得するだけで超大変…
6

各サーバに散らばっているデータを連携したり、
分析基盤に転送するためにメッセージングシステムが必要
大量のサーバとデータたち分析基盤メッセージングシステム
サーバ間の
データ転送を担う
7

パイプラインチームでは、Apache Kafkaを
メッセージングシステムとして採用
大量のサーバとデータたち分析基盤Apache Kafka
8

予備知識
pub/sub型メッセージングシステム
複数の送信者が送信したデータを中継者(Broker)が
全て受け取り、データを利用したい複数の受信者が中継者から
購読することで多対多のメッセージングを実現するシステム
Publisher SubscriberBroker
9

予備知識
pub/sub型メッセージングシステム
Brokerという中継者を置くことでスケールアウトに伴う煩雑さを
撤廃、複数のサーバ間でデータを簡単に利活用できるように
最終的な受け手を気にすることなく
送信（Publish）
利用したい項目のデータのみ
購読（Subscribe）
10
Publisher SubscriberBroker

What is Kafka①
: LinkedInで開発された
pub/sub型分散メッセージングシステム
Producer
Consumer
最終的な受け手を気にすることなく
送信（Produce）
→受信者の増減による設定変更は無
利用したい項目のデータのみ
購読（Consume）
→利用データの変更は項目の設定のみ
Apache Kafka
（Broker Cluster） 11

What is Kafka②
• Brokerは複数のサーバを使用して分散システムとして稼働させることが可能
• メッセージの処理単位を複数に分割できる仕組みを持つため
Consumer側のアプリケーションも分散処理が可能
• 可用性・スケールアウト性を確保
• メッセージを自分のDiskへ書き込みつつ
他サーバへもレプリケーションすることで、データの永続性を担保
• 何らかの理由でConsumerの処理が一時停止してもリトライが可能
• Apache Foundationが提供するデータ分析エンジンとの親和性が高い
• Apache Hadoop, Apache Spark, Apache Storm, Apache Flink etc...
12
Kafkaの特徴

Kafkaとパフォーマンス
分散メッセージングシステムは
パフォーマンスに影響を与える要素が非常に広範囲
→思ったような性能が出ない場合、確認箇所が多い
• アーキテクチャそのもの
(Producer-Broker-Consumerの繋ぎ方が悪い？)
• Kafka実装
(コードのどこかの処理が重い？)
• 各種設定
(要件と相性の悪い設定が記述されている？)
• JVM
(JVMに負荷がかかる設定になっている？)
• OS（特にI/O周り）
(ファイルシステムが悪い？)
• ネットワーク
(帯域が足りない？遅延が多い？)
• ハードウェア
(性能不足？)
実際に社内で遭遇した事例を
紹介します
13

Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.
「一部だけ」リクエストを
捌ききれない

発生状況
一部のKafka Broker Clusterだけ
Request Handler がリクエストを捌ききれない
Kafka Broker (一部省略)
R/W
Produce Request
Consume Request
Request Handler
File
System
Producer / Consumerからの
リクエストを基に実際にFile Systemに
読み書きするスレッド
15
(スレッドのアイドル率が低い)

発生状況
Kafka Broker (一部省略)
R/W
Produce Request
Consume Request
Request Handler
File
System
16
一部のKafka Broker Clusterだけ
Request Handler がリクエストを捌ききれない
(スレッドのアイドル率が低い)
多くのクラスタでのアイドル率は90%以上
アイドル率30%を割るクラスタが発生

原因調査
各種設定の調査
負荷の高いクラスタと低いクラスタの設定の違いを確認
• Kafka Broker
• JVM
• OS
• ネットワーク
→パフォーマンスに影響する設定の違いはない
Brokerの動作ログを確認した結果、以下の動作の違いを発見
１回のリクエストで
12メッセージ受信
通常のクラスタ問題のクラスタ
17
リクエスト１回で受け取るメッセージの個数が違う
１回のリクエストで
1メッセージ受信

Kafkaのバッチングについて
18
Kafkaには１回の送信に複数のメッセージをまとめて送信する
バッチング機能がある
→ 指定メッセージ数貯まるまで or 一定時間経過まで
メッセージを溜め込む
バッチングの大きさ(BatchSize)を大きく
→処理効率高、遅延は増大
今回はKafka ProducerのBatchSize設定も全て一緒

Kafkaのバッチングについて
19
Kafkaには１回の送信に複数のメッセージをまとめて送信する
バッチング機能がある
→ 指定メッセージ数貯まるまで or 一定時間経過まで
メッセージを溜め込む
バッチングの大きさ(BatchSize)を大きく
→処理効率高、遅延は増大
時間内にメッセージが殆ど溜まっていない！！！
今回はKafka ProducerのBatchSize設定も全て一緒

答えはProducerに
１台あたりの秒間メッセージ数が少ないのにも関わらずPartition数が多い
Producer (複数台) Broker
…
…
Partitioner
MessageMessage
Batch
Producerはラウンドロビンで全ての
Partitionにメッセージを振り分け
指定時間内に
溜まるBatchSizeが1
Request Handlerが
高負荷に
20
並列処理するための単位

パラメータ調整/構成変更で対処？
Producerの数を減らせば良い？
• ビジネス要件で不可能
• サービスのサーバ群が高可用性とパフォーマンスの両立を求めており、
Producerの台数が非常に多い。
• 1台あたりの流量は少なく、台数が多い構成を変更できない
Partitionを減らせばいい？
• Kafkaの機能制約
• Partitionを減らす操作はKafkaでは簡単にできない
タイムアウトを長くすればいい？
• ビジネス要件で不可能
• 遅延が長くなり、転送のリアルタイム性が犠牲になる
21

送信先partitionを固定 (keyed message)
Producer
Broker
…
…
Partitioner
Keyed Message
Keyed Message
Batch
ProducerごとにKeyを設定
秒間メッセージ数が少ないのに多くのPartitionに分散していることが問題
同一のProducerから送信するメッセージは全て同じPartitionに振り分けられるように
同じKeyを持つデータは
全て同じPartitionに振り分けられる
一定時間内に溜まるBatchSizeを大きくできる！ → 無事解決
22
メッセージにKeyを付与できる

まとめ
分散メッセージングシステムは
パフォーマンスに影響する要素が多く、
原因特定や切り分けの難易度が高い
• 動作ログと設定を眺めながら、
「この設定でこんな動きになるっけ？」
という違和感を嗅ぎ分けることが解決への近道
• メッセージの流量や性質に起因するパフォーマンス低下も
存在するため、日頃から設定や構成だけではなく
「どのようにデータを流しているか」も確認しておくことも重要
23

Apache Kafkaによるログ転送とパフォーマンスチューニング - Bonfire Backend #2 -

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Apache Kafkaによるログ転送とパフォーマンスチューニング - Bonfire Backend #2 -

Ähnlich wie Apache Kafkaによるログ転送とパフォーマンスチューニング - Bonfire Backend #2 - (20)

Mehr von Yahoo!デベロッパーネットワーク

Mehr von Yahoo!デベロッパーネットワーク (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

Apache Kafkaによるログ転送とパフォーマンスチューニング - Bonfire Backend #2 -