Fluentdの現実装のPros/Cons - Go ahead!
TODO: 必要なら図を足す 他に書いた方が良いPros/Consのリクエストがあったら追記 内部のイベントストリームの扱い Pros: Inputがスケーラブルに実装しやすく，データストリームを正常時/エラー時で切り替えやすい Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい 以下長々と理由書きます． Fluentdはイベントストリームを効率良く，またロバストに扱うことを目的に設計されています．そのため，独自の転送プロトコル(forwardプラグイン)を実装していますし，内部のイベントのハンドリングもそれに沿うようになっています．ただ，それによって相性の悪い操作とかもあります． Fluentdはバッファ機能を提供しており，これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています．が，あまりにも書き込み先が遅いなどの問題があると，バッファの制限を超えて
Fluentd v0.12でのFilterとLabel - Go ahead!
Fluentd，最近だと海外でも露出が増えてきていて，軽量・柔軟・ロバストという所で， 新規の他，既存のログコレクタのリプレース含め，採用する所が増えてたりします． より改善するため色々とユーザにヒアリングした結果，「フィルタ機能が欲しい」というのが一番多い意見でした． Fluentdは元々Treasure Dataへロバストにデータを転送するためのミドルウェアで，「ETLとかはTreasure Dataで」 というのもあり，組み込みでフィルタ機能はありませんでした． 今現在のOutputプラグインによるフィルタ実装は，タグの書き換えが必要だったりして少し慣れが必要で，初心者にはちと難しい． ということで，より簡単に効率よくデータストリームを扱えるフィルタ機能を入れることにしました！ 前置きが長くなりましたが，次のバージョンであるv0.12ではFilterとLabelの導入が目玉機能になり
ServerEngine at RubyKaigi 2014 - Go ahead!
RubyKaigi 2014でServerEngineについて発表してきました． 最初はFluentdで発表しようかと思ったんですが，別の有用なプロジェクトの話もそろそろした方がいいかな，ということでServerEngineにしました． @sonotsさんがFluentdの発表をしてくれたので，被らなくて良かった… 画像は技評さんから． 以下がスライドです．書いてないことも発表では色々と話したので，動画もセットで見た方が良いです． fluent/serverengine ServerEngineはTreasure Dataで開発・運用されている分散キューや分散スケジューラ，それとFluentdなどの経験を元に，汎用的な部分を抽出してフレームワークにしたプロダクトです．発表で言及した機能の他にもBlockingFlagなどのユーティリティがあるので，Rubyでデーモンやバッチワーカーを書くと
Fluentdとログ収集のパターン - Go ahead!
「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末
MPP on Hadoop, Redshift, BigQuery - Go ahead!
Twitterで「早く今流行のMPPの大まかな使い方の違い書けよ！」というプレッシャーが半端ないのでてきとうに書きます．この記事は俺の経験と勉強会などでユーザから聞いた話をもとに書いているので，すべてが俺の経験ではありません(特にBigQuery)．各社のSAの人とかに聞けば，もっと良いアプローチとか詳細を教えてくれるかもしれません． オンプレミスの商用MPPは使ったことないのでノーコメントです． MPP on HadoopでPrestoがメインなのは今一番使っているからで，Impalaなど他のMPP on Hadoop的なものも似たような感じかなと思っています． もちろん実装の違いなどがあるので，その辺は適宜自分で補間してください． 前提 アプリケーションを開発していて，そのための解析基盤を一から作る． 簡単なまとめ データを貯める所が作れるのであれば，そこに直接クエリを投げられるPre
CROSS 2014 - Go ahead!
CROSS 2014というイベントがあり， 分散処理システムCROSSというセッションのオーナーをやってきた． 分散処理システムCROSS 元々はログ収集で1セッションどうか，という話だった．が， もうFluentdとかの話は色々な所でやってるし，ここで1時間やってもあんま成果はないだろうということでやめた． そもそも日本でFluentd以外のログ収集プロジェクトで深い話を出来る人は希で，探すのがつらい． その変わり分散処理でも話が来ていたので，そっち側でどうにかやることにした． 分散処理だとなんかアルゴリズムとかそっち系の色が強くなりそうなので，とりあえずシステムをつけた． メンバ @oza_x86，@kuenishi，@shot6の三人にお願いした．時間を作って頂いてありがとうございました！ 人選に関しては，少し前にTwitterでつぶやいたけど，以下のような感じで選んだ． 分散処理シ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
