ストリーム処理プラットフォームにおけるkafka導入事例 #kafkajp

ストリーム処理プラットフォームにおけるKafka導入事例

http://www.yahoo.co.jp/

ヤフー株式会社

データ&サイエンスソリューション統括本部データプラットフォーム本部

森谷大輔

自己紹介

• 氏名

• 森谷大輔

• 業務

• 社内ストリーム処理PFの構築保守運用

• ストリームなアプリケーションの開発

• Kafka歴

• 2012年9月〜now（3.5年くらい）

• Special Thanks

• 梁浩軒

Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 2

Agenda

• Kafka導入経緯

• 構成、周辺OSS、機能

• ユースケース

• 反省点、課題と感じているところ


Agenda






Yahoo! JAPAN のストリーム処理プラットフォーム

• 様々なデータソースをリアルタイムに各サービスに提供、サービスの価値に貢献


アプリログ

ソーシャルログ

Weblog

IoT

Photo by insidetwit https://www.flickr.com/photos/insidetwit/

企画のきっかけ

• 今この瞬間が最も意味を持つ、鮮度が重要なデータ

• 貯めて結果を出す、では遅いケースがある

• やってきたデータを逐次処理して、結果を逐次返すプラットフォームを作ろう！


異常検知

オンライン機械学習

ウィンドウ集計

ETL

ユースケースのパターン

Kafka, Stormの導入

• 2012年度初頭、開発着手

• Kafka, Storm 採用

• (2012年9月) わい、チームに配属される

• 「入ったらもう Kafka だった」

• 「Kafka ってなんだ」


Kafka 採用理由

• LinkedInで実績がある

• Stormと相性が良い

• 高可用性

• Hadoopとも連携できる

• とりあえずデータを投げればサービスをまたがって再利用可能

• consumer group と offset という素晴らしい概念


Storm 採用理由

• 他OSSと比較してコミュニティが活発だった

• Twitterで実績がある

• 高可用性

• at least once


http://storm.apache.org/

プラットフォームの構築

• 載せるアプリケーションの開発と並行しながら構築

• 当時Web上にはほとんど日本語のドキュメントがなかった• 知りうる限り一つしかなかった

• 2012年上半期開発完了、本番稼働


Agenda






大まかな構成と周辺OSS


DistributedMessage Queue

DistributedReal-time Computation

SearchEngine

Service API

Packet

• Kafkaを流れるデータは全て Packet という共通フォーマットでMessagePack形式でシリアライズされている

• 送信メッセージにメタ情報を付与

• シリアライズ時（≒ produce時）のタイムスタンプ等

• メッセージは文字列かバイト列

• PFが提供しているライブラリを使えばユーザは基本的にはシリアライズ形式を意識する必要がないようにしている


ストリーム処理結果の格納オプション

• 実績

• Cassandra, MySQL, 内製検索エンジン

• Kafkaの時点でデータの重複は発生するので、アプリケーションに重複を除去する機構を入れるか、そもそも若干の重複は許容されるユースケースでなければならない

• その点KVSは相性が良い


BatchConsumer

• リアルタイムで読み進めているconsumer groupとは別に、過去分を同じように処理したいという要望が結構ある

• 「昨日の18時から20時までのデータ、offsetは普通に読み進めちゃったんだけど検索エンジンに反映できなかったからやり直したい」

• ユーザからの要望は基本時間指定となる

• ストリームアプリケーションのロジックをそのまま再利用したい


BatchConsumer

• BatchConsumerなる抽象クラスを用意

• ユーザはBatchConsumerを継承して処理内容を実装したクラスを作る

• 引数にZooKeeperとtopicと開始・終了のタイムスタンプを指定してBatchConsumeを発火

• オプションで流量調整やスレッド数等が指定できる


BatchConsumer

• シンプルなSimpleConsumerを使って実装している• ※人間にとってシンプルとは言ってない

• 特定のpartitionについてタイムスタンプを指定すると大雑把なオフセットが返ってくるgetOffsetsBeforeメソッド

• その時間のメッセージが属するセグメントの、一個前の先頭のオフセットを返す謎仕様（少なくとも0.8.1.1までは）

• 余計なセグメントを読むと時間がかかるため頑張って回避している

• 対象メッセージが入っているセグメントが特定できれば後はそのセグメントの最小オフセットからPacketのタイムスタンプが対象時間帯に入るまで読み捨て、時間帯に入ったら処理し、外れた瞬間に処理を終える

• パーティション内のメッセージは時系列順である前提のもとCopyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 17

監視・可視化

• 監視項目

• broker死活

• トピックの流入量（トピックによって敏感度が違う）

• エンドツーエンドのレイテンシ• 定期的にoffset.reset=largestでオフセットをコミットせずにconsumeして計測している

• 様々な変更が入る中で、重要な指標を簡単にチェックするツールが欲しくなった

• Elasticsearch + Kibana 採用

• トピック毎指標を可視化• JMXからログ数等のメトリクス推移

• エンドツーエンドのレイテンシ推移

• 一部重要なトピックは全ログ投入


Agenda






ユースケース：リアルタイム検索


リアルタイム検索の課題

• リアルタイム検索をよりリアルタイムに

• システムを堅牢にしたい

• 新機能の追加を容易にしたい


リアルタイム検索処理内容

• リアルタイム検索用データの解析

• テキスト解析（言語、特徴語など抽出）

• メトリクス（RT、Likeなど）解析

• 機械学習: 感情分析（ポジティブ・ネガティブ）

• 検索エンジン用データに加工

• 500ミリ秒間隔で検索エンジンに投入

• 電車の遅延を早く検知してユーザのスマデバにプッシュ


感情分析について


http://research-lab.yahoo.co.jp/nlp/20140912_post.html

Agenda






Kafka バージョンアップ 0.7系 → 0.8系


素のJavaライブラリ

Java以外のライブラリ

いろ

• producerもconsumerもユーザの自由な方法で繋げるようにしていた

• client 下位互換性無し

• クラスタを2重化して全てのproducer, consumerを書き換えて切り替えた

• 重大な反省点となる

• 「ユーザが不便だと感じない程度に制限」したい

いろな

サービス

監視について思うこと

• 最初は損失も重複も許容

• ビッグデータだしストリームだし

• とはもう言えなくなっている

• 少なくとも検知はしたい

• 現在はproducerの件数とconsumerの件数突き合わせまでできていない

• エンドツーエンドで全トピック全量consumeし続けて突き合わせ、レイテンシチェックするのが一番望ましい

• 少なくともbrokerとしての義務を果たしていると自信を持てるようになる


まとめ

• KafkaとStormをベースにしたストリームデータ利活用プラットフォーム

• Hadoopへ保存

• 共通フォーマットでシリアライズ

• 処理結果の格納オプションとしてCassandra等

• 時間帯を指定して再実行するBatchConsumer

• 指標可視化にはElasticsearchとKibana

• リアルタイム検索ではテキスト解析、機械学習、異常検知で利用


ストリーム処理プラットフォームにおけるkafka導入事例 #kafkajp

Technology