OSSで支えられるライブドアの巨大ログ集計 #nhntech

24,369 views

Published on

Published in: Technology
1 Comment
89 Likes
Statistics
Notes
  • 勉強になります! >> '変更なしでバリエーション増に対応できる設定セットを作る' '汎用の公開ソフトウェアを可能な限りそのまま使う'
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
24,369
On SlideShare
0
From Embeds
0
Number of Embeds
3,780
Actions
Shares
0
Downloads
107
Comments
1
Likes
89
Embeds 0
No embeds

No notes for slide

OSSで支えられるライブドアの巨大ログ集計 #nhntech

  1. 1. OSSで支えられる ライブドアの巨大ログ集計 - HiveとFluentd - 第2回 NHNテクノロジーカンファレンス 2012/08/18 TAGOMORI Satoshi (@tagomoris)12年8月18日土曜日
  2. 2. TAGOMORI Satoshi (@tagomoris) NHNJapan株式会社 ウェブサービス本部 開発2室12年8月18日土曜日
  3. 3. 今日の話 どういうことをやっているかの話 機能とコンポーネント分離の話 規模の拡大とデプロイの話12年8月18日土曜日
  4. 4. どういうことをやっているかの話12年8月18日土曜日
  5. 5. アクセスログ収集・集計 システム・サービスの稼動状況を明確にする PV, UUの集計 HTTPレスポンスコード毎の割合の時系列変化 レスポンスタイムの統計・時系列変化 そのほか必要に応じたログ調査など12年8月18日土曜日
  6. 6. 概要 Web Server Fluentd log Web Server info Graphs (GrowthForecast) log Hive Client query Hive Server Hadoop/HDFS12年8月18日土曜日
  7. 7. 構成ソフトウェア Hadoop Cluster (Hadoop, Hive) CDH3u5 + CentOS5 + JDK6 Fluentd Cluster Fluentd 0.10.25 + CentOS5 + Ruby 1.9.3-p194 + jemalloc Others GrowthForecast, HRForecast fluent-agent-lite, Shib, ShibUI12年8月18日土曜日
  8. 8. Hive オープンソースプロダクト Hadoop MapReduce のためのDSL(ドメイン特化言語) HiveQL というほぼSQLそのままのものを使える 特に集計・統計においてパフォーマンスが良い Hive Server経由でRPCを使える12年8月18日土曜日
  9. 9. Fluentd オープンソースプロダクト 構造化ログ収集用ソフトウェア インストールが簡単、拡張性があり、比較的高速に動作 プラグイン機構を備えていて豊富な公開プラグインが存在 いくつかの機能を使うことでデータ処理にも使用可能12年8月18日土曜日
  10. 10. アクセスログ収集・集計 ログ収集・変換: Fluentd 集計処理: Hive リアルタイム統計処理: Fluentd12年8月18日土曜日
  11. 11. 概要 Web Server Fluentd log Web Server info Graphs (GrowthForecast) log Hive Client query Hive Server Hadoop/HDFS12年8月18日土曜日
  12. 12. 実装の詳細 "Hive Tools in NHN Japan" Hadoop Source Code Reading vol.9 (2012/05/30) http://www.slideshare.net/tagomoris/hive-tools-in-nhn-japan-hadoopreading "Distributed message stream processing on Fluentd" Fluentd meetup in Japan #1 (2012/02/04) http://www.slideshare.net/tagomoris/distributed-stream-processing-on-fluentd-fluentd "Plugins by tagomoris" Fluentd Casual Talks (2012/05/18) http://www.slideshare.net/tagomoris/plugins-by-tagomoris-fluentdcasual12年8月18日土曜日
  13. 13. 実装の詳細 ごめん、無理…… "Hive Tools in NHN Japan" 30分 Hadoop Source Code Reading vol.9 (2012/05/30) http://www.slideshare.net/tagomoris/hive-tools-in-nhn-japan-hadoopreading "Distributed message stream processing on Fluentd" Fluentd meetup in Japan #1 (2012/02/04) 60分 30分 http://www.slideshare.net/tagomoris/distributed-stream-processing-on-fluentd-fluentd "Plugins by tagomoris" Fluentd Casual Talks (2012/05/18) 10分 30分 http://www.slideshare.net/tagomoris/plugins-by-tagomoris-fluentdcasual12年8月18日土曜日
  14. 14. 集計クエリの登録と実行 Shib / ShibUI の画面でごらんください Shib でのクエリ入力と実行 ShibUI でのクエリ登録、グラフの閲覧 ShibUI でのクエリ作成12年8月18日土曜日
  15. 15. Why We Dont Use Data Analytics Services?12年8月18日土曜日
  16. 16. なぜ自分達で作るか なぜ Google Analytics (or others)じゃいけないのか? 根拠: 数字の理由が説明可能でなければならない 再現性: データさえあれば追試可能でなければならない 機能と継続性の問題 機能とコンポーネント分離の話 規模の拡大とデプロイの話12年8月18日土曜日
  17. 17. 機能とコンポーネント分離の話12年8月18日土曜日
  18. 18. コンポーネント分離 Hadoop / HDFS Hive Server 例:Hive系 Shib (node.js) ShibUI (Perl/Plack Web Application: Kossy) Users (Web Browser) HRForecast12年8月18日土曜日
  19. 19. 機能のアップデート ミドルウェアの機能アップデート この分野のツールはアップデートが頻繁にある しかも適用したいアップデートが多い UIツール等の機能アップデート (社内)ユーザ向けの機能の追加・修正など 頻繁に行えないようでは仕事をしているとは言えない12年8月18日土曜日
  20. 20. 機能向上のための鉄則 頻繁に、ただし全体を壊さずにアップデートしたい コンポーネント分離を徹底する インターフェイスを明確に定めて疎結合化するため ある箇所の変更の影響範囲をできるだけ小さくするため 小さく、変更内容が追えるツールをOSSで揃える 更新タイミングをコントロール可能な状態を維持する12年8月18日土曜日
  21. 21. 規模の拡大とデプロイの話12年8月18日土曜日
  22. 22. デプロイ対象 deliver archiver backup servers deliver servers servers worker worker worker worker worker worker worker worker worker servers servers serializer serializer 例:Fluentdクラスタ HDFS (WebHDFS)12年8月18日土曜日
  23. 23. 規模の拡大への対応 量の拡大 PV増にともなうアクセスログの増大への対応 「サーバを増やしてリストに追加するだけ」になってる? バリエーションの拡大 サービス増減に関して手間がかかるようでは駄目 「ログを流せばあとは全自動」になってる? 私見 「スケールする」と言うとき、両方に対応できているべき12年8月18日土曜日
  24. 24. スケールするクラスタ構成の鉄則 変更は少なく、追加は容易に 変更なしでバリエーション増に対応できる設定セットを作る その上で規模の桁が違う一部にだけ特例の設定を行う 汎用の公開ソフトウェアを可能な限りそのまま使う デプロイ手順が複雑な構成はスケールしない できるだけミドルウェアに任せることで複雑さを軽減する 10%+の性能よりもデプロイ容易性の方が価値が高い12年8月18日土曜日
  25. 25. 場合によっては あらゆるところに 手を入れる覚悟をしておく12年8月18日土曜日
  26. 26. コンセプトの良いOSSを 選んで使う Hive と Fluentd12年8月18日土曜日
  27. 27. Thanks! photo: crouton & luke by @kbysmnr12年8月18日土曜日

×