Amebaにおけるログ解析基盤Patriotの活用事例
•
18 recomendaciones•18,813 vistas
2013年11月7日開催 「Cloudera World Tokyo 2013」 セッション発表資料 （株式会社サイバーエージェント）
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Amebaにおけるログ解析基盤Patriotの活用事例
Similar a Amebaにおけるログ解析基盤Patriotの活用事例 (20)
Más de cyberagent
Más de cyberagent (20)
Último
Último (7)
Amebaにおけるログ解析基盤Patriotの活用事例
- 6. 株式会社サイバーエージェント Ameba Technology Laboratoryについて • Amebaの大規模データを集約的に扱う組織 • 2011年4月に開設、現在約20名が所属 ログ解析 検索 データマイニング 大規模 分散処理 (ログ解析基盤) 推薦 フィルタリング 6
- 8. 8 Amebaのログ解析基盤：Patriot • Amebaのサービス共通のログ解析基盤 • Ameba Technology Laboratoryで開発・運用 • サービスのユーザ行動の分析 • レコメンド等の大規模データ活用による機能の提供 • Hadoopクラスタ上に構築 • • • • HDFSにログデータを集約 Hive/MapReduceを用いた集計 HBaseを用いて処理結果を活用 Flumeを用いたデータ収集
- 10. 株式会社サイバーエージェント これまでの経緯 • 2010年 ７月： 初期リリース (CDH3b系) • 2011年 ３月： CDH3u0にアップグレード ９月： 独自開発のワークフロースケジューラ、サマリDBとしてHBaseを導入 • ２０１２年 ５月： スマートフォンプラットフォーム向けPatriotの構築 (CDH3u3) １０月： ログ収集にFlumeを導入（Apache Flume1.3） • ２０１３年 ３月： 外部連携サーバ（Patriot Bridge）の導入 ７月： PatriotのDC移設、CDHアップグレード(CDH4.3) GHE、Jenkinsを用いた運用フローの見直し ８月： スマートフォンプラットフォーム向けPatriotを統合 10
- 13. 株式会社サイバーエージェント ワークフロースケジューラ • MySQLでジョブと依存関係を管理 • 設定ファイル一つでジョブ追加可能 ジョブ管理DB (MySQL) ジョブ登録 (cron) ワーカー (ruby daemon) Hiveクエリ (*.pbc バッチ設定 (*.pbc (rubyDSL)) (rubyDSL)) (*.pbc (rubyDSL)) ログ取り 込み ワーカー (ruby daemon) ログ転送 レコメンド バッチ 13
- 14. 株式会社サイバーエージェント ジョブ設定DSL • 柔軟なジョブのグループ化により細粒度の依存関係を簡潔に記述 • プラグインとしてコマンドを追加可能 ジョブをグループ化し job_group{ 依存関係を設定 require ['base_tbl_#{$dt}'] Hiveクエリを hivequery{ 実行するコマンド require ['tmp_tbl_#{date_sub($dt,1)}'] produce ['tmp_tbl_#{$dt}'] 日を跨ぐ hiveql 'INSERT OVERWRITE ...' 依存関係 } hive2hbase{ Hiveの結果を require ['tmp_tbl_#{$dt}'] HBaseにPutする hiveql 'SELECT count(distinct id) FROM ..' コマンド } } 14
- 17. 株式会社サイバーエージェント バッチ設定のレビュー •可能な部分はJenkinsで自動化 • 構文チェック • キーの重複検査 •テンプレートを用いた効率化 • バッチ設定はERBテンプレートが利用可能 • 共通指標はテンプレート化しレビューを省略 •現在さらなる自動化を検討中 • クエリをパース・分析するライブラリを開発 • パーティションの選択の有無などレビュー時に必要な確認を自動化 • 最適化、リファクタリング • クエリの複雑さを計測 など 17
- 18. 株式会社サイバーエージェント テンプレート化の例：アクセスログ解析 PV, レイテンシなど約20項目の集計を１つのテンプレートで設定 job_group{ # ログ取り込み設定、前処理など } import_erb_config 'accesslog_analysis_daily.erb', {'service'=>'blog', 'dev'=>'pc', 'paths' => { # 集計対象URL ... } } • PV • • • 日別、時間別 デバイス、OS別 レスポンスタイム • 中央値 • 最小、最大 • 上位、下位5%値 など 18
- 24. 24 Patriotへのログ転送 • 2012.05以前 SCPでログ転送 • 2012.05 Scribeを使ったリアルタイムなログ転送を一部で開始 • 2012.10 ScribeをFlumeに置き換え、Amebaサービスに導入開始 • 2013.01 Patriot以外のシステムへの転送も開始 • 2013.09 主要AmebaサービスにほぼFlume導入完了 • 2013.11 Ameba SAP(CAグループ)のログ収集を計画中
- 25. 25 Patriotへのログ転送 • Flume導入サービス ： 80 service (導入拡大中) • ログの種類 ： 160 log type (service×log type) • 導入ホスト数 ： 1,000 host • ピーク時 ： 90,000 lines / sec • サイズ（Raw） ： 1.0 TByte / day
- 27. 27 Flume Collector • 収集対象ファイルが出力されるホストで起動するFlume Agent。 • 収集したログはAggregatorに転送する。 • Flumeの設定 • • • 秒間1000linesほどのログでもヒープは128Mで十分。 監視としてMBeansの各種メトリクスをGangliaに送信。 アラート監視にはJolokiaを使ってhttp経由でMBeansを参照。 http://www.jolokia.org/ ※リアルタイムにMBeansを見るときはVisualVMなどを使用。 Collector Intermediate Aggregator Collector Intermediate Aggregator Collector Final Aggregator
- 28. 28 Flume Aggregator • Intermediate Aggregator • • • Final Aggregatorにログ転送するFlume Agent。 ルーティングの中継としてDC毎に設置。 スペック ： 物理×2 / 4Core / Mem8G / RAID1 × 2 VM×3 / 4Core / Mem8G • Final Aggregator • • • 転送されたログを最終的に集約するFlume Agent。 HDFSなどへの書込み、他システムへのルーティングをする役割。 スペック ： 物理サーバ×5 / 4Core / Mem24G / RAID1 × 2 Collector Intermediate Aggregator Collector Intermediate Aggregator Collector Final Aggregator
- 29. 29 ログ転送で使っている機能 • Channel Selector ： 他システムへの振り分け、Multiplexing • TimeStamp Bucket ： 日時などでBucketingしてHDFSに書込み • Reset Connection ： LoadBalancer経由のログ転送 • Deflate Compression ： 圧縮転送 • HBase sink ： HBaseに書込み • File Channel ： ロストを許さないログで使用（集計 / 監視） • Memory Channel ： 若干のロストを許容するログで使用 （Recommend / Trend）
- 30. 30 Channel Selector • Flume Agent (JVM) 機能 • Sourceで受け取ったログを指定したChannelに流し込む。 Source • 複数のChannelに同じログを同時に転送も可能 （Multiplexing）。 この機能で他システムへの振り分けをしている。 Selector • • これで同じログを他システムで重複して取得 する必要がなくなった。 • optional channels(FLUME-1768, 1769)が実装された CDH4.2.0以降のものが使い勝手がよい。 Channel Channel Channel Sink Sink Sink • optional channelsはもしChannelへのputを失敗してもリトライしない設定。 • リトライしないことで他の重要なChannelに影響を及ぼさない。 • Memory Channelのようなロストを許容できる場合との組合せに適している。
- 31. 31 TimeStamp Bucket (HDFS Sinkの機能) • 機能 • HDFSに書込みむとき、ログのHeaderのTimeStampを元に日付や時間で 正確にBucketingできる。 hdfs://namenode/flume/%{header1}/%{header2}/%Y-%m-%d/%H/ • TimeStampをsetするInterceptorについて • • Flumeの TimestampInterceptor では転送時の現在時刻をTimeStampとするが ログの日時をパースするように自社でInterceptorを独自実装。 JSON、TSV、Syslogなど多様なログに対応。
- 32. 32 Reset Connection • 機能 • • Collectorで転送先をLoadBalancerにするときに使用。 指定した間隔でLBに再接続するので、LBに登録した host:port に分散して転送ができる。 agent.sinks.avro.reset-connection-interval = 60 • 使用経緯 • • • Flumeの設定で元々LoadBalance機能はあるが、100近いサービスを 横断した設定ファイル変更はChefを使っているとはいえ手間。 設定ファイルでは宛先をLBのIPにして、LBの設定を変えるだけで 転送先の増設などに対応できる。 弊社FlumeコミッターのJuhaniが作ったパッチで稼働中。 (FLUME-2154, CDH5.0.0 beta1で適用) Collector Load Balancer Aggregator Aggregator Aggregator
- 33. 33 Deflate Compression • 機能 • Avroを使った転送で圧縮した転送ができる。 agent.sinks.avro.compression-type = deflate • ZlibEncoder と ZlibDecoder を用いて通信を圧縮している。 • ネットワーク負荷を数分の一に低減できる。 • CDH4.3.0以降のもので利用可（FLUME-1915）。
- 34. 34 HBase Sink • 機能 • • • • • 転送したログなどをHBaseに保存できる。 HBase SinkとAsync HBase sinkの2タイプがある。 Async HBase sinkの方が高速。ただしHBase Sinkにあるケルベロス認証は 非サポート。 Async HBase sinkを使うにはHBaseのvalueをLong型にする必要あり。 HBase SinkのSerializerをフォークして作りこみ、ストリーム処理した結果を Patriotのデータ構造に変換してHBaseにリアルタイム反映するのに利用している。 処理結果を Serializerで変換 Aggregator HBase クラスタ
- 35. 35 コンポーネントのカスタマイズ • カスタマイズしたコンポーネントをFlumeに簡単に組み込める。 • Jarファイルにして /usr/lib/flume/lib などに配布して 下記のように指定する。 • このようにしてFlume自体に実装されてない機能、独自システムとの 連携などに対応できる。 # example agent.xxx.custom.type = [カスタマイズしたClass名やMethod名など] agent.xxx.custom.channel = ch1 agent.xxx.custom.port = 12345 ※ xxx : sources, channels, sinks などのコンポーネント
- 36. 36 コンポーネントのカスタマイズ - HBase Sink • typeには自分で作ったClass名を指定。 ※ type = hbase と指定した場合はデフォルトのHBase Sinkになる。 • serializerのみClass指定することもできる。 • 設定項目もカスタマイズできる。 agent.sinks.hbase.type = jp.co.cyberagent.flume.sink.hbase.PatriotHBaseSink agent.sinks.hbase.serializer = jp.co.cyberagent.flume.sink.hbase.PatriotSerializer agent.sinks.hbase.channel = ch1 agent.sinks.hbase.table = table_name agent.sinks.hbase.columnFamily = data agent.sinks.hbase.custom = custom 処理結果を Serializerで変換 Aggregator HBase クラスタ
- 37. 37 コンポーネントのカスタマイズ - Channel Selector Flume Agent (JVM) • デフォルトのSelectorは1headerでのみの判別になるが、 複数headerをみてChannelに流し込むようにカスタマイズ。 Source Selector • 設定例 • applog で、サービス名が「girlfriend」、行動タイプが spend のログは hdfs-ch と spend-ch の両方に流し込み、 • applog.girlfriend.spend default trend-log は trend-ch に流し込み、 • trend-log それ以外のログはデフォルトで hdfs-ch だけに流し込む設定。 trend-ch hdfs-ch spend-ch Sink Sink Sink agent.sources.avro.selector.type = jp.co.cyberagent.flume.selector.MultiHeaderSelector agent.sources.avro.selector.headers = category,service,type agent.sources.avro.selector.required.trend-log = trend-ch agent.sources.avro.selector.required.applog.girlfriend.spend = hdfs-ch spend-ch agent.sources.avro.selector.default = hdfs-ch
- 38. 38 スケールアウトについて Channel • Final Aggregator - HDFS Sink • • HDFSへの書込みは最初は1Channel ： 1HDFS Sinkで十分。 基本的にはホスト追加でスケールアウトできる。 • もし転送量が大きくなり(秒間数万とか)リソースが余ってるのに スループットが出なくなったら、hdfs.batch-sizeを上げるより 1Channelに対してHDFS Sinkを並列化する方がスケールする。 http://blogs.apache.org/flume/ • • 1ホストにおいてもChannelを複数に分けた方がスケールする。 Channel HDFS Sink 1Channel ： 2HDFS Sink （2並列） より並列数を増やしても スケールはあまりしない。 ※同時書込みファイル数が1万近い場合 Performance Test by Cloudera HDFS Sink Channel HDFS Sink HDFS Sink HDFS Sink Channel HDFS Sink HDFS Sink https://cwiki.apache.org/confluence/display/FLUME/Flume+NG+Syslog+Performance+Test+2012-04-30
- 39. 39 スケールアウトについて • Intermediate Aggregator • • • 他のホストに転送するだけなら大きなサーバリソースは不要。 Collectorが100台ほどでもホスト2,3台の冗長化構成で十分。 もし負荷が高くなってもホストを追加すればスケールできる。 • Aggregator共通 • File Channel より Memory Channel の方が低レイテンシでスケールしやすい。 • File Channelを使っていてログ量が大きければ物理サーバ、 そうでなけばVMで基本問題なし。 • File Channel で物理サーバの場合、I/O負荷低減のためディスクを2つ用意し 下記のようにPartitionを分けるとよい。 /data1 ： checkpointDir用のパーティション /data2 ： dataDirs用のパーティション
- 40. 40 HDFSに保存したログの重複について • HDFS Client にはトランザクションの仕組みがなく、HDFSとの通信で タイムアウトなどが起こると、成功したか分からないものは処理を やり直すため若干の重複が起こりえる。 • HDFSに書き込む batch-size が大きいほど重複は起こりやすい。 • 重複率は0%〜0.005%程度。 ※秒間1000linesほどのWebサーバのログ、batch-size=100の設定で調べた結果。 • 重複を許容できなければMapReduceでユニークにするなどで対応する。 • 逆にデータのロストは File Channel を使えば発生しない。 ※Memory Channelは停止前にChannelにデータがあれば、 その分は失われるしまう。その代わり、パフォーマンスが高い。
- 41. 41 過去のトラブル解決 • HDFSへの同時書込みファイル数のlimitに達した • • Flume Aggr側 ： ulimitの上限を65536に変更。 DataNode側 ： Xceiverの上限引き上げ。 • 起動時のReplayに時間がかかる場合 • • ChannelSizeが数千万以上溜まったときに稀に発生。 use-fast-replayをtrueにするなど他のReplay方式を試すと速く終わることも。 • File ChannelのCheckPointでファイルのlock取得でタイムアウト • • • I/O負荷が高いホストで発生。 I/O負荷の原因となっている元を解消する。 もしくはFile Channelの設定で write-timeout の値を引き上げ(default：3秒)。
- 42. 42 今後の展望 • Flume導入範囲の拡大 • SSL通信機能(FLUME-997, CDH4.4.0で実装)の検証 • Final Aggregatorの負荷軽減 • HDFS上に作るファイル単位ごとに担当するAggregatorを振り分ければ より少ないサーバリソースでHDFSへ書込みできそう。
- 43. 43 まとめ • Amebaのログ解析基盤Patriotについて • GithubEnterpriseとJenkinsを用いて他部門が利用できる体制 • データマイニングエンジニアやレポーティングツールとの連携 • FlumeでHadoopクラスタへリアルタイムに大規模なログ転送を実現 • HDFSへの書込みだけでなく、一度のログ転送で同時に他システムへ ログを流し込み、ネットワーク負荷を軽減
- 44. 44 最後に • 以前の発表 • Patriot （Hadoop Conference 2011 winter） http://www.slideshare.net/toutouzone/hadoop-conferencejapan2011 • Flume （Hadoop Conference 2013 winter） http://www.slideshare.net/iijiji0314/flumeameba • Onix （Data Stream Processing and Analysis with Akka @ Scala Conference 2013） http://www.slideshare.net/romanshtykh/data-stream-processing-and-analysis-with-akka
- 45. 45 最後に • Ameba Technology Lab ではエンジニアを 募集しています！ http://www.cyberagent.co.jp/recruit/career/ • Hadoop / データマイニング / 機械学習/ 検索 などに 興味がある人はお声がけください。
- 46. ご清聴ありがとうございました。