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
60
robust logprocessing
安全にスケールするログ解析システムの勘所
Daisuke Yamazaki
January 16, 2011
Tweet
Share
More Decks by Daisuke Yamazaki
See All by Daisuke Yamazaki
ゼロトラブルへの道
yamaz
22
8.4k
RWC2019 rubyによる超大量データ配信
yamaz
1
160
学び実践してきたこと
yamaz
1
310
スケールアウト再考
yamaz
1
310
RTB 30 min
yamaz
0
93
RailsとCで広告システムを作って起業した話
yamaz
1
260
adserver 30min
yamaz
0
72
Other Decks in Technology
See All in Technology
広島発!スタートアップ開発の裏側
tsankyo
0
230
Amazon Bedrock AgentCore でプロモーション用動画生成エージェントを開発する
nasuvitz
6
410
広島銀行におけるAWS活用の取り組みについて
masakimori
0
120
攻撃と防御で実践するプロダクトセキュリティ演習~導入パート~
recruitengineers
PRO
1
120
GCASアップデート(202506-202508)
techniczna
0
250
Preferred Networks (PFN) とLLM Post-Training チームの紹介 / 第4回 関東Kaggler会 スポンサーセッション
pfn
PRO
1
170
知られざるprops命名の慣習 アクション編
uhyo
10
2.4k
いま、あらためて考えてみるアカウント管理 with IaC / Account management with IaC
kohbis
2
680
つくって納得、つかって実感! 大規模言語モデルことはじめ
recruitengineers
PRO
18
4.2k
VPC Latticeのサービスエンドポイント機能を使用した複数VPCアクセス
duelist2020jp
0
180
トヨタ生産方式(TPS)入門
recruitengineers
PRO
1
170
ABEMAにおける 生成AI活用の現在地 / The Current Status of Generative AI at ABEMA
dekatotoro
0
640
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Practical Orchestrator
shlominoach
190
11k
Designing for humans not robots
tammielis
253
25k
Building Applications with DynamoDB
mza
96
6.6k
Writing Fast Ruby
sferik
628
62k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Fireside Chat
paigeccino
39
3.6k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Agile that works and the tools we love
rasmusluckow
329
21k
How to train your dragon (web standard)
notwaldorf
96
6.2k
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