![解決策: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に影響が及ぶ](https://image.slidesharecdn.com/cadeda5streamprocessingpipeline-180717005637/85/-23-320.jpg)
![ストリーム処理に関する取り組み
● ステートフルストリーム処理基盤Phalanx
○ ストリーム処理でステートフルデータの変更を実現する際に
CRDT*を利用することで更新操作を簡略的に表現可能
○ DEIM 2018で発表
● ストリーム処理パイプライン管理基盤
○ パイプラインに必要な簡単な処理だけを提供
■ ログの加工、ログの選択
○ 誰でも容易にパイプライン処理の追加を可能にするのが目的
* [Conflict-free Replicated Data TypesShapiro et al.,2011]
26](https://image.slidesharecdn.com/cadeda5streamprocessingpipeline-180717005637/85/-26-320.jpg)
ログ解析基盘におけるストリーム処理パイプラインについて
- 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
- 8. Patriotにおけるストリーム処理 ● ログの転送 ○ サービスにおけるユーザの行動ログを適切な場所に転送 ● ログのフィルタリング ○ ログスキーマに則ったバリデーション等 ● ログの加工 ○ Online Joiner等 ● リアルタイム集計 ○ 秋葉原ラボのプロダクトとしてはZeroが担当 8
- 9. 目次 ● 背景 ○ ログ解析基盤Patriotについて ○ Patriotにおけるストリーム処理 ● ストリーム処理パイプライン ○ ストリーム処理パイプラインの変遷 ○ ストリーム処理パイプラインにおける遅延ログ問題 ● 現在の取り組み ○ ストリーム処理 ○ ストリーム処理以外の取り組み 9
- 10. Apache Flumeの導入(2012~) ● Apache Flume ○ ストリーミングでイベントを転送先にPushするミドルウェア ● Patriotのストリーム処理パイプライン ○ Webサーバに常駐するエージェントがログの追記毎にログを転送 ○ Aggregatorと呼ばれるFlumeサーバに集約し処理系に転送 ○ Aggregatorをつなげることでパイプラインを構築 ■ Patriot以外の社内処理基盤などに転送 処理系A 10 Aggragator Aggragator 処理系B
- 11. Apache Flume導入直後の課題 ● Flumeの転送先増加に伴うパイプラインの硬直化 ○ Aggregatorに様々な条件の転送設定を追加 ○ 転送設定が複雑化し転送状況の把握や転送の変更が困難 ○ 扱える人間が限られて属人化 転送先 Aggragator 転送先 転送先 11
- 12. 転送管理システムの開発(2014~) ● ログの転送時にDBの転送設定を参照 ● オンラインで転送設定を変更可能 ○ 管理画面から登録済み転送先を変更可能 ○ フィルタリング処理も可能 転送先 Aggragator 転送先 転送先 DB 12
- 13. ● さらなるパイプラインの拡大 ○ Zeroの登場などストリーム処理のニーズ増加 ○ パブリッククラウドへの転送 ● Flume(Push型転送)の問題が露呈 ○ Back Pressure問題 ■ Flume Aggregatorの処理が詰まると転送元のAggregatorも転送不能 ■ パイプラインが大きくなるとそれだけ影響範囲が拡大 ○ 転送先が更に増え管理コスト増加 転送管理システム導入後 転送できなくなるので 処理が詰まる 13
- 14. Apache Kafkaの導入(2016~) ● Apache Kafka ○ 分散Pub/Subシステム ● 転送先で処理が詰まっても転送元には影響は無い ○ Kafkaにデータが貯まるだけ ● 転送元で転送先の管理不要 ○ 転送先が必要なデータを取捨選択可能 転送先 必要なデータストリームを 転送先で選択可能 処理系が詰まっても転送 14
- 15. 現在 ● Apache Kafkaをデータハブとして活用 ○ データ転送中に容易にデータの加工が可能 ● ストリーム転送パイプラインは更に拡大 ○ 課題も増え戦いは続く。。。 転送先 15 Kafkaを経由してログの変換を実現
- 16. 目次 ● 背景 ○ ログ解析基盤Patriotについて ○ Patriotにおけるストリーム処理 ● ストリーム処理パイプライン ○ ストリーム処理パイプラインの変遷 ○ ストリーム処理パイプラインにおける遅延ログ問題 ● 現在の取り組み ○ ストリーム処理 ○ ストリーム処理以外の取り組み 16
- 17. 遅延ログ問題のあらすじ 17 ● ネイティブアプリの登場によってそれまで起こらなかった問題が発生 ○ 常に遅延したログが処理系に到着する状況の発生 ○ 集計毎に入力データが変動し処理の冪等性を担保するのが困難 ○ 2015年ごろ ● 問題の詳細と解決策について紹介 処理系Webサーバ ストリーム処理 パイプライン バッチ処理で集計を実行 FlumeやKafkaなど転送を担う コンポーネントで構成 ログを受け取るサーバ パイプラインの入り口
- 18. ● ユーザの行動はWebサーバで処理されるためログはWebサーバで発生 ● 処理系は必要なログが全て到達してからバッチ処理を実行 ○ 負荷高騰等によってパイプラインで遅延が発生することもある ○ パイプラインは管理下にあるので 遅延が解消されるまで待ってからバッチ処理を実行 処理系Webサーバ ネイティブアプリの登場以前 Webサービス ストリーム処理 パイプライン 18
- 20. 処理系Webサーバ ストリーム処理 パイプライン ● 集計への影響 ○ ネイティブアプリのログの転送は管理できないので 常に遅延したログが届くという状況 ○ 遅延したログが後で届いた場合、集計の結果が変動 ネイティブアプリの登場 ((((( 20 00:00 ログ発生 処理系 01:30 発火 01:00集計の0時台のカウントは0 02:00集計の0時台のカウントは1 ① ② ③ ④
- 21. 遅延ログによって生じる問題 21 ● 集計に冪等性が保てない ○ バッチ処理の集計とは一度だけではない ■ パイプラインで遅延が生じていたとき ■ ログをバックアップから再取り込みするとき ○ 冪等性を確保できないということは正確な集計ができないことと同義 ● 実行タイミングを決めることができない ○ 遅延ログが常に届くので集計時刻を遅らせた方が集計値は大きくなる ○ しかしログを待ち続けているといつまでも集計を開始できない → そのため集計の冪等性を保ちつつ 実行タイミングを適切に決定するための仕組みが必要
- 22. 解決策:２つの時刻の導入 ● ログの発生時刻だけではどこで遅延したのか判別不可能 ○ 管理可能な遅延と管理不可能な遅延が混在 ● 発生時刻に加えてパイプラインへの到着時刻をログに付与 ○ Webサービスの場合、発生時刻と到着時刻は等しい ○ ネイティブアプリのログはWebサーバに到着した時点の時刻を付与 ネイティブアプリ 発生時刻 ストリーム処理 パイプライン Webサービス 発生時刻=到着時 刻 到着時刻 22
- 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に影響が及ぶ
- 24. 解決策:実装編 ● ログフォーマットの統一 ○ 時刻の配置やネイティブアプリとWebサーバのログの識別等 ○ フォーマットについては過去にデータの品質管理で紹介 ● 到着時刻の付与 ○ Webサーバでログに変換するときに付与 ○ Flumeの転送中に付与 ■ Interceptorを追加するだけで実現 ● データの選定ルール ○ Hiveのクエリで実現 24 発生時刻(event_time)の範囲 watermarkの範囲 到着時刻+1時間まで許容
- 25. 目次 ● 背景 ○ ログ解析基盤Patriotについて ○ Patriotにおけるストリーム処理 ● ストリーム処理パイプライン ○ ストリーム処理パイプラインの変遷 ○ ストリーム処理パイプラインにおける遅延ログ問題 ● 現在の取り組み ○ ストリーム処理 ○ ストリーム処理以外の取り組み 25
- 26. ストリーム処理に関する取り組み ● ステートフルストリーム処理基盤Phalanx ○ ストリーム処理でステートフルデータの変更を実現する際に CRDT*を利用することで更新操作を簡略的に表現可能 ○ DEIM 2018で発表 ● ストリーム処理パイプライン管理基盤 ○ パイプラインに必要な簡単な処理だけを提供 ■ ログの加工、ログの選択 ○ 誰でも容易にパイプライン処理の追加を可能にするのが目的 * [Conflict-free Replicated Data TypesShapiro et al.,2011] 26
- 27. ストリーム処理以外の取り組み ● Zeppelin ○ Sparkなど分散処理環境へのアクセシビリティ向上 ○ 解析方法?結果の共有を容易に ● Kudu ○ Fast Data処理向けに試験的に導入中 ● Hadoopクラスタ管理ツールの開発 ○ 各プロセスの開始?停止、Rolling Restart/Upgrade ○ Zookeeper経由でGitと連携し設定変更など ● バッチ系データフローのオープン化 ○ 誰でも自由にシステム横断してバッチ処理のデータフロー管理が可能 ○ 機械学習エンジニア?データ活用エンジニアの利用を想定 27
- 28. 終 28