Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ログ監視システムにおける時間ベース遅延の可視化 / Apache Kafka Meetup J...
Search
CyberAgent
PRO
April 09, 2019
Technology
0
2k
ログ監視システムにおける時間ベース遅延の可視化 / Apache Kafka Meetup Japan
4月9日開催
Apache Kafka Meetup Japan
ログ監視システムにおける時間ベース遅延の可視化
秋葉原ラボ:大平哲也
CyberAgent
PRO
April 09, 2019
Tweet
Share
More Decks by CyberAgent
See All by CyberAgent
2025年度 生成AI 実践編
cyberagentdevelopers
PRO
5
380
LLMを用いたメタデータベースレコメンド検証
cyberagentdevelopers
PRO
6
1.9k
CodeAgentとMCPで実現するデータ分析エージェント
cyberagentdevelopers
PRO
1
390
SQL Agentによるタップルのデータ利活用促進
cyberagentdevelopers
PRO
2
530
NAB Show 2025 動画技術関連レポート / NAB Show 2025 Report
cyberagentdevelopers
PRO
1
480
【2025年度新卒技術研修】100分で学ぶ サイバーエージェントのデータベース 活用事例とMySQLパフォーマンス調査
cyberagentdevelopers
PRO
8
12k
【CA.ai #1】未来を切り拓くAIエージェントの可能性
cyberagentdevelopers
PRO
4
310
【CA.ai #1】MCP世界への招待:AIエンジニアが創る次世代エージェント連携の世界
cyberagentdevelopers
PRO
2
260
【CA.ai #1】ABEMA のコンテンツ制作を最適化! 生成 AI × クラウド映像編集システム
cyberagentdevelopers
PRO
0
260
Other Decks in Technology
See All in Technology
『OCI で学ぶクラウドネイティブ 実践 × 理論ガイド』 書籍概要
oracle4engineer
PRO
3
200
【Oracle Cloud ウェビナー】クラウド導入に「専用クラウド」という選択肢、Oracle AlloyとOCI Dedicated Region とは
oracle4engineer
PRO
3
130
能登半島地震で見えた災害対応の課題と組織変革の重要性
ditccsugii
0
470
なぜAWSを活かしきれないのか?技術と組織への処方箋
nrinetcom
PRO
4
700
そのWAFのブロック、どう活かす? サービスを守るための実践的多層防御と思考法 / WAF blocks defense decision
kaminashi
0
160
AIツールでどこまでデザインを忠実に実装できるのか
oikon48
6
3.2k
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
4
460
定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki Takahashi
shift_evolve
PRO
4
360
【Kaigi on Rails 事後勉強会LT】MeはどうしてGirlsに? 私とRubyを繋いだRail(s)
joyfrommasara
0
230
Trust as Infrastructure
bcantrill
1
380
AWS Control Tower に学ぶ! IAM Identity Center 権限設計の第一歩 / IAM Identity Center with Control Tower
y___u
0
100
JAZUG 15周年記念 × JAT「AI Agent開発者必見:"今"のOracle技術で拡張するAzure × OCIの共存アーキテクチャ」
shisyu_gaku
1
160
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
How GitHub (no longer) Works
holman
315
140k
Building an army of robots
kneath
306
46k
Producing Creativity
orderedlist
PRO
347
40k
Statistics for Hackers
jakevdp
799
220k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
The Cost Of JavaScript in 2023
addyosmani
54
9k
Practical Orchestrator
shlominoach
190
11k
Speed Design
sergeychernyshev
32
1.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
19
1.2k
Transcript
ログ監視システムに おける時間ベース遅延の可視化 大平哲也
1. 自己紹介 2. 秋葉原ラボの紹介 3. オフセットを用いた遅延計測の問題点 4. 時間ベース遅延の可視化 5. オフセットの地点のデータ取得の高速化
6. 遅延の可視化 7. まとめ 発表の流れ
大平 哲也 (おおだいら てつや) 内定者期間中に秋葉原ラボでログ遅延監視ツールの開発 今年度入社。只今研修中 最近興味のある分野:ストリーム処理、Dataflow、進化計算 趣味:コーヒー、自転車、電子工作 自己紹介 だいら
@tdaira_
「データを活用」してサービスと会社の発展に寄与する 秋葉原ラボについて
サイバーエージェントで扱うサービス
不正なログをフィルタリングして後続へ流すシステム 許容可能な遅延時間内にフィルタリングを行う必要がある ログの品質管理システム Input topic NG topic OK topic Validator
ログ転送 システム DWH サーチエンジン サイバーエージェントにおけるデータの品質管理について https://www.slideshare.net/cyberagent/cwt2016
KafkaのOffsetの管理 パーティション Offsetによりどこまで各 Consumerが値を読み 取ったかが管理されて いる Offsetの遅延 [Lag] = [最新レコードのOffset]
- [ConsumerのOffset] Consumer Aのラグ [Lag] = 12 - 9 = 3 Consumer Bのラグ [Lag] = 12 - 11 = 1
オフセットはKafkaのコマンドラインツールやkafka-manager等の 監視ツールで確認することができる オフセットの確認作業 Consumerの Offset 最新レコードの Offset Offsetの遅延
古いログがどれくらい溜まっているかわからない ログが溜まる原因を切り分けられない オフセットを用いた遅延計測の問題点 Input topic Validator ログ転送 システム ログの流量が 増えた
Validatorの処理 能力が落ちた
ログの流量増えた場合 18:16 18:20 18:25 18:30 18:16 18:17 18:18 18:19 18:26
18:27 18:29 18:30 18:20 18:22 18:25 流量:大 流量:小 同じ処理速度でも流量が多い場合Lagが広がる CURRENT-OFFSET Lag:3 Lag:10 CURRENT-OFFSET LOG-END-OFFSET LOG-END-OFFSET
Consumerの処理速度が落ちた場合 17:20 17:33 18:10 18:30 17:40 17:55 同一流量 同じ流量でも処理速度が落ちた場合Lagが広がる 17:20
17:33 18:10 18:30 17:40 17:55 処理速度:低 処理速度:高 Lag:3 Lag:5 CURRENT-OFFSET CURRENT-OFFSET LOG-END-OFFSET LOG-END-OFFSET
• 経験則でオフセットの遅延から遅延時刻を推定 • メッセージを手動で取得し、タイムスタンプを一つずつ確認 遅延への対応 時間ベースでログの遅延を監視したい
Kafkaの概要 このメッセージと現在時刻の 差が知りたい P:Partition C:Consumer Partition
時間ベースの遅延計算 ①オフセット情報の一覧を取得 ②各パーティションからのオフセット地点のメッセージ を取得 ③現在時刻とtimestampの差を計算 0 1 2 3 81
82 ・・・ 83 84 0 1 2 3 53 54 ・・・ 55 56 0 1 2 3 77 78 ・・・ 79 80 offset offset offset Partition1 Partition2 Partition3 Partition1: 81 Partition2: 54 Partition3: 80 Partition1: {“timestamp”: “2019-01-01 11:23”, ”data”: ...} Partition2: {“timestamp”: “2019-01-01 11:18”, ”data”: ...} Partition3: {“timestamp”: “2019-01-01 12:10”, ”data”: ...} Partition1: now - [2019-01-01 11:23] = 520 sec Partition2: now - [2019-01-01 11:18] = 820 sec Partition3: now - [2019-01-01 11:30] = 100 sec
Consumerグループ一覧の問い合わせ ↓ Consumerグループが読んでいるパーティションの取り出し ↓ パーティションのOffsetを問い合わせ ↓ パーティションにメッセージを問い合わせ ↓ メッセージからタイムスタンプを取りだして遅延を計算 ↓
一覧にして出力 プログラム上の処理の流れ
実行結果はConsumerGroupのパーティションごとに出力 実行結果 > sbt “runMain command.LagReaderCommand -b [boot-strap-server] -c consumer_group"
ConsumerGroup TopicPartition Lag consumer_group 0 10sec consumer_group 1 45sec consumer_group 2 15sec 最終的にこれを全パーティション分取得して監視したい
一つ一つのパーティションを順番に読んでいくと データの取り出しに時間がかかる (パーティション数が100程度のstg環境で17分) 実行時間の問題点 複数パーティションから同時購読を行い高速化
複数パーティションをまとめて購読しデータ取得 流量の関係で一度に全てのパーティションのメッセージを取得することができない 複数パーティション同時購読の課題 Partition1 Partition2 Partition3 Partition4 Consumer グループ :
メッセージ 流量の多い パーティションに偏る
複数Consumerグループが同一のパーティションを参照することがあるので 一つのパーティションから異なるオフセットのメッセージを取り出す必要がある 複数回シークを行う必要があり非効率 複数パーティション同時購読の課題 0 1 2 3 81 82
・・・ 83 84 offset1 Partition offset2 Consumer グループ1 offset1: 81 Consumer グループ2 offset1: 83
Consumerグループ一覧の問い合わせ ↓ Consumerが読んでいるパーティションの取り出し ↓ パーティションのOffsetを問い合わせ ↓ パーティションにメッセージを問い合わせ ↓ メッセージからタイムスタンプを取りだして遅延を計算 ↓
一覧にして出力 プログラム上の処理の流れ(修正前)
Consumerグループ一覧の問い合わせ ↓ Consumerが読んでいるパーティションの取り出し ↓ パーティションのOffsetを問い合わせ ↓ Offsetの重複排除 ↓ パーティションに並列に問い合わせ ↓
メッセージを取得できなかったパーティションがないか確認 ↓ メッセージからタイムスタンプを取りだして遅延を計算 ↓ 一覧にして出力 プログラム上の処理の流れ(修正後)
Consumerグループ2 - Topic1 Partition1: 100 - Topic2 Partition1: 150 -
Topic2 Partition2: 220 Consumerグループ1 - Topic2 Partition1: 80 - Topic2 Partition2: 300 Consumerグループ3 - Topic1 Partition1: 130 オフセット情報の一覧を取得 この単位でまとめて問い合わせできない Partition1 Partition1 Partition2 Consumer グループ2 Consumer グループ1 Kafka Cluster Consumerグループ一 覧の取得 Consumerグループに対 応するパーティションの Offsetを取り出す パーティションの重 複排除 Consumerグループ1 Consumerグループ2 Consumerグループ3 Consumerグループ2 - Topic2 Partition1: 150 - Topic2 Partition2: 220 Consumerグループ3 - Topic1 Partition1: 130 Consumerグループ1 - Topic2 Partition1: 80 - Topic2 Partition2: 300 Consumerグループ2 - Topic1 Partition1: 100 重複しない単位でまとめ直す Consumer グループ3 Topic2 Topic1
Consumerグループ一覧の問い合わせ ↓ Consumerが読んでいるパーティションの取り出し ↓ パーティションのOffsetを問い合わせ ↓ Offsetの重複排除 ↓ パーティションに並列に問い合わせ ↓
メッセージを取得できなかったパーティションがないか確認 ↓ メッセージからタイムスタンプを取りだして遅延を計算 ↓ 一覧にして出力 プログラム上の処理の流れ(修正後)
並列にメッセージを取得 重複排除後のオフセット Consumerグループ1 - Partition2: 80 - Partition4: 300 Consumerグループ2
- Partition1: 100 Partition1 Partition2 Partition3 Partition4 メッセージを取得 Kafka Cluster 問い合わせ1回目 Partition1 Partition2 Partition3 Partition4 メッセージを取得 Kafka Cluster 問い合わせ2回目 取得できなかったパーティション からメッセージを取得
並列にメッセージを取得 重複排除後のオフセット Consumerグループ1 - Partition2: 80 - Partition4: 300 Consumerグループ2
- Partition1: 100 Partition1 Partition2 Partition3 Partition4 メッセージを取得 Kafka Cluster 問い合わせ1回目 Partition1 Partition2 Partition3 Partition4 メッセージを取得 Kafka Cluster 問い合わせ2回目 取得できなかったパーティション からメッセージを取得
7分半→1分半へ高速化 比率にすると1/5程度の時間に短縮 1分半ほどの実行時間であれば常時回しておけば遅延監視には十分な速度 高速化結果
取得したデータは常時監視したいのでPrometheusで可視化 遅延の可視化 遅延計算プログラム 常時各パーティションの 遅延を計測 蓄積されたデータの 取得 (Exporter) consumer1 partition0
100sec consumer1 partition1 200sec consumer2 partition0 180sec consumer3 partition0 50sec ・ ・ ・
Prometheusの画面 オフセットベース 時間ベース 時刻 ログのオフセット ログの遅延時間 最大の遅延は 23時35分の70万 最大の遅延は 0時0分の25分
時刻 オフセットベースで遅延が広がったタイミングよりもあとで、時間ベースでの遅延が広がっている
• 時間ベースの遅延を可視化 • 複数パーティションの同時購読より遅延取得を高速化 • Prometheusで常時遅延の監視を実現 まとめ