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
40
robust logprocessing
安全にスケールするログ解析システムの勘所
Daisuke Yamazaki
January 16, 2011
Tweet
Share
More Decks by Daisuke Yamazaki
See All by Daisuke Yamazaki
ノートラブルシステムへの道
yamaz
22
7.9k
RWC2019 rubyによる超大量データ配信
yamaz
0
140
学び実践してきたこと
yamaz
1
260
スケールアウト再考
yamaz
1
280
RTB 30 min
yamaz
0
80
RailsとCで広告システムを作って起業した話
yamaz
0
200
adserver 30min
yamaz
0
56
Other Decks in Technology
See All in Technology
EDRの検知の仕組みと検知回避について
chayakonanaika
12
4.9k
30→150人のエンジニア組織拡大に伴うアジャイル文化を醸成する役割と取り組みの変化
nagata03
0
180
AIエージェント元年@日本生成AIユーザ会
shukob
1
210
EMConf JP 2025 懇親会LT / EMConf JP 2025 social gathering
sugamasao
2
190
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
250
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
daiksy
14
5k
株式会社Awarefy(アウェアファイ)会社説明資料 / Awarefy-Company-Deck
awarefy
3
11k
"TEAM"を導入したら最高のエンジニア"Team"を実現できた / Deploying "TEAM" and Building the Best Engineering "Team"
yuj1osm
1
170
OSS構成管理ツールCMDBuildを使ったAWSリソース管理の自動化
satorufunai
0
640
LINE NEWSにおけるバックエンド開発
lycorptech_jp
PRO
0
240
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
5
890
クラウド関連のインシデントケースを収集して見えてきたもの
lhazy
7
1k
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
67
4.6k
Scaling GitHub
holman
459
140k
GitHub's CSS Performance
jonrohan
1030
460k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Docker and Python
trallard
44
3.3k
Statistics for Hackers
jakevdp
797
220k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
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 ログ集計に際して弊社で考慮していることを 簡単に説明しました。 メンバー募集中です!大量配信・大規模集計やりたい方は ぜひ。 バイト・インターンも可です(yama@scaleout.jpまで) 19