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
0
34
robust logprocessing
安全にスケールするログ解析システムの勘所
Daisuke Yamazaki
January 16, 2011
Tweet
Share
More Decks by Daisuke Yamazaki
See All by Daisuke Yamazaki
ノートラブルシステムへの道
yamaz
22
7.6k
RWC2019 rubyによる超大量データ配信
yamaz
0
130
学び実践してきたこと
yamaz
0
220
スケールアウト再考
yamaz
1
270
RTB 30 min
yamaz
0
71
RailsとCで広告システムを作って起業した話
yamaz
0
160
adserver 30min
yamaz
0
49
Other Decks in Technology
See All in Technology
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
0
980
rootlessコンテナのすゝめ - 研究室サーバーでもできる安全なコンテナ管理
kitsuya0828
3
380
Lambdaと地方とコミュニティ
miu_crescent
2
370
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
3
170
Lambda10周年!Lambdaは何をもたらしたか
smt7174
2
110
B2B SaaSから見た最近のC#/.NETの進化
sansantech
PRO
0
660
10XにおけるData Contractの導入について: Data Contract事例共有会
10xinc
5
540
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
490
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
270
スクラムチームを立ち上げる〜チーム開発で得られたもの・得られなかったもの〜
ohnoeight
2
350
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
12k
リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers
lmi
4
300k
Featured
See All Featured
How to Ace a Technical Interview
jacobian
276
23k
A designer walks into a library…
pauljervisheath
203
24k
Happy Clients
brianwarren
98
6.7k
The Cost Of JavaScript in 2023
addyosmani
45
6.7k
How GitHub (no longer) Works
holman
310
140k
It's Worth the Effort
3n
183
27k
Designing for humans not robots
tammielis
250
25k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
GitHub's CSS Performance
jonrohan
1030
460k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
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