安全にスケールするログ解析システム構築の勘所

1

株式会社 スケールアウト　　　　　　　　　山崎大輔

はじめに1. スケーラブルなログ集計を安全に構築するために我々が考慮し

ていることを説明します。

2. 広告集計という特性上、「超高速にかつ高効率に！」というよりはどちらかというと「多少の非効率は目をつぶって安全側に寄せる」という設計方針になっています。

3. 上司から突然「来月から 1 日 10 億越えのアクセスを食うことになるから集計システムはよろしくね♪」という日が来るかもしれないので、来たる日に備えてもらえればと思います。

2

アジェンダ

自己紹介 ログ集計の実際 ログ集計の各パートで考慮しているこ

と まとめ

3

自己紹介山崎大輔Twitter: @yamazBlog : 最速配信研究会 http://d.hatena.ne.jp/yamaz/

現在：株式会社スケールアウト 代表1 日数億～を超えるような配信をカジュアルに行うための広告配信システム「 ScaleAds 」の開発と販売およびコンサル

かれこれオンライン広告業界で 14 年やってます

4

広告集計で行っている典型的な処理

分散処理ができるもの PageView 集計など

分散処理しにくく、依存関係がないもの 1 日分の UU(UniqueUser) 集計

分散処理できず、データの依存関係があるもの 積算 UU 集計など

5

システム構成 ( 分散が効くもの )

6

配信サーバ

集計サーバ

レポートサーバ (RDB) 　

生ログ

中間集計ログ

システム構成 ( 分散が効かないもの )

7

配信サーバ

集計クラスタ (Hadoop)

レポートサーバ (RDB) 　

生ログ

処理全体で意識すべきこと

　集計処理全体でどのサーバにどう処理を負担させるべきかを強く意識する

例： 集計サーバ側での巨大テーブル同士の JOIN は大変解決案： JOIN 相当が行われた状態でログをはき出す

JOIN 演算をフロントサーバに寄せることで、JOIN 演算の計算リソースと時間を分散する( ただしディスクは食う )

8

ログローテート

定期的なログローテーション ( 現在は1 時間に一度 )

ランダムローテーション ( 全台同時に落として対応する HTTPD がいなくなる状態を避ける )

9

中間集計

ログローテーション後、分散処理が効く集計に関しては速やかに同一サーバ (= 配信サーバ ) で中間集計を行う

利点 : 配信サーバが配信と中間処理のコストを負うので、全体が間に合うようにサーバを足すだけ勝手にスケールする。

10

ログトランスファー

あんまりよくない方法1 日終わった後に全部のログを集める

→ 集計開始時間が無駄に遅くなる

よりよい方法ローテーション回数を増やし、時間分割して集まってない奴だけを集める

11

ログトランスファーその 2

よりよいかもしれない方法ログをそのままネットワークを介してデータストレー

ジに書き込む (Facebook Scribe など )

利点： 帯域利用の平滑化が達成される( ログの二重書き込みの可能性を排除できなかったため、弊社では不採用 )

(注 ) 広告集計上まずいことログの二重カウント >> ( 越えられない壁 ) >> ログのロ

スト > 集計が間に合わない > 　その他

12

本集計

集計の冪等性を強く意識する 冪等性（べきとうせい : idempotence）　ある操作を 1 回行っても複数回行っても結果が同じ

であることをいう概念 → 冪等性があって分割処理をしやすい集計はスケ

ールしやすい 冪等性のあるなし / 分割処理のしやすさによって処

理を分ける

13

本集計

冪等性あり / 分割処理しやすい ( 例 : PageView カウント )

→ フロントサーバで中間集計し、本集計でマージ処理( 中間集計で大部分の処理が完了しているので、処理は 5 分程度 )

冪等性ちょっとあり / 分割処理しにくい ( 例 : UniqueUser カウント )

Hadoop クラスタにデータを載せて集計

冪等性なし / 分割処理しにくい ( 例 : 積算 UU カウント )

Hadoop クラスタにデータを載せて集計

14

日々の運用について

キャパシティプランニング 人的依存の排除 集計系に過度な期待をかけない

15

キャパシティプランニング

今後の伸びだけでなく、日常的に再集計がおきうることも加味する

よくない例1 日の集計が 20 時間かかる→再集計にかけられる時間が 1 日 4 時間しかない→1 日の集計遅れを取り返すのに 5 日かかる→週明けに金曜の集計ミスが起きたら事実上アウト

弊社の例 )8 時間で完了するようにプランニングする

16

人的依存の排除

冪等性がある集計なら誰がいつ実行しても問題ないようにする。

集計側を過度に複雑なシステムにて復旧にノウハウが必要なようにはしない

繊細な条件でしか動かないようなシステムはよくないシステム ( やかんはこわれないよ )

17

集計系に過度な負荷をかけない

NOSQLベースだと JOIN 演算がきつくなるので、ログ作成及びETL 側で工夫する

ログ作成側 (Web サーバ ) で JOIN 演算相当を行ってログ 1 行に極力

すべてのデータがあるようにする ( これは Join 演算をアクセス側に寄せているのと同じ )

過度な最適化はあきらめる最近のハードウェアは速く、単純な仕組みでも十分速い。なので複雑な仕組みを導入しないと速度が上がらないようならアーキテクチャやハードウェアの選定が間違っている可能性も考えましょう

18

まとめ

ログ集計に際して弊社で考慮していることを　　簡単に説明しました。

メンバー募集中です！大量配信・大規模集計やりたい方はぜひ。

バイト・インターンも可です (yama@scaleout.jpまで )

19