SlideShare a Scribd company logo
安全にスケールするログ解析システム構築の勘所   株式会社 スケールアウト          山崎大輔
はじめに 1.  スケーラブルなログ集計を安全に構築するために我々が考慮していることを説明します。 2.  広告集計という特性上、「超高速にかつ高効率に!」というよりはどちらかというと「多少の非効率は目をつぶって安全側に寄せる」という設計方針になっています。 3.  上司から突然「来月から 1 日 10 億越えのアクセスを食うことになるから集計システムはよろしくね♪」という日が来るかもしれないので、来たる日に備えてもらえればと思います。
アジェンダ 自己紹介 ログ集計の実際 ログ集計の各パートで考慮していること まとめ
自己紹介 山崎大輔 Twitter: @yamaz Blog  :  最速配信研究会  http://d.hatena.ne.jp/yamaz/ 現在:株式会社スケールアウト 代表 1 日数億~を超えるような配信をカジュアルに行うための 広告配信システム「 ScaleAds 」の開発と販売およびコンサル かれこれオンライン広告業界で 14 年やってます
広告集計で行っている典型的な処理 分散処理ができるもの PageView 集計など 分散処理しにくく、依存関係がないもの 1 日分の UU(UniqueUser) 集計 分散処理できず、データの依存関係があるもの 積算 UU 集計など
システム構成 ( 分散が効くもの ) 配信サーバ 集計サーバ レポートサーバ (RDB)   生ログ 中間集計ログ
システム構成 ( 分散が効かないもの ) 配信サーバ 集計クラスタ (Hadoop) レポートサーバ (RDB)   生ログ
処理全体で意識すべきこと  集計処理全体でどのサーバにどう処理を負担させるべきかを強く意識する 例: 集計サーバ側での巨大テーブル同士の JOIN は大変 解決案:  JOIN 相当が行われた状態でログをはき出す JOIN 演算をフロントサーバに寄せることで、 JOIN 演算の計算リソースと時間を分散する ( ただしディスクは食う )
ログローテート 定期的なログローテーション ( 現在は 1 時間に一度 ) ランダムローテーション ( 全台同時に落として対応する HTTPD がいなくなる状態を避ける )
中間集計 ログローテーション後、分散処理が効く集計に関しては速やかに同一サーバ (= 配信サーバ ) で中間集計を行う 利点 :  配信サーバが配信と中間処理のコストを負うので、全体が間に合うようにサーバを足すだけ勝手にスケールする。
ログトランスファー あんまりよくない方法 1 日終わった後に全部のログを集める -> 集計開始時間が無駄に遅くなる よりよい方法 ローテーション回数を増やし、時間分割して集まってない奴だけを集める
ログトランスファーその 2 よりよいかもしれない方法 ログをそのままネットワークを介してデータストレージに書き込む (Facebook Scribe など ) 利点: 帯域利用の平滑化が達成される ( ログの二重書き込みの可能性を排除できなかった ため、弊社では不採用 ) ( 注 )  広告集計上まずいこと ログの二重カウント >> ( 越えられない壁 ) >> ログのロスト  >  集計が間に合わない  >  その他
本集計 集計の冪等性を強く意識する 冪等性(べきとうせい :  idempotence )  ある操作を 1 回行っても複数回行っても結果が同じであることをいう概念 ->  冪等性があって分割処理をしやすい集計はスケールしやすい 冪等性のあるなし / 分割処理のしやすさによって処理を分ける
本集計 冪等性あり / 分割処理しやすい ( 例 : PageView カウント )  ->  フロントサーバで中間集計し、本集計でマージ処理 ( 中間集計で大部分の処理が完了しているので、 処理は 5  分程度 ) 冪等性ちょっとあり / 分割処理しにくい (  例 : UniqueUser カウント ) Hadoop クラスタにデータを載せて集計 冪等性なし / 分割処理しにくい ( 例 :  積算 UU カウント ) Hadoop クラスタにデータを載せて集計
日々の運用について キャパシティプランニング 人的依存の排除 集計系に過度な期待をかけない
キャパシティプランニング 今後の伸びだけでなく、日常的に再集計がおきうる ことも加味する よくない例 1 日の集計が 20 時間かかる -> 再集計にかけられる時間が 1 日 4 時間しかない -> 1 日の集計遅れを取り返すのに 5 日かかる -> 週明けに金曜の集計ミスが起きたら事実上アウト 弊社の例 )8 時間で完了するようにプランニングする
人的依存の排除 冪等性がある集計なら誰がいつ実行しても問題ないようにする。 集計側を過度に複雑なシステムにて復旧にノウハウが必要なようにはしない 繊細な条件でしか動かないようなシステムは よくないシステム ( やかんはこわれないよ )
集計系に過度な負荷をかけない NOSQL ベースだと JOIN 演算がきつくなるので、ログ作成及び ETL 側で工夫する ログ作成側 (Web サーバ ) で JOIN 演算相当を行ってログ 1 行に極力 すべてのデータがあるようにする ( これは Join 演算をアクセス側 に寄せているのと同じ ) 過度な最適化はあきらめる 最近のハードウェアは速く、単純な仕組みでも十分速い。 なので複雑な仕組みを導入しないと速度が上がらないようなら アーキテクチャやハードウェアの選定が間違っている可能性も 考えましょう
まとめ ログ集計に際して弊社で考慮していることを   簡単に説明しました。 メンバー募集中です!大量配信・大規模集計やりたい方はぜひ。 バイト・インターンも可です ( [email_address] まで )

