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
robust logprocessing
Search
Daisuke Yamazaki
January 16, 2011
Technology
1
52
robust logprocessing
安全にスケールするログ解析システムの勘所
Daisuke Yamazaki
January 16, 2011
Tweet
Share
More Decks by Daisuke Yamazaki
See All by Daisuke Yamazaki
ノートラブルシステムへの道
yamaz
22
8.2k
RWC2019 rubyによる超大量データ配信
yamaz
1
150
学び実践してきたこと
yamaz
1
300
スケールアウト再考
yamaz
1
300
RTB 30 min
yamaz
0
90
RailsとCで広告システムを作って起業した話
yamaz
1
250
adserver 30min
yamaz
0
66
Other Decks in Technology
See All in Technology
VCpp Link and Library - C++ breaktime 2025 Summer
harukasao
0
220
ObsidianをMCP連携させてみる
ttnyt8701
2
140
新卒3年目の後悔〜機械学習モデルジョブの運用を頑張った話〜
kameitomohiro
0
370
Observability infrastructure behind the trillion-messages scale Kafka platform
lycorptech_jp
PRO
0
130
Model Mondays S2E02: Model Context Protocol
nitya
0
170
知識を整理して未来を作る 〜SKDとAI協業への助走〜
yosh1995
0
130
20250625 Snowflake Summit 2025活用事例 レポート / Nowcast Snowflake Summit 2025 Case Study Report
kkuv
1
150
doda開発 生成AI元年宣言!自家製AIエージェントから始める生産性改革 / doda Development Declaration of the First Year of Generated AI! Productivity Reforms Starting with Home-grown AI Agents
techtekt
0
190
Prox Industries株式会社 会社紹介資料
proxindustries
0
170
標準技術と独自システムで作る「つらくない」SaaS アカウント管理 / Effortless SaaS Account Management with Standard Technologies & Custom Systems
yuyatakeyama
2
970
[TechNight #90-1] 本当に使える?ZDMの新機能を実践検証してみた
oracle4engineer
PRO
3
140
Amazon Bedrockで実現する 新たな学習体験
kzkmaeda
1
370
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
The Pragmatic Product Professional
lauravandoore
35
6.7k
How to train your dragon (web standard)
notwaldorf
92
6.1k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
660
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
What's in a price? How to price your products and services
michaelherold
245
12k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Documentation Writing (for coders)
carmenintech
71
4.9k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Transcript
安全にスケールするログ解析システム 構築の勘所 1 株式会社 スケールアウト 山崎大輔
はじめに 1. スケーラブルなログ集計を安全に構築するために我々が考慮している ことを説明します。 2. 広告集計という特性上、「超高速にかつ高効率に!」というよりはどち らかというと「多少の非効率は目をつぶって安全側に寄せる」という設 計方針になっています。 3. 上司から突然「来月から1日10億越えのアクセスを食うことになるから
集計システムはよろしくね♪」という日が来るかもしれないので、来た る日に備えてもらえればと思います。 2
アジェンダ n 自己紹介 n ログ集計の実際 n ログ集計の各パートで考慮していること n まとめ 3
自己紹介 山崎大輔 Twitter: @yamaz Blog : 最速配信研究会 http://d.hatena.ne.jp/yamaz/ 現在:株式会社スケールアウト 代表
1日数億~を超えるような配信をカジュアルに行うための 広告配信システム「ScaleAds」の開発と販売およびコンサル かれこれオンライン広告業界で14年やってます 4
広告集計で行っている典型的 な処理 n 分散処理ができるもの n PageView集計など n 分散処理しにくく、依存関係がないもの n 1日分のUU(UniqueUser)集計
n 分散処理できず、データの依存関係があるもの n 積算UU集計など 5
システム構成(分散が効くもの) 6 配信サーバ 集計サーバ レポートサーバ(RDB) 生ログ 中間集計ログ
システム構成(分散が効かないもの) 7 配信サーバ 集計クラスタ(Hadoop) レポートサーバ(RDB) 生ログ
処理全体で意識すべきこと 集計処理全体でどのサーバにどう処理を負担させるべき かを強く意識する 例: 集計サーバ側での巨大テーブル同士のJOINは大変 解決案: JOIN相当が行われた状態でログをはき出す JOIN演算をフロントサーバに寄せることで、 JOIN演算の計算リソースと時間を分散する (ただしディスクは食う)
8
ログローテート n 定期的なログローテーション(現在は1時間 に一度) n ランダムローテーション(全台同時に落とし て対応するHTTPDがいなくなる状態を避 ける) 9
中間集計 ログローテーション後、分散処理が効く集計に関 しては速やかに同一サーバ(=配信サーバ)で 中間集計を行う 利点: 配信サーバが配信と中間処理のコストを 負うので、全体が間に合うようにサーバを足す だけ勝手にスケールする。 10
ログトランスファー n あんまりよくない方法 1日終わった後に全部のログを集める →集計開始時間が無駄に遅くなる n よりよい方法 ローテーション回数を増やし、時間分割して集まってない 奴だけを集める 11
ログトランスファーその2 n よりよいかもしれない方法 ログをそのままネットワークを介してデータストレージに書き 込む(Facebook Scribeなど) 利点: 帯域利用の平滑化が達成される (ログの二重書き込みの可能性を排除できなかった ため、弊社では不採用)
(注) 広告集計上まずいこと ログの二重カウント>> (越えられない壁) >>ログのロスト > 集計が間に合わない > その他 12
本集計 n 集計の冪等性を強く意識する 冪等性(べきとうせい: idempotence) ある操作を1回行っても複数回行っても結果が同じである ことをいう概念 n → 冪等性があって分割処理をしやすい集計はスケール
しやすい n 冪等性のあるなし/分割処理のしやすさによって処理を分 ける 13
本集計 n 冪等性あり/分割処理しやすい(例: PageViewカウント) → フロントサーバで中間集計し、本集計でマージ処理 (中間集計で大部分の処理が完了しているので、 処理は5 分程度) n
冪等性ちょっとあり/分割処理しにくい( 例: UniqueUserカウント) Hadoopクラスタにデータを載せて集計 n 冪等性なし/分割処理しにくい(例: 積算UUカウント) Hadoopクラスタにデータを載せて集計 14
日々の運用について n キャパシティプランニング n 人的依存の排除 n 集計系に過度な期待をかけない 15
キャパシティプランニング 今後の伸びだけでなく、日常的に再集計がおきうる ことも加味する よくない例 1日の集計が20時間かかる →再集計にかけられる時間が1日4時間しかない →1日の集計遅れを取り返すのに5日かかる →週明けに金曜の集計ミスが起きたら事実上アウト 弊社の例)8時間で完了するようにプランニングする 16
人的依存の排除 n 冪等性がある集計なら誰がいつ実行しても問題ないよう にする。 n 集計側を過度に複雑なシステムにて復旧にノウハウが必 要なようにはしない 繊細な条件でしか動かないようなシステムは よくないシステム(やかんはこわれないよ) 17
集計系に過度な負荷をかけな い n NOSQLベースだとJOIN演算がきつくなるので、ログ作成及びETL 側で工夫する ログ作成側(Webサーバ)でJOIN演算相当を行ってログ1行に極力 すべてのデータがあるようにする(これはJoin演算をアクセス側 に寄せているのと同じ) n 過度な最適化はあきらめる
最近のハードウェアは速く、単純な仕組みでも十分速い。 なので複雑な仕組みを導入しないと速度が上がらないようなら アーキテクチャやハードウェアの選定が間違っている可能性も 考えましょう 18
まとめ n ログ集計に際して弊社で考慮していることを 簡単に説明しました。 メンバー募集中です!大量配信・大規模集計やりたい方は ぜひ。 バイト・インターンも可です(
[email protected]
まで) 19