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
既存のログ監視システムをクラウドっぽく実装してみた
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
tjmtrhs
February 18, 2026
Technology
0
450
既存のログ監視システムをクラウドっぽく実装してみた
ルータやスイッチが出力するsyslogを監視してアラートを発生させるシステムを運用しています。これをGCP Pub/SubやDataflowを用いて実装し直す取り組みを紹介します。
tjmtrhs
February 18, 2026
Tweet
Share
More Decks by tjmtrhs
See All by tjmtrhs
データモデルYANGの処理系を再発明した話
tjmtrhs
0
1.1k
運用者の試行錯誤を想定したNWモデル上での並列検証システム
tjmtrhs
0
53
コンテナを用いたISPネットワーク検証システムとトラヒックシミュレーションによる作業事前検証の実施
tjmtrhs
0
90
ISP機器設定ファイルをもとにトポロジモデルを抽出し仮想検証環境構築と運用手順確認に利用する手法
tjmtrhs
0
110
皆がすなるカオスエンジアリングといふものを、ネットワークオペレーションでもしてみむとてするなり
tjmtrhs
0
650
ネットワーク機器もエージェントで監視できるのかやってみた mackerel meetup 14 LT
tjmtrhs
0
2.1k
ネットワーク設定の抽象化とコンテナルータを用いた検証環境の立ち上げ支援
tjmtrhs
0
1.3k
もし本番ネットワークをまるごと仮想環境に”コピー”できたらうれしいですか?
tjmtrhs
0
200
モデルを基に本番環境を再現して事前に検証可能にする運用サイクル
tjmtrhs
0
86
Other Decks in Technology
See All in Technology
Security Diaries of an Open Source IAM
ahus1
0
210
クラウド × シリコンの Mashup - AWS チップ開発で広がる AI 基盤の選択肢
htokoyo
2
180
[JAWS DAYS 2026]私の AWS DevOps Agent 推しポイント
furuton
0
140
SRE NEXT 2026 CfP レビュアーが語る聞きたくなるプロポーザルとは?
yutakawasaki0911
1
250
作りっぱなしで終わらせない! 価値を出し続ける AI エージェントのための「信頼性」設計 / Designing Reliability for AI Agents that Deliver Continuous Value
aoto
PRO
2
280
脳内メモリ、思ったより揮発性だった
koutorino
0
210
OCI技術資料 : コンピュート・サービス 概要
ocise
4
54k
タスク管理も1on1も、もう「管理」じゃない ― KiroとBedrock AgentCoreで変わった"判断の仕事"
yusukeshimizu
5
2.6k
情シスのための生成AI実践ガイド2026 / Generative AI Practical Guide for Business Technology 2026
glidenote
0
200
When an innocent-looking ListOffsets Call Took Down Our Kafka Cluster
lycorptech_jp
PRO
0
120
スクリプトの先へ!AIエージェントと組み合わせる モバイルE2Eテスト
error96num
0
160
越境する組織づくり ─ 多様性を前提にしたチームビルディングとリードの実践知
kido_engineer
2
190
Featured
See All Featured
Are puppies a ranking factor?
jonoalderson
1
3.1k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
78
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
Color Theory Basics | Prateek | Gurzu
gurzu
0
240
Everyday Curiosity
cassininazir
0
160
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.1k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
1.9k
Music & Morning Musume
bryan
47
7.1k
RailsConf 2023
tenderlove
30
1.4k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
130
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
67
37k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
210
Transcript
© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 1 既存のログ監視システムを
クラウドっぽく実装してみた NTT Tech Conference 2026 LT 2026/02/18 @ docomo R&D OPEN LAB ODAIBA & online NTTドコモビジネス 原田和明, 川崎洋平, 田島照久
[email protected]
© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 2 それなりのNWを運用しています
業界最大級(たぶん)の検証設備の運営とエンジニア育成, speakerdeck, 2023/03/28
© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 3 基盤システム運用の監視とsyslog
Polling (pull, active) Trap (push, passive) log log log log log log messageの例 Jan 21 13:49:12 d01j.akbu mib2d[80865]: SNMP_TRAP_LINK_DOWN: ifIndex 646, ifAdminStatus up(1), ifOperStatus down(2), ifName xe-1/0/9
© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 4 これまでのシステムと改善の狙い
ログ保管 パケット ブローカ 異常判定 メンテ 情報DB 1日に100万行 いかないくらい = 平均 10 line/sec 通常は 発生数秒~10秒程度 の遅延
© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 5 これまでのシステムと改善の狙い
ログ保管 パケット ブローカ 異常判定 メンテ 情報DB 1日に100万行 いかないくらい = 平均 10 line/sec 通常は 発生数秒~10秒程度 の遅延 「平均」なので波がある。 冗長系切り替え時などでは 数千行が一気に出力される こともある 判定スクリプトのspawnに よりLoadAvgの増加を招き 数十分以上の遅延が発生 遅延による 時刻のずれで 不要な通知発 生 swatch で実装されていて わかりやすいが、全体的な ルールが不明瞭になって メンテ効率は微妙
© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 6 そうだPub/Subしよう:
大量メッセージを捌くノウハウ求めて パケット ブローカ syslog-ng Pub/Sub 入力用 トピック Dataflow メッセージを ストリーミング処理 Function + KVS 異常&メンテ判定 メンテ 情報DB Pub/Sub アラート用トピック Pub/Sub 非アラート用トピック Function 通知処理
© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 7 なぜDataflow?
◼ 要件 ⚫ pubsubのsubscriberとして動く ⚫ メッセージを読み、外部APIを叩き、 条件分岐で別topicにpublishできる ⚫ 絶え間なく流れるデータを オーバヘッド少なく処理してほしい ◼ 実装の案 ⚫ Function (Cloud Run) でpubsub SDK使って自前実装 ⚫ Dataflow (Apache Beam) を使う → 後者の方がPaaSっぽいし、周囲の入出力の責務は丸投げできて コア部分のロジックに限定できそう ※実際はGCE (IaaS) にdataflowインスタンスが建ちます
© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 8 参考:Dataflowはjavaのコードを書く
◼ pythonでも書ける らしいが未検証
© NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 9 改善されたのか?
◼ WIPですが、ちゃんと流れてそうな気配 ⚫ 負荷テストはこれから ◼ 頭を悩ますポイントは増えた ⚫ インスタンスサイズのコスパ • 最小でも月1万円くらい ⚫ dataflowの内部処理で ある程度バッファして処理しているが バッファ=遅延なのでその調整 ⚫ コンポーネントが疎になったので 結合テスト(CI)の実施方法が未知 • 想定するメッセージを都度publishして チェックする方法が有力 ⚫ オートスケールは有効に機能するのか (未検証)