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
33
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
110
スケールアウト再考
yamaz
1
270
RTB 30 min
yamaz
0
71
RailsとCで広告システムを作って起業した話
yamaz
0
150
adserver 30min
yamaz
0
49
Other Decks in Technology
See All in Technology
10分でわかるfreee エンジニア向け会社説明資料
freee
18
520k
全社横断データ活用推進のコツと その負債とのつき合い方
masatoshi0205
0
160
DatabricksにおけるLLMOpsのベストプラクティス
taka_aki
4
1.6k
FOSS4G 2024 Japan コアデイ 一般発表25 PythonでPLATEAUのデータを手軽に扱ってみる
ra0kley
1
130
家具家電付アパートの冷蔵庫をIoT化してみた!
scbc1167
0
140
ZOZOTOWNでの推薦システム活用事例の紹介
f6wbl6
1
440
いろんなものと両立する Kaggleの向き合い方
go5paopao
2
940
社内で最大の技術的負債のリファクタリングに取り組んだお話し
kidooonn
0
370
利きプロセススケジューラ
sat
PRO
4
2.6k
re:Invent 2024のおすすめセッション
beli68
0
110
Microsoft Intune アプリのトラブルシューティング
sophiakunii
1
370
透過型SMTPプロキシによる送信メールの可観測性向上: Update Edition / Improved observability of outgoing emails with transparent smtp proxy: Update edition
linyows
2
160
Featured
See All Featured
Fireside Chat
paigeccino
33
3k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
15
2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
A better future with KSS
kneath
238
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