Prestoのフォースを感じたので,知り合いが試した情報も含めて,今思っている所を書いてみる.
Athenaのページにあるように,実行エンジンは独自実装ではなくて,Facebookが公開しているPrestoを使っている.FacebookのみならずTreasure Data,Airbnb,Netflixなどクエリがガンガン飛ぶ環境で元気に動いている実績もあるので,拡張性,パフォーマンス,安定性で選ばれたのだろうと思われる.あとAWS的にJavaの方が相性は良さそう.
いくつかの記事で言及されている.
これらを見ると,Prestoをそんなに改造せずに動かしている感じ.例えばGunosyさんやclassmethodさんの記事ではとりあえずフルスキャンをするcsv.gzの方がParquetより速い.データ量が少ないのとクエリが単純なので誤差の範囲に収まってる可能性もあるが,ParquetのReaderをAthena向けに改造している感じはしない(TQA(TDのPresto)の場合,PlazmaDB向けに色々と最適化したReaderを実装してパフォーマンスを稼いでいる(参考)).
AWSがGoogleのColossus相当を持っているという話は聞かないものの,それでもBigQueryに近いパフォーマンスが出たりもするようなので,1クエリで多めにワーカーを使っているんじゃないかと思っている.TQAがクエリによっては同じデータ量でBigQueryとかその他DWHより高速に動いたケースってのはいくつかあるので,Prestoを使っているAthenaでも同様になると思われる.
あと細かなところだけど知り合いの試した情報によると,TQAとかBigQueryはキューイングされてから実行が完了するまでの実行時間が表示されるが,Athenaはクエリが走り始めてから完了するまでの時間しか表示されてないようなので,キューイングまわりで時間が掛かっている場合,体感と表示時間にかなり差があくようだ.
1クラスタに数千ワーカー(今のPrestoだと万は怪しい?)があって,そこにユーザが割り当てられ,そこの中でさらに適宜ワーカーを選んで処理をしている感じ.
Amazon AthenaでCloudFrontログをSQLで解析する #reinvent #athena
例えばこの記事の最後に「同じSELECTでも数秒で終わるものが時間帯によって数百秒かかることがあったり」というのがあるので,リソースが空いてるワーカーやクラスタをちゃんと選んでいるのではなくて,おそらくランダムか割り当て回数が少ないワーカーを選んでいるっぽい.この辺はBigQueryと同じで,実際複数ユーザが投げ続ける環境だと空いてるワーカーをクエリ負荷含めて探すのはかなり難しいので,この手のアプローチがシンプルでそれなりによく動く.
ただ,知人の試した結果だと,1時間弱くらいResourceUnavailableで弾かれ続けた,みたいな状況もあるようなので,重めのクエリを投げ続けると制限されるのか,ユーザのクラスタ割り当てが一定時間は固定で,ビジーなクラスタに割り当てられるとクエリが失敗しやすくなるのかもしれない.
Athenaのページに同時実行数に関する記述がないので,この辺どれだけ絞っているのかよく分からないのが悩ましいところ……
どうもPresto内部でいくつかエラーを握りつぶしているっぽい.これはBigQueryもそうなんだけど,多分そのエラーによってクラスタの状態とかバックエンドの詳細が分かってしまうので,「とりあえずエラー」みたいなのを返しているようだ. エラーが起きたらとりあえずretryする感じになりそう.
ユーザが目に見えるところだと,DDLとか禁止されているクエリ周り.例えば運用上発行されたら困るDDLとかはもちろん弾かれるし,生のPrestoとかTQAだと通るクエリがAthenaではエラーになったりすることもあるようなので,その辺は運用との兼ね合いで禁止しているようだ.
あと当たり前だけどHiveのmetastore周りはAWS向けに専用サーバを実装しているっぽい.
ここは思いっきりBigQueryを参考にしているようだ,がBilling Tierみたいなのはない.いずれ入るかもしれないが,AthenaはBigQueryのようにバッチとか含めてDWH的に使わせる気はあまりないようなので,当分ないだろうと思っている. ただ,AWSは既存のうまく行ってるサービスを自社サービスに取り込んで提供する傾向が強いので,今後BigQueryに寄せていく可能性はありそう.
Athenaは様々なフォーマットに投げられる一方,jsonやcsvみたいなオブジェクトを対象にすると強制的にフルスキャンになるので,その分課金がバーストしやすい.列指向にするにはEMRのSparkとか使って行うのが鉄板のようだ.
あと当たり前だけどS3に対する保存・APIリクエスト・データ転送分も別途課金されるので,1TB per 5$ + additionalというのは気をつけてないと,想像より課金されてた,みたいなのが起きやすそう.特にデータ転送量.
結構TLとか見てると,「BigQueryの対抗だ!」みたいなtweetを見かけたりするけど,個人的にはあくまでManaged Prestoって感じでまだ対抗みたいな感じはしてない.今後,ヘビーユーザが増えた時にどこまでうまくworkするのかは気になっているところ.
出来れば,AWSからPrestoにガンガンパッチとかFeature Requestが飛んでくれると嬉しいなぁと思ってます.
]]>上の記事がTLで結構話題になっていて,そういえば昔TinySegmenterをD言語で実装したなぁと掘り起こした(TinySegmenter written in D).5年前のコードだったけど最新版でもさっくりと動いたので,どれくらいか比較のためにベンチマークを取ってみた.
結果としては,Juliaには勝てなかった.コードを読んだ限り,Julia実装は他のとは違って中間のsegmentsリストを作らなかったりとか最適化がちょくちょく入っているので,この辺D言語でも頑張れば近いパフォーマンスは出せそう.
ベンチマークしたのは手元のMBP.それぞれの処理系は*env
で入れたりhomebrew
を使って入れたりした.
上の記事のベンチマーク結果は,Pythonのベンチマークだけループ回数が100じゃなくて10だったり,Juliaの実装にTC1などのスコアリングがなかったりといくつか完璧ではないので,修正した後にchezouさんが再度計測しなおすと思われます(すでに本人には報告済み).
以下手元でのベンチマーク結果.速かった順.
masterだとTC1とかの修正が入ってます.
1 2 3 |
|
1 2 3 |
|
1 2 3 |
|
高速化したバージョン.パッチはすでに本家に投げました(Improve performance by repeatedly · Pull Request #1 · 6/tiny_segmenter)
1 2 3 |
|
Python 2の方は3.5に比べて遅いらしいのでやってない.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
上のイベントに参加してました.普通の感想は他の人が書くと思うので,質問した内容とその返答を書いておきます.
現状はエラーになる.
DrillはSchema on Readに加えて,データ読み込み時にスキーマを自動で生成する機能もある(Embulkのguessみたいなもの).JSONとかのローカルファイルに対してクエリ投げる時は,いちいちスキーマを自分で設定する必要がなくて便利なのだけど,さすがに後半のデータで急に型が変わったりフィールドが増えたりすると,クエリ処理を続行できないとのこと.
そういう時はちゃんとスキーマを事前に定義する必要がある
現状その手の機能はない.並行で処理するクエリの数は制限できる.
Prestoだとクエリ毎にメモリ使用量とかを制限できて,それによってどれだけクエリが投げられても,ワーカー群はかなり安定して処理を実行できるようになっている.現状のDrillユーザは,あらかじめどれだけメモリを使うかなどを測定して,それに見合ったクラスタを構築しているらしい.
1クラスタ100台の事例はある,とのこと.
Prestoだと1クラスタ1000台とかの事例はあるけど,これを聞く限りまだ大規模での事例はそこまでないようだ.ここは後発なのものあって,今後事例は出てくるかもしれないが,上で言及したリソース制御とかがないと,大規模での運用は結構厳しそう.
Window関数相当のSQLを頑張って書いているか,自分達でDrillを拡張しているかのどちらか.
Drillは現状の1.1だと,Window関数とかはあまりサポートされてなくて,Presto/Impalaで使える便利関数群が色々と使えない.今Drillを採用している人達はどうやって様々な分析をやっているのか,というのは運用・自社開発でカバーという感じらしい.この辺がこなれないと,普通の人達が使うのは結構厳しい感じ.
上がMapRの人達に聞いた内容.後発なのでPrestoなどの良いところを取り込んでいるものの,まだ成熟してない感じなので,プロダクションで使うには運用でカバーしないといけない箇所が結構あるなぁという.
ApacheプロジェクトだしMapRがかなり開発リソースを割いてる感じなので,上記の問題群はいずれ解決されるだろうとは思いますが,Presto/Impalaもかなり開発が活発なので,どこまで差別化出来るのかが今後の注目ポイントになりそう.
俺も時間を作って色々とチェックしてみるか…
]]>今年で最後となるYAPC::Asia Tokyoで,データ分析基盤まわりについて発表してきました.部屋は満席だったようで,聞きに来てくれた皆さん,ありがとうございました.会場はD言語erにふさわしくD会場でした.
データ分析基盤を支える技術 - YAPC::Asia Tokyo 2015 これが今どきのデータ解析基盤だ!初心者のためのデータ解析講座 #yapcasia #yapcasiaD - Togetterまとめ
どういう展開にしようか悩んだんですが,データ分析基盤の構築に使われる様々なソフトウェアが,どういう問題を解決するために導入されているのか,またその一方どういう問題を持っているのか,を一からデータ分析基盤を作るという流れで話していくことにしました.
既にガリガリやっている人向けではなくて,これからやろうとしている人,やってるけど現状の仕組みだと厳しくなってきたので今後どうしようか考えている人,などの参考になればと思っています.
データ分析周りに興味があった人が結構聞きに来てくれたらしく,全体の流れを俯瞰できて良かった,みたいな感想もチラホラ見受けられたので,この構成にして良かったな,とホッとしています.
スライドのまとめにも書いていますが,Treasure Dataなどのデータ分析基盤や,AWSやGCPやAzureのような分析基盤を作るためのコンポーネントを提供しているクラウドが増えているので,自分で一から構築する必要性はかなり低くなっています.「どういうソフトウェアがありどういうことが出来るのか」を知っておくのは重要ですが,なるべく便利なサービスを利用して,ビジネスに集中した方が良いでしょう.
SparkやFlink,その他可視化,機械学習,データパイプラインなども話したかったんですが,時間が足りなかったので,これらはまたどこかでチャンスがあれば話しても良いかなぁと.
上のtogetterのまとめには質疑応答に関するtweetはまとめられてないようなので,気になる方はいずれアップロードされる動画を見てください :)
]]>データ分析基盤を支える技術 - YAPC::Asia Tokyo 2015
Abstractに書いてあるとおり,そんな感じの話を60分かけてします. 各ソフトウェアとかの詳細に言及すると60分に収まらないので,深い話とかは 別途飲み会とかでしましょう(トークが落ちてもちゃんと参加します!).
YAPC::Asia Tokyo 2015 Talk Ranking
現在30位前後で受かるかわかりませんが,聞きたいトークがいくつかあるので, 裏番組にならないことを祈るばかりです…(-人-)
]]>募集が約2週間前とかなり直近になってしまったんですが,100人以上の方の参加がありました.場所を提供してくれたgloopsさん,受付などサポートしてくれたdots.さん,懇親会などをスポンサーしてくれたTreasure Dataさん,発表者の方々,また当日参加してくれた皆さん,ありがとうございました!
Eduardoが東京の地下迷宮に迷ったりとハプニングも少しありましたが,無事終わって良かったです.fluent-bitのお披露目を兼ねたイベントでしたが,さっそくパッチを送ってくれてる人もいて,正式版リリースはまだですがフィードバックをガンガン貰えればという感じです :)
また,他の方の発表も,Fluentdを単なるログの収集だけではなく,工夫して色々と実現されているのも良い知見になりました.やはりプラグインで柔軟に弄れると,利用の幅が広がって面白いですね.
次は秋か冬辺り,v0.14のお披露目もかねて開催出来ればと思っています.
俺が行った発表はタイトル通りv0.12に関する発表です.
v0.12から追加された機能について,細かいものから目玉機能でもあるFilterやLabel,at-least-onceなどについても再度一から説明した感じになります.
v0.10を使っている方は,このスライドを見ればv0.10とv0.12の差分が分かると思います.td-agent 2.2からは同梱されているFluentdはv0.12になっているので,どんどんFilterとかを使って行きましょう.secretオプションとかは最近入ったばかりなので,次リリースされるtd-agent 2.2.1から使えるようになります :)
他の方のスライドは上に貼った募集ページの”イベントレポート”の所にあるので,興味のある方は是非チェックしてみてください!
]]>以下長々と理由書きます.
Fluentdはイベントストリームを効率良く,またロバストに扱うことを目的に設計されています.そのため,独自の転送プロトコル(forwardプラグイン)を実装していますし,内部のイベントのハンドリングもそれに沿うようになっています.ただ,それによって相性の悪い操作とかもあります.
Fluentdはバッファ機能を提供しており,これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています.が,あまりにも書き込み先が遅いなどの問題があると,バッファの制限を超えてしまうことがあります.
この時,FluentdはInputプラグインにエラーを返します.これによりInputプラグインはさらにエラーを外部にも伝搬させることが出来,forwardプラグインなら再送や,エラーが続くようならセカンダリに流すなどが出来るようになっています.これはデータストリームを流し続けるため,またInputプラグインがブロックせずに大量の入力を扱えるようにするため,こうなっています.
このモデルは,データがストリームではない過去ログの一括転送などと少し相性が悪いです.例えばtailを使って過去ログをElasticsearchに一気に流す時によく問題に当たるのですが,Elasticsearchは1台だと受け付けられるデータ量はそれほど多くなく(ここはチューニングに左右されます),大量の過去ログを一気に送ろうとするとOutputプラグインのフラッシュ処理が追いつかなくなり,結果バッファが溜まりリミットを越え,Input側にエラーが返り続けることになります(tailの場合はひたすらリトライ).
一方,Elasticsearchと一緒によく使われるLogstashはFluentdとは違うアプローチをとっています.内部には長さ固定のブロッキングキュー(Outputのバッファではない)がInputとOutputの間に存在しており,Inputはそのキューがあくまで処理がブロックします.
そのため,上記のような過去ログの転送などでは,キューが空くまで処理は行われないので,Output側が詰まってもエラーなどにはなりません.その変わりブロックしているため,外部からデータが送られてくるようなケースにおいては,このブロックがどんどん伝搬していくので,大量・多数の入力を捌くのが難しくなります.
この辺に関しては最近のイベントでも言及されてました(ここで言われているログが抜ける云々はInput側の問題ではなくて,ESが高負荷になりすぎてES側でrejectされてるんだと思います.この記事参照).
fluentdは日本では流行ってるけど、キューがあふれるとキューに入りきらなかったログが抜けることがある、logstashなら大丈夫なので、大量の過去ログ投入するといはlogstashがおすすめ。 #jdt54 #JavaDayTokyo
— mogami (@smogami) April 8, 2015
これらのモデルの差は
という出生の違いによって生まれているのかなぁと思っています.
実のところFluentdで過去ログを転送している人はいて大きな問題にはなってないのですが,どうしてもキャパシティが足りないところに無理にやろうとすると,上記のElasticsearchのような問題が起きたりするので気をつけましょうという感じです.(一括転送専用にバッファをチューニングするのは面倒だったりしますし…).
実際1レコードずつSQL発行してinsertを行うmysqlプラグインでも,最近同じ問題が起きてました.これはバルクロード版で解決しました.
今だとEmbulkがあるので,大量データの一括転送はそちらを使ってくださいという流れになりますが,ブロックする挙動があっても損はないとは思うので,うまくバッファのAPIが整備出来れば,back-pressureっぽい機能は入れようかとは思ったりはしてます(fluent/fluentd #569).
今回はFluentdとLogstashしか言及してませんが,他にもいくつかログ収集のプロダクトは存在しているので,上記のイベントのライフサイクルや,転送プロトコルでどういうセマンティクスがあるのかなどは,使う場合には一通りチェックした方が良いと思います.
]]>書くの遅れましたが,先月の末に行われたDevelopers.IO 2015で,登壇してました.
発表スライドは以下です.
Developers Dayの日で「なるべくニッチな話をしてください」と言われたのと, TD Techtalkに参加出来なかった人も見に来るというのもあったので,Treasure Dataのデータインポートとかクエリ処理周りの 内部処理的な話をしました.
Treasure Dataみたいなサービスを自力で作る人は少ないとは思いますが, 昨今データ解析周りの需要は増えているので,もし社内でそういう案がある人の参考にでもなればという感じです. といっても,クラスメソッドさんのイベントでもあり,AWS要素多めの内容になっています.
一番最後に決まったセッションだったんですが,部屋的には埋まっていた感じなので良かったです.クラスメソッドさんのまとめやtogetterのまとめは以下にあるので,参考にしてみてください.
SAPさんの会場で,複数のトラックで行われており,盛況でした.興味があったものの参加出来なかったセッションがいくつかあったのが心残りといえば心残り.最後の抽選では色々と欲しいものがあったものの,残念ながら手に入れることは出来ませんでした.また似たようなイベントがあったときにはリベンジしたい…
クラスメソッドさん勢いあるなぁと感じたイベントでした.まだまだこれからも色々とやるようなので,盛り上げるのに今後も協力出来ればという感じです.
皆さんお疲れ様でした!
]]>DeNAでVerticaの勉強会が開かれるということで行ってきた.皆さんお疲れ様 & ありがとうございました.
VerticaはMPPデータベースと呼ばれるプロダクトの一つ.まとめみたいなのはすでに他の人が用意してくれているので,そちらを参照してください.
Verticaの基本的な話.C-Storeが元になっていて, やはりC-Storeの論文に書かれている機能がベースになってた.
ここで出てきた
とかはMPPでは基本的な特徴で,それらを一通り持っている感じ.
少し珍しいものとしては,マルチマスタみたいにすべてのノードがクエリを受け付ける所.
複数クエリが飛んでいる時にどういう負荷分散をするか分かってないけど,クエリを投げた時にあるノードが自動でリーダーになるっぽい.
Impalaも似たような仕組みだけど,Statestoreみたいな外部サービスすら存在してないようなので,
クラスタがどういう風に状態を共有しているのかが,個人的には気になっている.
あとで言及するけど,DB Designerというツールが一番の肝.
DeNAでどうやってVerticaを利用しているかの話.まだPrestoやImpalaが広まる前から利用しているようで, やはりHiveやPigをAd-hocクエリの代わりに使うのはつらかったという.
もちろんすべてをVerticaでやっているわけではなくて,データはHadoopクラスタにも入れていて,
でかいサービスなどの場合はHadoopで中間データをつくってVerticaに入れているという,よくある構成.
ストレージと密結合しているMPPデータベースはこまめなロードが大抵苦手なので,
データ量が大きいところでは皆この構成を取っている.
lead
とかlag
とかのWindow関数はHiveやPrestoでも使えるんだけど,timeseriese
というgap-fillingな関数は少し面白いなと思った.
FluentdとKafkaを使ってデータを収集している話があって,ここでもFluentdが!
ここでHadoopを機械学習にも使っているという話をしていた.何のプロジェクトを使っているんだろうか?懇親会で聞くの忘れてた.
運用に関して色々とTipsを話されていて,参考になる発表だった. データインポート時に型が一致してないレコードをデフォルトで捨てるのが,なかなか豪快だなぁという感じ.
あとクエリは基本Resource Poolで細かく制御するのが複数ユーザで使う時の前提. これはどこのMPPデータベースでも同じで,何もしないと一人がでかいクエリ投げると他の処理が止まってしまう.
「Verticaがすごい」という話だったんだけど,テスト内容の詳細がなくて, どういうスキーマで,どれくらいのデータがあって,どういうクエリかが分からずかなりふわっとしていた. あとグラフに目盛りとかもなかったので,さらにすごさがよく分からなかった…
お客さんのテスト結果ということらしいので詳細を話せないのは分かるのだけど, こういうオープンなイベントだとTPCとか使って分かるデータで見せないと, ちょっと厳しいかなぁという感じ(特にパフォーマンスとかを気にするエンジニアには).
Verticaでのテーブルは単にどういうカラムがあるかというスキーマを持っているだけで, 実際にデータを保持するのはプロジェクションという単位.誰かがtweetしていたけど,Materialized Viewみたいなもの.
ここでDB Desingerというのが使えて,データやクエリを登録すると,それに最適なプロジェクションを構築してくれるらしい. プロジェクションは一つのテーブルに何個も構築出来るので,それぞれ必要なプロジェクションを作っておけば, 後でクエリエンジンが勝手に最適なプロジェクションを選んで実行してくれる.
Vertica,てきとうにやっても速い,みたいなの前聞いたことあったけど,実際はDB Designerにお任せという感じのようだ. DB Designer便利だけど,当たり前だけどプロジェクション作るとそれだけ容量食うので,作りすぎに注意.
データロード時に集計してしまうLive Aggregate Projectionという仕組みがあるのだけど, ロードの負荷が結構無視できないVerticaだと,大規模だと使いにくい印象を受けた.
色々と生の声が聞けた.
懇親会でユーザに聞いた話だと,OOMみたいなので落ちることはないらしく,20-30人とかで投げてもキューに貯めて順次処理する. ただメモリ使用量が大きすぎたり,キューが貯まりすぎると,落ちるより先にクエリがRejectされる.
K-safetyといういわゆるレプリケーションの仕組みがあるのだけど,DeNAさんや他のユーザも1とのこと.
2にするとデータロードの負荷が高くなり,色々と大変になるらしい.
個人的には,K-safetyの数を増やせばデータの分散具合が増してクエリの処理効率がよくなると思っていたんだけど,
Verticaは基本マスターデータしか見に行かないので,増やしても意味ないらしい.
K-safe 2ってレプリケーションすることでデータを分散させるわけだから,その分各ノードでのデータのローカリティがあがってクエリが高速になる気もするし,安易に減らすのはアンチパターンな気もする #vertica_meetup
— Mr. Fiber (@repeatedly) March 25, 2015
@repeatedly Verticaの場合K-safe1でも2でも基本的にはマスターデータのノードにしかアクセスはいかなくて、レプリの方にはアクセスいかないです!#vertica_meetup
— Civitaspo (@Civitaspo) March 25, 2015
@Civitaspo @repeatedly レプリカはノード障害あった際に使われます。基本的には、レプリカは同じソートパターンを採用し、クエリーの高速性には寄与しません。K-safe=1のパターンが多いです。 #vertica_meetup
— Projection_man (@Projection_man) March 25, 2015
PrestoとかのようなMPPクエリエンジンと違ってストレージと結合しているし, この辺うまく使ってデータの読み込み効率化出来そうだなぁと思っているんだけど,ソースが見られないので何とも言えない…
あとクラスタの再配置やデータのリバランスは結構時間が掛かるらしく,数日かかることもあるとのこと. パフォーマンスはそんなに落ちないらしいけど,別クラスタを立てて一気に入れ替えるのが楽なのかなぁーという.
まー,やはり銀の弾丸はないので,皆それぞれ苦労するポイントはあるなという感じだった. 話を聞かせてくれた人達に感謝 (-人-)
第一回ということもあり,基本的な話が多かった印象でした. ただ実際に使っている人の話とかはやはり参考になる.
第二回もあるかもとのことなので,またその時は参加するかもしれません. オープンソースではないので,気になる所の実装がチェック出来ないのがやっぱりつらい所…
]]>「古橋君がアメリカに帰る前にEmbulkのリリースイベントしちゃうか〜」というノリで1日で立ち上げたイベントでしたが,めちゃくちゃ人が集まって正直驚きでした.
Embulk以外にも,ファイル転送のドンであるHULFTの機能や20年以上つづく開発のアレコレ,Fluentdのv1までのバージョニングと実装予定の機能の説明,そしてHTTP2対応ウェブサーバであるh2oの話,などなど結構バラエティに富んだイベントになったんじゃないかと思っています.
質疑応答や懇親会でEmbulkに色々とフィードバックがあったり,その後触ってもらってバグ報告などもらったりして,イベントをやった甲斐があったなと実感してます.要望の多かったresume機能などもさっそく実装が始まっているので,随時チェックしてもらえればと思います.
また,FluentdとEmbulkの関係みたいなものも,別途記事にする予定です.
データ転送ミドルウェア勉強会みたいなイベント,結構需要があるようなので,また色々と開いて行きたいと思っています.
会場をかしてくれたSAP Japan,会場手配などをしてくれたdots,懇親会をスポンサーしてくれたTreasure Data,発表者の方々,また参加者の方々,皆さんお疲れ様でした!
スライドは上記に貼ってある”「データ転送ミドルウェア勉強会」レポート #dtm_meetup”でまとめられているので,気になる方は参照してみてください!
]]>1月20日に第一回をやりました!キャンセルも少なめで,イベント参加100人強,懇親会が80人くらいでした.予想の倍以上集まった感じで,Prestoも注目されてるんだなと実感したイベントでした.
今回は基本から始まり,それぞれ今使っている人達に,運用の話,BIツールとの連携の話,どういう組み合わせで使っているかなど発表してもらいました.「PrestoのDynamoDBコネクタを作る!」みたいな話もあったりして,リリースが待ち遠しい所です.
懇親会でもたくさんの人と話をしましたが,やはり安定した運用のしやすさとか,コネクタによる複数ソースへのアクセスなど,色々と使っている理由含め情報交換出来たのが良かったです.発表してくれそうな人を二人くらい見つけたので,日程は決まってませんが,また第二回でもやろうと思っています.
このイベントの後,発表に関しての議論が他で行われたりもして,良いイベントになったんじゃないかと思います.
会場をかしてくれたFreakOut,会場準備や手配などをしてくれたdots,懇親会をスポンサーしてくれたTreasure Data,発表者の方々,また参加者の方々,皆さんお疲れ様でした! 第二回でお会いしましょう :)
スライドは以下です.
]]>
Serverspecそのものの説明はいらないとは思いますが,公式サイトと書籍へのリンクを張っておきます.
ソフトウェアの書籍でよくあるような「Serverspecはこう使う」といよりも「Serverspecはなぜこうなっているのか?」という所に重みを置いている書籍です.D言語のTDPLもそうですが,メイン開発者だからこそ書ける書籍になっています. もちろん,Serverspecの説明のために使い方や機能の説明もありますが,個人的には1章と4章がこの本の肝だろうと勝手に思っています.
Serverspecの誕生から,どういう時に使うのか,また今どういう哲学でmizzyさんがServerspecを開発しているかについて書かれています.この章は,Serverspecというよりも,ソフトウェア開発に関する考えとして読むのも面白いと思います.
Serverspec・Specinfraの内部的な構造から設計指針まで広く深く書かれている章です.もし今後Serverspecをがっつり使いたい・またパッチを投げたい,と思っている人は読むべきでしょう.この章のいくつかは,英語でどこかで公開した方がいいんじゃないかと思うくらいです(PRのレビューの負荷が下がりそう).
実装寄りの章ですが,ソースコードもふんだんに出てくるので,理解はしやすいと思います.
個人的に,Treasure Agent(td-agent)のインストール後の状態テストにServerspecを使っています.ミドルウェアのパッケージは構成が変わると,運用している人のスクリプトが動かなくなったりするので,そこを動くコードでチェック出来るようにServerspecで書きました.
この時には汎用的なパッケージの構成テストにServerspecを使っている例がなかったのか,OSなどの判定をする機能がありませんでした.その影響でテスト出来ない箇所がありましたが,「ohaiみたいなのがあるとこうやってテスト書ける〜」みたいな要望を出したら,次の日にはServerspec(実際はSpecinfra)に入ってました! この機能に関しては,3章の3.8のセクションに書かれてます.
Serverspecの作者が著者ということもあり,付録含めて200ページの中に様々な情報がちりばめられています.Serverspec使ってみようかな,と思っている方は買って損はないと思いますし,各リソースタイプも付録に列挙されているので,簡単なリファレンスとしても使える感じです.
mizzyさん,執筆お疲れ様でした and ありがとうございました!
]]>覚えている限りメインで参加したのは以下.
30分以上のトークが増えた年でもあった.HadoopCon Taiwanでは英語のみで基調講演というかなりレアな体験をした.
Fluentdを広めるのが仕事なので,来年も色々と発表はしていきたい.
LTっぽいので話したのだと,モニカジとかCloudera World Tokyoでも喋った.多分他にもあるけどよく覚えていない.
2014年はPrestoのソースコードリーディングを4回くらい開催して,そのままの流れで来年はPresto Meetupをやる. ユーザが増えつつあるPrestoの日本での普及に貢献出来ればという感じで活動している.
D言語関係のイベントは開催出来なかったのだけど,周りから少し要望があるので,2015年はmeetupっぽいのを開きたい.
Contributionがあんまり多くない感じもするので,来年はもっと色々とやる必要がありそう.
仕事でFluentd・td-agent関係をやっているので,開発の大半はそっちにリソースを割いた.以下がFluentdの2014年のまとめ的な記事.
Fluentdもユーザが増えてきて色々と改善すべきところが見えているので,それらを来年は解決する. v1に向けて,とりあえず年末にv0.12を出せたのは良かった.
本体の破壊的変更の数が激減したので,ちょいちょいとしたメンテナンスが多めだった.
俺のライブラリにもユーザがいるらしく,俺が気づくより先にパッチが届くのもあったりして嬉しい. 個人的にはvibe.dがやっぱりイベント駆動ライブラリとして使うには少し自由度がアレな感じなので, もう少し薄いライブラリでも書こうかなぁと考え中…
すきやばし次郎,超美味かった
]]>一緒に参加することになったモリスさんの感想記事はこちら.
色々と紆余曲折?があり,なぜか俺がキーノートで発表することに.
初めての英語での発表が40分のキーノートということもあって,色々と疲れた.
発表内容はHadoop上で使えるSQLプロダクトについて,基本からTreasure Dataでの経験周りを含めてあれやこれや話した. 質問もあったので,俺のアレな英語でもそれなりに伝わっていたのかなという感じ.
他のセッションも聞きたかったのだけど,中国語で正直何を話しているか分からなかったので,外のスペースで他の人と話していた.
海外から招待された人の気持ちが分かった一瞬だったw
カンファレンス会場だった中央研究院は,台北政府直属?の研究所らしくかなり大きかった.向こうの人曰く,大抵のイベントはここでやっているらしい. その他,大規模ではないけどHBaseを使っている所が多かったりと,色々と情報交換も出来た感じで良かった.
HadoopCon 2014で知り合った人たちが観光案内をしてくれて,HadoopConの日と次の日に色々と回れた.
台北101含む観光地だったり,地元の人が集まる店だったり,夜市だったり,色々と解説もしてくれてかなり楽しめた.
写真あげまくるのもアレなので,残りはFBのアルバムで…
色々と調整してくれた台北の人たちには本当に感謝というか,かなり台北中は楽できたので,こういう恩はいつか返したいなと.
台北,ココイチとかすき家とか大戸屋とかゆで太郎とか麺屋武蔵とかあるので,日本の人がいっても多分食には困らない.
ホテルとか,探せば普通に日本語が通じる所もかなりあるので,気軽にこれる所だなぁと.
交通費もかなり安いので,気軽にタクシーとか乗れる.
RubyConfとかOSDCとか,大きめのイベントも毎年やってるっぽいので,近いし,英語の練習がてら皆さんも参加しましょう!と参加仲間を増やす作戦.
]]>最初はFluentdで発表しようかと思ったんですが,別の有用なプロジェクトの話もそろそろした方がいいかな,ということでServerEngineにしました. @sonotsさんがFluentdの発表をしてくれたので,被らなくて良かった…
画像は技評さんから.
以下がスライドです.書いてないことも発表では色々と話したので,動画もセットで見た方が良いです.
ServerEngineはTreasure Dataで開発・運用されている分散キューや分散スケジューラ,それとFluentdなどの経験を元に,汎用的な部分を抽出してフレームワークにしたプロダクトです.発表で言及した機能の他にもBlockingFlagなどのユーティリティがあるので,Rubyでデーモンやバッチワーカーを書くときには是非試して貰えればと思います.
また,FluentdもいずれはServerEngineベースになる予定です.今でもServerEngineと似たような機能を俺俺で実装しているのですが,ServerEngineにすることでよりコードは簡潔に,また新しい機能も実装出来るようになります.この辺は乞うご期待という感じです.
1週間前に台北で英語でのキーノートがあり,直前まで時間が取れませんでした.台北後にひたすらスライドを作り,前日にやっと完成という,かなり際どいスケジュール.
本番どうかなと思ったんですが,時間進行を見ながら一部詳細を飛ばしたり,メインホールだったけどそんなに詰まることなく発表出来たんじゃないかなと思います.ここ数年は色々と大きいイベントでの発表も増え,それらの経験のおかげか,日本語であればそれなりにこなせるようになってきたかなと実感してます.
また,Railsとか関係のない,どちらかというと地味というか泥臭い感じの話が多めだったんですが,何人かには受けたようで,良かったです.
@repeatedly 今年のセッションの中でトップクラスなぐらい良いセッションでした
— 複数DB (@ryopeko) September 19, 2014
@repeatedly よかったですよ!数年前にあれば、あの時苦労しなくてもよかったのに…と思ってしまいました
— Toshiwo (@toshiwo) September 19, 2014
@repeatedly BTW, your talk was great and ServerEngine is cool. Thanks!
— Hiroshi Nakamura (@nahi) September 20, 2014
聞きに来てくれた皆さん,手伝ってくれたスタッフ,そして同時通訳の方々,ありがとうございました!!
とりあえず8月9月のイベントラッシュが終わった感じなので,少しのんびりしたい…んだけど,11月のRubyConfでkiyoto-sanがFluentdについて発表するようなので,俺も参加しているかもしれません.
]]>Perl使ってないし最初は行く気なかったんだけど,登録中のセッション見るとPerlじゃないの多いし, 個人スポンサーになればTシャツやパーカーも貰えると言うことで,個人スポンサーでチケット入手.
0日目は参加せず,1日目は朝から,2日目は昼から参加.
YAPCでのTEDを目指したという発表.大ホールの暗い雰囲気と,宇宙に覆われたスライドによって, 宗教的な感じがしたプレゼン.
発表時間の半分で発表そのものは終わったのだけど,質疑応答をもっと盛り上げれば,完成度は上がったんじゃ無いかと思う.
一番Perlっぽい話かな,と思って参加.Perlのテストにおける歴史みたいなのとか, エコシステムの話みたいなのが聞けたのは面白かった.
「Perl 6と同じくらい夢が詰まっている」という言葉,つらい.
TV番組用システムの裏側の話.あるある系もあったり,便利そうなコマンド作ってたり, なかなかみんな苦労しているな,と.最近TV系の運用話はちょくちょく聞くので,どこも似ている感じ.
songmuさんともずにおんのコンビ漫才を休憩がてら見ていた.やっぱ本番では色々とミスが起きるw
ここで食べたDMMかき氷,普通に美味しかった
IoT周辺の技術の用語とか仕組みの説明.いやー,しかしこの辺りは略語が多くてすぐ覚えるのがつらい.
その後はセッションには参加せず,休憩スペースで何人かでISUCONとかPHPとか色々とだべっていた. MQTT Meetupに参加する予定があったので,懇親会には参加せず会場を去った.
naoyaさんの発表をにやにやしながら見ようかと思っていたのだけど,起きたらもう終わっていたのが心残り.
ついた時間も中途半端だったので,naoyaさんとHUBに行き,そこでmiyagawaさんとかけんじおじさん,shiba_yuさんとかとしゃべっていた. 時間が経つと色々と人が集まってきたのだけど,大ホールの席を取るため移動.
言うことはないというか,全部知っている話だったので内職をしていた.が,ベストトークで2位だったので, やっぱ分野が違うと受けるトークも変わるんだなぁという.
ただ,最初にモリスさんがFluentdのユーザを聞いてくれたら半分くらい?は手をあげていたので, ちゃんと浸透してるんだなと嬉しく思う反面,あと半数にどうやってリーチすべきかというのも考えないと行けない.
モリストリーム…じゃなくてNorikraの宣伝が少なかったな,という印象.
席を取っていて良かった,というくらい人がわらわらと集まってきていた.
FluentdがTwitterで非常にアクティブに議論・サポートされている話とか出てきて,Twiterの監視社会怖い!
やっぱLTは短い中にネタを押し込んでくる人が多いので,それ故に面白いのだけど,すぐ終わるのがちょっと悲しい.
typesterさんのエモい話.typesterさんのキャリアって他の人が真似するのはかなり難しいのだけど, 話の中でも出ていた「複数の人のロールモデルを参考にする」というのに結局落ち着く.
お子さんも一緒に来ていて,ほっこりする感じの発表だった.
あと,typesterさんはIngressは緑のLv8だったので,青のLv8の俺とどこかでやりあってたかも, と思ったけど鎌倉だし全然関係なかった.
そうそうに一つのビールが無くなっていたけど,ジンジャーエール派の俺には関係なかった. 土曜日は夜に外せない用事があるので,色々な人に絡んでから,早めに帰った.
他の人も書いてると思うけど,意見が多いとそれだけ反映されるだろうということで書いておく.
今年の参加者は約1300人で,それに対して会場のキャパシティは約500人らしく,非常に狭かった. 特に多目的教室は毎度部屋から出るくらいまで立ち見とか出ていたので,ちゃんと聞けない人も多かったのではないかなと.
去年も同じ場所で約1100人だったらしいけど,去年は大丈夫だったのかな?参加してないのでよく分からない. この辺のマネージは本当に難しいので,一発で解決のアイディアは提示できないのだけども…
2つのトークが続いて休憩がないのがいくつかあって,これは質疑応答と移動時間がかぶってしまうので勿体ないなと.
トークの種類がPerlに限らず色々とあり,それに伴って参加者も結構多様な感じがしていて楽しかった. ベストトーク賞のベスト3がどれもPerl関係ないのが,それを物語っていると思う.
ネットワークも快適だったし,休憩スペースも飲み物とかあって,セッション以外でぶらぶらするのも困らなかった.
1000人規模の運営超大変だし,運営チームの方達は本当にお疲れ様でした!来年も楽しみにしてます :)
]]>より改善するため色々とユーザにヒアリングした結果,「フィルタ機能が欲しい」というのが一番多い意見でした. Fluentdは元々Treasure Dataへロバストにデータを転送するためのミドルウェアで,「ETLとかはTreasure Dataで」 というのもあり,組み込みでフィルタ機能はありませんでした.
今現在のOutputプラグインによるフィルタ実装は,タグの書き換えが必要だったりして少し慣れが必要で,初心者にはちと難しい. ということで,より簡単に効率よくデータストリームを扱えるフィルタ機能を入れることにしました!
前置きが長くなりましたが,次のバージョンであるv0.12ではFilterとLabelの導入が目玉機能になります. これらは二つともデータストリームの処理をより楽にするための機能です.
後,Fluentd v0.10.53のリリースアナウンスでも書きましたが, 今現在のmasterブランチはすでにv0.12用になっています.また,以下の機能はまだmasterにはマージされていません.今週中にはマージ予定ですが, 試して見たい方は,PR #416をチェックしてください.
Outputプラグインで出力する前に,イベント群に処理を適用するための仕組みです.
grep
やrecord_refomer
やgeoip
プラグインなどは,Filterとして実装することでより効率良く処理出来るようになります.
最初に実装,その後に設定の例を見せます.
FilterのAPIは以下のようになっています.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
SetXXXMixin
を置き換えるadd_metadataフィルタを見て貰えればわかりやすいと思いますが,
引数で渡ってくるレコードを弄って,それを返り値にするだけです
filter
とは違いfilter_stream
は上記のデフォルト実装があるので,変更する必要はありません.
大抵のプラグインはこのAPIをオーバーライドして処理を実装すれば,その結果が次のフィルタに渡されるようになります.
EventStreamを直接処理するFilterを書くためのAPIです.例えばgrep
はレコードを弄らず,EventStream全体に対して処理を行うプラグインなので,
このAPIをオーバーライドします.filter_stream
を変更する場合,filter
を変更する必要はありません.
filter
とは違い,返り値としてEventStreamを返す必要があります.Fluentdは,このfilter_stream
の返り値を次のFilterに渡し,最終結果をOutputプラグインに渡します.
また,record_reformer
のrenew_record
のように,新しくレコードを生成する系のプラグインもこちら側で処理を実装することになります.
grep
とrecord_reformer
のFilter例は以下にあります.
<filter>
セクションが追加されています.たとえば,add_metadata
とgrep
を使う場合には以下のようになります.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Fluentdの設定ファイルの流儀にしたがって,上から順番にmatch
にマッチしたところまでのFilterが適用されます.
この例では,まずgrep
が適用され,その次にadd_metadata
,そしてこれらの結果のEventStreamがstdout
に渡されます.
例えば以下のデータが入ってきたとして:
{"message":"INFO"}
{"message":"WARN"}
stdout
には,grep
で最初のレコードがフィルタリングされ,add_metadata
でタグが追加された以下のデータが渡されます:
{"message":"WARN", "tag":"filter.test"}
タグを書き換えてmatch
の条件を調整して〜という煩わしさから解放されるようになります.
注意点としては,マッチしたmatch
の下にあるfilter
は,たとえtagがマッチしようが適用されない所です.
タグの書き換えや再emitが発生しないため,速度やメモリ効率は多少よくなるはずです.
手元で約450MBのファイルをin_tail
で読み込み,record_reformer
でホスト名などを付加して転送する,
というのをv0.10とv0.12で測ってみた所,v0.10は181秒,v0.12は149秒で,約30秒短縮されました.
ユーザによってはもっとFilterがチェーンしている所もあるはずなので,そういう場合には恩恵が大きいと思います.
これはFilterやOutputをまとめるための機能になります.制限として,InputはLabelの中に含めることは出来ません. こちらは先に設定から見てみます.
以下が簡単な例になります.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
forward
の中に@label @forward
というパラメータがあります.これがLabelの指定になっていて,
@label
があるとその指定されたLabelにイベント群が流れて行きます.なので,この例ではforward
で
受け付けたイベント群は,add_metadata
フィルタを通り,その下のfile
に到達します.
一方,@label
のないInputは今までと同じ挙動となり,トップにイベント群を流します.
この例では,grep
フィルタを通り,その下のmongo
に到達します.
Labelの機能によって,各プラグイン間の関係がわかりやすくなり,またルーティングのためにタグを調整する必要もなくなります.
out_relabel
プラグインを使えばデータを別のLabelに飛ばせるので,入力によって違うフィルタを適用したいが,書き込み先は一緒にしたい,
みたいな処理も簡単にできるようになります.
v0.12から,router
というのがInput/Outputに増えてます.今までEngine.emit
と書いていた所を,router.emit
に書き換えるだけで,
Labelの機能が使えるようになります.
言い換えれば,この書き換えをしていないInput/Outputプラグインは,@label
が使えないということになります.
v0.12の主要機能であるFilterとLabelについて簡単に説明しました.まだ実装としていくつか細かな改善はあるのですが,
基本機能は上記のままで行くと思います.
何かフィードバックがあれば@repeatedly
にmentionをするか,上記の該当PRにコメントをして貰えればと思います.
Fluentdのエコシステムの一つとして,Fluentd UIをリリースしました. すでに試してくれたユーザもいるようなので,現在の使用感などは下記の記事を参考にしてください.
この記事ではFluentd UIそのものについてつらつらと書きたいと思います.英語でのアナウンスもいずれ公式ブログに載るはず.
Fluentd UIの背景として,Fluentdも最近は国を問わず色々な所でユーザが増えてきており, 「CLIとか楽勝!」以外のユーザの割合も増えつつあります.
ログコレクタでリッチな管理UIを持っているプロダクトってほとんどないと思うのですが, 新しく使い始めるユーザの嵌まり所とか見ていると, GUIの方が始めるための敷居が下がりそうなポイントがいくつかありました.
なので,Fluentdを使いたい人がなるべく嵌まらずに始められるようにと, 万葉の方と開発したのがFluentd UIです.
生い立ちの所で書いた通り,Fluentdの敷居を下げるのが第一の目的なので, すでにFluentdをバリバリ使っている人はユーザの対象ではありません.
バージョン0.1.0の段階で,以下の機能があります:
最初に色々機能を洗い出したのですが,全部入れるとリリースが遅れるし,
複雑なのを入れるとユーザが混乱するかもということで,ベーシックな機能セットに絞りました.
それでも,プラグイン入れての挙動チェックなど,全部Webから出来るようになっています.また,
ユーザがテストしにくかったin_tailは,Fluentularを参考にかなり使いやすいUIになったと思います.
実装的にもかなり依存を減らしていて,例えば,最初はSQLiteベースだったのですが, 「SQLiteだとFluentd UIそのもののセットアップに嵌まる人が出る可能性がある」とファイルベースに変更したりしました.
バージョン0.1.0ということから分かる通り,まだまだ始まったばかりのプロダクトで,
今回は開発者側が「こういう機能があったら始めやすいだろう」というものを中心に入れました.
今後はユーザからのフィードバックも受けつつ,更に使いやすさを改善して行けたらなと.
現状各プラグインの設定を削除する時は,自分でフリーフォームから消す必要があるので,
この辺もボタンで消せるようにとか,出来たらいいかなぁと考えてます.
あと,今設定が組み込みで実装してあるので(インストールした3rd partyプラグイン用の設定ページがない),
各プラグインから自動で設定ページが生成できるような仕組みも必要かなと,色々と模索中です.
td-agentには同梱予定はないんですが,td-agent 2にはtd-agent-uiみたいな感じで同梱する予定です.すでに起動した人は知っていると思いますが,td-agentをセットアップする用のボタンがあります :)
Fluentd UIは,UI上で色々と試行錯誤しその結果出来た設定ファイルをChefとかで配布, みたいなのを想定しているのですが,毎回コピペとか面倒ですし, 最近だとfluentd-serverとかもあるので,この辺なんか上手くやりたいな,と.
Fluentd UIについて背景含めつらつらと書きました.是非試して頂いて,問題があったらissue投げるなりPRなりしてもらえると助かります!
あ,ちなみに最初のリリースは俺がやりましたが,開発はコミットを見れば分かる通りuu59さんでちゃんとしたRailsコードになっているので,ご心配なく!
]]>ここではログコレクタにFluentdを想定しているが,他のログ収集プロダクトにも適用出来るはず.
ただ,Fluentdはタグベースのルーティングを持ち,単体でもキューのように動作させることが可能で,既存のものより複雑な問題を解決しようとしているので,少し工夫が必要かもしれない.
Fluentdそのものについては公式ドキュメントや,Fluentdとはどのようなソフトウェアなのかを参考に.
いきなりFluentdを使わないパターン.JavaScript SDKを提供している解析サービスやモバイル端末などでよく使われている.ログがユーザサイドで発生する場合にはログコレクタを仕込むことは出来ないので,基本このアプローチになる.
これらはクライアントの出来によって精度が左右されるが,モバイルであれば繋がらなかったら一定量バッファリングをし,ネットワークが繋がった段階で非同期に転送などがよくある実装.
ログコレクタを用意出来るサーバサイドでこのアプローチを取っているシステムは最近だとあまり聞かない.もしやるならエラーハンドリングとして
などの問題を解決する必要がある.Fluentdであればこれらの機能が最初からついているので,今から構築するシステムでやる必要はほとんど無いと思われる.
アプリケーションやノードからログを集め,ログコレクタから直接保存する.「クライアントから直接保存する」の例で,ローカルにログコレクタを置き,そこ経由でデータを投げつけるモデル.
ネットワーク周りのややこしい問題をログコレクタに任せられ,Fluentdであればプラグインで容易にストリームを操作できるのがメリット.また,ApacheやNginxから直接外部にデータを投げるのは難しいので,Fluentdでファイルにはき出されたログを収集するときにはこの構成となる.
この構成だと,収集対象のサーバが多くなるだけアクセスが増えて保存先への負荷があがるので
などの場合に有効になる.次で書く集約ノードが必要ないので,その分管理は楽になる.
Fluentdは転送役と集約役に違いはないので,この段階でフィルター系プラグインを使って,データを加工することもある.
Treasure Dataの場合には,Librato Metricsに投げる所などは集約ノードを経由せず,各Fluentd(Treasure Agent)から直接投げている.この場合は各ノードのメトリックスが取りたいので,集約ノードでデータストリームをまとめる必要もない.
これとは違いMongoDBの場合だと,細かいのをちまちま送るより大きめのバッチでガンと書き込んだ方が効率が良いので,このモデルよりも集約ノードを置いた方が良い.
ログコレクタでの多段構成モデル.集約ノードを置く利点は,データストリームをまとめてデータに対する処理をしやすくする点が大きい.また,各ノードから集めることでストリームが太くなり,マイクロバッチの効率も良くなる.
Fluentdでもアグリゲーションをしたり,Norikraと連携するプラグインがあったりするので,その手の処理はこの集約ノードでやるのがベター.
大抵のログコレクタと同じく,Fluentdのデフォルトの転送プロトコルはPush型になっていて,多段構成時には流れるように保存先にデータが集まるようになっている.
多段構成時の注意点は,ある場所のノードが落ちた時にストリームが途切れてしまう所.Fluentdの場合は障害に対応するために,転送先を複数指定可能で,その中で負荷分散とノードが落ちた時の処理を指定出来るようになっていて,よほど一気にノードが落ちない限りストリームが途切れることはない.もし落ちてもバッファリングが行われるので,ノードを再度立ち上げればデータはまた流れ出す.
アプリケーションをホストするような環境だとローカルにFluentdを置けなかったりするので(HerokuだとFluentdは起動できるが,ファイルバッファが使えなかったりする.ユースケース次第),その場合はいきなり集約ノードやキューにデータを投げることになる.
データストリームの中でキューを間に挟むことの主な理由は,ログのreliabilityの向上と,処理の間にワンクッション置くこと.
そもそもキューはPush型ではなくPull型であり,Producer・Queue・Consumerと登場人物も増えるので,キューを置くことでログ収集そのものが効率化されることはあまりない.異なる粒度のシステム間で連携をする時に,間にキューを置くことが多い.
実際Fluentdとキューを連携させている例はいくつかあり,たとえば複雑なシステムを構築しているVikiの例ではKestrelでFluentdからのデータストリームを分岐させているし,AWSは本家がfluent-plugin-kinesisを書いているので,いずれこの事例も増えるはず.
KafkaやKinesisなど信頼性のあるキューを間に置けば,ログをそれなりの期間保持しつつ,Consumerを複数用意することでストリームを分岐できる.
Push型での分岐とは違い,キューからログを取る側の都合でデータを処理出来るので,各データストリームで処理粒度が違う時に有効.
ただ,キューそのものに信頼性があってもProducer/Consumerが駄目だと効率が良くならずログが欠損/重複するので,自分たちのシステム要件に合わせてちゃんと構築する必要がある.
キューを置かずにPull型でログを転送する方法もある.Kafkaほどの信頼性を期待するのは難しいが,Pull型の利点を享受できる.まだ完成していないが,Fluentdだとモリス=タゴという人が,pullforwardというのを開発中らしい.
プロダクションで使われているパターンをいくつか書いた.大抵のシステムは上のどれかの構成に当てはまる.FluentdはWebや広告のみならずIoTやPOS含め色々なところで使われていて,データのアーカイブ,簡単なストリーム処理,ノードやアプリケーションのモニタリング,などなど様々なユースケースの基盤になれる柔軟性がある.
また,LINE社で2年間問題なく動いているし,最近勉強会とかで話を聞くと「安定していて自分の仕事がない」と言われる位,よほど変なことしない限り安定性もある.ある会社で100億events/dayをFluentdクラスタで転送した実績もあるので,パフォーマンスもそれなりにある(フィルタ的な処理を重ねまくると,もちろん遅くなる).
が,Fluentdを使わない方が良いケースもある.以下主に二つ.
一切ログの欠損も重複も許せない,しかも確実に書き込む必要がある,というケース.
ストリーム処理でExactly Onceを保証するのはかなり難しく,俺が知っている限りOSSでは存在していない.商用でもほとんど知らない.
Exactly Onceを実現しようとすると,ログ発生時点から書き込むまでを完全に同期的にやるか,様々な箇所でトランザクションが必要になり,スケールアウトが難しくコストもものすごく掛かる.そして保存先にもそれなりの機能が求められる.
かつてOSSでマスターノードを使い到達保証を目指したプロダクトがあったが,結局パフォーマンスがボトルネックになり,そこまでしてもログの欠損が防げなかったため,新しいバージョンでは諦めることになった.
FluentdはデフォルトAt Most Onceであり,ドキュメントにもモデルの説明と対策が書いてある,
これはログが欠損/重複しまくるということではなく,At Most OnceもAt Least Onceも通常は問題は起きない.トポロジーに問題がある場合に,システム的に欠損/重複が起きうるという話.そして大抵のユーザはExactly Onceでなくても上手く行く.
Fluentdでも欠損/重複を防ぐための対策はいくつかあり
などなど.システム的にExactly Onceではなくても,それに低コストで近づけることは可能.
v0.12からはAt Least Onceもサポートする.現在リリースされているv0.12.pre2から使えるが,v0.12の正式リリース後,ドキュメントにもちゃんと書く.
たとえばAWSのCloudWatch Logsがそう.Agentのセットアップが必要だったりして楽かと言われるとまだ微妙だが,今後最初からインストールされる可能性もある.
そのような状況で,Agentから取れるログをCloudWatch Logsで直接見るので十分であれば,Fluentdを入れるメリットは少ない(CloudWatch Logs用のプラグインがあるので,Fluentdから利用することは可能).
Fluentdの利点は簡単にロバストで柔軟性のあるログ収集基盤が作れて,一度構築してしまえば,環境非依存でそのログ収集基盤を再利用出来るところなので,そのような必要性がないのであれば,環境と密結合したサービスを使う方が運用コストそのものは直近は削減できるはず.
Fluentdが向いているケースと向いてないケース,そのPros/Consみたいなのを書いた.細かく書けばもっと色々と書けるのだけど,記事でそんなに長々と書いても疲れるだけなので大まかに. 何か質問があればTwitterで@repeatedlyにmentionするなり,この記事にコメントするなりしてください :)
もうすぐFluentd + Elasticsearch + Kibanaという有名な構成のムック本が出るようなので,この本とか読むと,解析のノウハウ含め色々とここには書いていない情報が手に入るのではないかと思います.
MPP on HadoopでPrestoがメインなのは今一番使っているからで,Impalaなど他のMPP on Hadoop的なものも似たような感じかなと思っています. もちろん実装の違いなどがあるので,その辺は適宜自分で補間してください.
アプリケーションを開発していて,そのための解析基盤を一から作る.
以下つらつらとリスト形式で書いてます.
PrestoやImpalaやApache Drillは,Redshift/BigQueryと違ってMPPデータベースではなくてMPPクエリエンジンなので,そこに違いがある. Prestoそのものについては,@frsyuki がHCJ 2014で発表したスライドがあるので,そっちも参考に.
基本的にこれらの裏にはHadoopなどの基盤が前提になりつつある(オブジェクトストレージ + 演算リソースでも可).上のリストを眺めれば,なんとなく使い分けが分かるんじゃないでしょうか! MPPと一纏めにするにはユースケースや得意なものが違うので,ちゃんと使い分けましょう.基本的にどれもBIツールと接続する方法があり,苦労はそんなにしないはず.
各プロダクトは常に改善されているので,ここに書いてある制約などは,いずれ緩和される可能性があります.常に最新情報をチェックしましょう.
今回はMPPクエリエンジンプロダクトの話なので上のリストでは省きましたが,Treasure Dataが提供しているTQAというMPPサービスは「Prestoで運用とかストレージを考えなくていい版」に近い感じになります.TDはさまざまな外部ストレージと連携出来るので,Treasure Dataを中心に使い分ける感じになります.
最後に宣伝!
Twitterに流したさらに要約したtweet.
Presto on Storage/BigQuery/Redshiftはユースケースがバラバラなので,適宜使い分ければ良いという単純な話.ただ,HDFSやオブジェクトストレージみたいなのにデータが永続化されている前提なので,Prestoは入りには楽だよね,というのはあります.
— Mr. Fiber (@repeatedly) July 23, 2014
Redshiftは同時実行制御頑張っているし,distkeyとかをちゃんと設計してあげればかなりパフォーマンスが出るので,データマートとして優秀.特に8XLとかであれば,RDSとかでは頑張れない領域になる.ただ,スキーマの変更に弱いので,適宜ロードしてあげないと行けないのがネック
— Mr. Fiber (@repeatedly) July 23, 2014
BigQueryは逆に,その辺のMPPの知識ないけど楽に処理したい,という時には便利.ストレージと密結合しているRedshiftと違ってストレージとしては安価なので,ガンガンデータを入れられる.スキーマの変更に弱いのと,G社の都合でクエリに制限が掛かったり不安定になるのがネック
— Mr. Fiber (@repeatedly) July 23, 2014
Prestoは単体だとストレージがないので,裏側に何を使うかによってかなり左右される.ちゃんとしたHadoopクラスタやオブジェクトストレージがあれば,同時実行制御の部分に難はあるが,低レイテンシクエリーとしては十分優秀.データのインポートの手間がないのが大きい.
— Mr. Fiber (@repeatedly) July 23, 2014
まぁHadoopとかあるならとりあえずPresto入れとくか,という流れにはなりつつある気がする.それでも同時にたくさんのクエリが飛んでくるとか,ある程度スキーマ固まったのでガッツリ使いたい,になるとRedshiftとかBigQueryにバッチでinsert,がよくあるパターン
— Mr. Fiber (@repeatedly) July 23, 2014
やっぱり他のMPPデータベースにデータ入れるの面倒だからPrestoでがんばりたい,というユーザ結構いてその人たちが色々とPrestoをデータマート的に使えるようにと頑張っているようなので,いずれHadoop上ですべて完結する世界は来るかもしれない
— Mr. Fiber (@repeatedly) July 23, 2014
トレジャーデータというサービス,自分でインフラ管理する必要ないですし,Fluentd/JS/iOS/Androidなどからデータを入れるだけで,即バッチや低レイテンシクエリを投げられる,便利なサービスらしいですよ > http://t.co/gSg9ZTNjKt
— Mr. Fiber (@repeatedly) July 23, 2014
社会人の勤めを果たした
— Mr. Fiber (@repeatedly) July 23, 2014
]]>