More Related Content

PDF
Frontend optimization dena_creativeseminar
PDF
Fluentdのお勧めシステム構成パターン
PDF
2013/08/01 JAWS-UG福岡 x e-Zuka-Tech Night 「今一度、EC2を」
PDF
【Hpcstudy】みんな、ベンチマークどうやってるの?
PDF
SITW24 fluentdとダッシュボードを使った ビジュアルなシステム管理
PDF
Jaws ug横浜aws設計・移行ワークショップ 提案書(チーム3)
PPTX
HDFS (fsimage and edits) in CDH3,CDH4
PDF
アポ前15分で詰め込む!ログ解析
Frontend optimization dena_creativeseminar
Fluentdのお勧めシステム構成パターン
2013/08/01 JAWS-UG福岡 x e-Zuka-Tech Night 「今一度、EC2を」
【Hpcstudy】みんな、ベンチマークどうやってるの?
SITW24 fluentdとダッシュボードを使った ビジュアルなシステム管理
Jaws ug横浜aws設計・移行ワークショップ 提案書(チーム3)
HDFS (fsimage and edits) in CDH3,CDH4
アポ前15分で詰め込む!ログ解析

Similar to Robust log process (20)

PDF
ログにまつわるエトセトラ
PPT
Big data解析ビジネス
PPTX
EmbulkとDigdagとデータ分析基盤と
PPTX
EmbulkとDigdagとデータ分析基盤と
PDF
AZAREA-Clusterセミナー(クラウドEXPO2013春)
PDF
PostgreSQLの運用・監視にまつわるエトセトラ
PDF
NAND Flash から InnoDB にかけての話(仮)
PDF
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
PDF
20121205 nosql(okuyama fs)セミナー資料
PDF
sysloadや監視などの話(仮)
PDF
20110519 okuyama tokyo_linuxstudy
PDF
弊社IoT事例とAlexaSkil開発レシピ
PDF
hbstudy#6LTyuzorock
PPTX
マルチデバイス時代の高速化
PDF
はてなのNagios - モニカジ#3
PDF
GoldenGateテクニカルセミナー2「Oracle GoldenGate 新機能情報」(2016/5/11)
PPTX
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
PDF
InnoDBのすゝめ(仮)
ODP
事例紹介「なうまぴおん」
PDF
企業におけるSpring@日本springユーザー会20090624
ログにまつわるエトセトラ
Big data解析ビジネス
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
AZAREA-Clusterセミナー(クラウドEXPO2013春)
PostgreSQLの運用・監視にまつわるエトセトラ
NAND Flash から InnoDB にかけての話(仮)
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
20121205 nosql(okuyama fs)セミナー資料
sysloadや監視などの話(仮)
20110519 okuyama tokyo_linuxstudy
弊社IoT事例とAlexaSkil開発レシピ
hbstudy#6LTyuzorock
マルチデバイス時代の高速化
はてなのNagios - モニカジ#3
GoldenGateテクニカルセミナー2「Oracle GoldenGate 新機能情報」(2016/5/11)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
InnoDBのすゝめ(仮)
事例紹介「なうまぴおん」
企業におけるSpring@日本springユーザー会20090624
Ad

More from Daisuke Yamazaki (7)

PPTX
WayOfNoTrouble.pptx
PPTX
Ruby World Conference 2019 rubyによる超大量データ配信
PPTX
今まで学び実践してきたこと
PPTX
スケールアウト再考
PPT
PPT
RailsとCで広告システムを作って起業した話
PDF
30分でわかる広告エンジンの作り方
WayOfNoTrouble.pptx
Ruby World Conference 2019 rubyによる超大量データ配信
今まで学び実践してきたこと
スケールアウト再考
RailsとCで広告システムを作って起業した話
30分でわかる広告エンジンの作り方
Ad

Robust log process

Editor's Notes

  • #3: が、いろんな都合上、 答えられたり答えられなかったりしますので、そのあたり 大人ですので、ご理解ください。 今回同業の方もいらっしゃるので、びびってます><;