More Related Content
Similar to ログ解析基盤におけるストリーム処理パイプラインについて (20)
More from cyberagent (20)
ログ解析基盤におけるストリーム処理パイプラインについて
- 2. 自己紹介
● 名前
○ 斎藤貴文
● 所属
○ 株式会社サイバーエージェント秋葉原ラボ
● 担当案件
○ データ転送管理基盤開発・運用
○ 効果計測ツール開発・運用
○ アクセス解析システム開発・運用
○ ステートフルストリーム処理基盤開発
○ ストリーム処理・データフローについて色々やっていたり
2
- 3. はじめに
3
● 今回の発表内容は初心者~中級者向けです
○ 実装の具体的な話はあまりしません
● このスライドにはOSSがいくつか出てきますが、
OSS固有の話はしません
○ 皆さん馴染みのOSSに脳内変換して問題ございません
■ Flume → Fluentd, Logstash
■ Kafka → Kinesis Stream, Google Cloud Pub/Sub, Palser
■ Hive → Pig, BigQuery, Redshift, Presto, Impala
● CADEDAの発表から加筆修正しています
- 4. 目次
● 背景
○ ログ解析基盤Patriotについて
○ Patriotにおけるストリーム処理
● ストリーム処理パイプライン
○ ストリーム処理パイプラインの変遷
○ ストリーム処理パイプラインにおける遅延ログ問題
● 現在の取り組み
○ ストリーム処理
○ ストリーム処理以外
4
- 5. 目次
● 背景
○ ログ解析基盤Patriotについて
○ Patriotにおけるストリーム処理
● ストリーム処理パイプライン
○ ストリーム処理パイプラインの変遷
○ ストリーム処理パイプラインにおける遅延ログ問題
● 現在の取り組み
○ ストリーム処理
○ ストリーム処理以外
5
- 6. Patriotについて
● メディアサービスのデータ解析基盤
○ OSSベースのデータ解析基盤
■ HDFS, YARN, Hive, Flume, Presto, Spark, HBase, etc.
○ 内製化したパッケージを利用
● 過去の発表
○ 内製パッケージによるHadoopデータ解析基盤の構築と運用
○ 最新版Hadoopクラスタを運用して得られたもの
○ Presto on YARNの導入・運用
○ サイバージェント 秋葉原ラボのHBase 活用事例
■ PatriotにおけるHBaseの利用事例を紹介
6
- 9. 目次
● 背景
○ ログ解析基盤Patriotについて
○ Patriotにおけるストリーム処理
● ストリーム処理パイプライン
○ ストリーム処理パイプラインの変遷
○ ストリーム処理パイプラインにおける遅延ログ問題
● 現在の取り組み
○ ストリーム処理
○ ストリーム処理以外の取り組み
9
- 10. Apache Flumeの導入(2012~)
● Apache Flume
○ ストリーミングでイベントを転送先にPushするミドルウェア
● Patriotのストリーム処理パイプライン
○ Webサーバに常駐するエージェントがログの追記毎にログを転送
○ Aggregatorと呼ばれるFlumeサーバに集約し処理系に転送
○ Aggregatorをつなげることでパイプラインを構築
■ Patriot以外の社内処理基盤などに転送
処理系A
10
Aggragator
Aggragator
処理系B
- 13. ● さらなるパイプラインの拡大
○ Zeroの登場などストリーム処理のニーズ増加
○ パブリッククラウドへの転送
● Flume(Push型転送)の問題が露呈
○ Back Pressure問題
■ Flume Aggregatorの処理が詰まると転送元のAggregatorも転送不能
■ パイプラインが大きくなるとそれだけ影響範囲が拡大
○ 転送先が更に増え管理コスト増加
転送管理システム導入後
転送できなくなるので
処理が詰まる
13
- 14. Apache Kafkaの導入(2016~)
● Apache Kafka
○ 分散Pub/Subシステム
● 転送先で処理が詰まっても転送元には影響は無い
○ Kafkaにデータが貯まるだけ
● 転送元で転送先の管理不要
○ 転送先が必要なデータを取捨選択可能
転送先
必要なデータストリームを
転送先で選択可能
処理系が詰まっても転送
14
- 16. 目次
● 背景
○ ログ解析基盤Patriotについて
○ Patriotにおけるストリーム処理
● ストリーム処理パイプライン
○ ストリーム処理パイプラインの変遷
○ ストリーム処理パイプラインにおける遅延ログ問題
● 現在の取り組み
○ ストリーム処理
○ ストリーム処理以外の取り組み
16
- 23. 解決策:DataFlow Model*の導入
● DataFlow Modelを参考にデータの選定ルールを決定
○ ログの発生時刻だけでなくwatermark(到着時刻の最新値)を
基準に入力データの範囲と処理開始時刻を決定
● watermarkを導入することで集計の冪等性を実現し
実行タイミングを決定
○ 入力データの範囲は発生時刻とwatermarkによって決定
■ watermarkよりも後に到着したログは無視することで
処理のタイミングを問わず常に同じ結果を算出可能
○ watermarkが規定の時刻に到達した時点で処理を開始
23* [The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing Akidau et al.,2015]
到着時刻に関係しないので
watermarkには影響しない
遅延によって
watermarkに影響が及ぶ
- 25. 目次
● 背景
○ ログ解析基盤Patriotについて
○ Patriotにおけるストリーム処理
● ストリーム処理パイプライン
○ ストリーム処理パイプラインの変遷
○ ストリーム処理パイプラインにおける遅延ログ問題
● 現在の取り組み
○ ストリーム処理
○ ストリーム処理以外の取り組み
25
- 27. ストリーム処理以外の取り組み
● Zeppelin
○ Sparkなど分散処理環境へのアクセシビリティ向上
○ 解析方法・結果の共有を容易に
● Kudu
○ Fast Data処理向けに試験的に導入中
● Hadoopクラスタ管理ツールの開発
○ 各プロセスの開始・停止、Rolling Restart/Upgrade
○ Zookeeper経由でGitと連携し設定変更など
● バッチ系データフローのオープン化
○ 誰でも自由にシステム横断してバッチ処理のデータフロー管理が可能
○ 機械学習エンジニア・データ活用エンジニアの利用を想定
27