Go ahead!

Memoization for Everything

Fluentd meetup 2015 summer

| Comments

Fluentd Meetup 2015 夏 - 2015/06/01(月) - dots.

募集が約2週間前とかなり直近になってしまったんですが,100人以上の方の参加がありました.場所を提供してくれたgloopsさん,受付などサポートしてくれたdots.さん,懇親会などをスポンサーしてくれたTreasure Dataさん,発表者の方々,また当日参加してくれた皆さん,ありがとうございました!

Eduardoが東京の地下迷宮に迷ったりとハプニングも少しありましたが,無事終わって良かったです.fluent-bitのお披露目を兼ねたイベントでしたが,さっそくパッチを送ってくれてる人もいて,正式版リリースはまだですがフィードバックをガンガン貰えればという感じです :)

また,他の方の発表も,Fluentdを単なるログの収集だけではなく,工夫して色々と実現されているのも良い知見になりました.やはりプラグインで柔軟に弄れると,利用の幅が広がって面白いですね.

次は秋か冬辺り,v0.14のお披露目もかねて開催出来ればと思っています.

Fluentd v0.12 - master guide -

俺が行った発表はタイトル通り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の現実装のPros/Cons

| Comments

TODO:

  • 必要なら図を足す
  • 他に書いた方が良いPros/Consのリクエストがあったら追記

内部のイベントストリームの扱い

  • Pros: Inputがスケーラブルに実装しやすく,データストリームを正常時/エラー時で切り替えやすい
  • Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい

以下長々と理由書きます.

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はログの管理をするために(昔はそれほどES/Kibanaと密結合していなかったはず)

という出生の違いによって生まれているのかなぁと思っています.

実のところFluentdで過去ログを転送している人はいて大きな問題にはなってないのですが,どうしてもキャパシティが足りないところに無理にやろうとすると,上記のElasticsearchのような問題が起きたりするので気をつけましょうという感じです.(一括転送専用にバッファをチューニングするのは面倒だったりしますし…).
実際1レコードずつSQL発行してinsertを行うmysqlプラグインでも,最近同じ問題が起きてました.これはバルクロード版で解決しました.

今だとEmbulkがあるので,大量データの一括転送はそちらを使ってくださいという流れになりますが,ブロックする挙動があっても損はないとは思うので,うまくバッファのAPIが整備出来れば,back-pressureっぽい機能は入れようかとは思ったりはしてます(fluent/fluentd #569).

今回はFluentdとLogstashしか言及してませんが,他にもいくつかログ収集のプロダクトは存在しているので,上記のイベントのライフサイクルや,転送プロトコルでどういうセマンティクスがあるのかなどは,使う場合には一通りチェックした方が良いと思います.

Developers.IO 2015

| Comments

Developers.IO 2015 | IoT, BigData, BI. in 3/27(金),29(日)

書くの遅れましたが,先月の末に行われたDevelopers.IO 2015で,登壇してました.

Treasure DataのAWS活用法

発表スライドは以下です.

Developers Dayの日で「なるべくニッチな話をしてください」と言われたのと, TD Techtalkに参加出来なかった人も見に来るというのもあったので,Treasure Dataのデータインポートとかクエリ処理周りの 内部処理的な話をしました.

Treasure Dataみたいなサービスを自力で作る人は少ないとは思いますが, 昨今データ解析周りの需要は増えているので,もし社内でそういう案がある人の参考にでもなればという感じです. といっても,クラスメソッドさんのイベントでもあり,AWS要素多めの内容になっています.

一番最後に決まったセッションだったんですが,部屋的には埋まっていた感じなので良かったです.クラスメソッドさんのまとめやtogetterのまとめは以下にあるので,参考にしてみてください.

イベントの感想

SAPさんの会場で,複数のトラックで行われており,盛況でした.興味があったものの参加出来なかったセッションがいくつかあったのが心残りといえば心残り.最後の抽選では色々と欲しいものがあったものの,残念ながら手に入れることは出来ませんでした.また似たようなイベントがあったときにはリベンジしたい…

クラスメソッドさん勢いあるなぁと感じたイベントでした.まだまだこれからも色々とやるようなので,盛り上げるのに今後も協力出来ればという感じです.

皆さんお疲れ様でした!

第一回 Vertica勉強会

| Comments

第1回 Vertica 勉強会

DeNAでVerticaの勉強会が開かれるということで行ってきた.皆さんお疲れ様 & ありがとうございました.

VerticaはMPPデータベースと呼ばれるプロダクトの一つ.まとめみたいなのはすでに他の人が用意してくれているので,そちらを参照してください.

はじめてのVertica!(はじめのて方にも、20分で分かりやすく解説)

Verticaの基本的な話.C-Storeが元になっていて, やはりC-Storeの論文に書かれている機能がベースになってた.

ここで出てきた

  • 列指向フォーマット
    • そして列毎の圧縮
  • Shared Nothing
  • ANSI SQL準拠

とかはMPPでは基本的な特徴で,それらを一通り持っている感じ.

少し珍しいものとしては,マルチマスタみたいにすべてのノードがクエリを受け付ける所. 複数クエリが飛んでいる時にどういう負荷分散をするか分かってないけど,クエリを投げた時にあるノードが自動でリーダーになるっぽい.
Impalaも似たような仕組みだけど,Statestoreみたいな外部サービスすら存在してないようなので, クラスタがどういう風に状態を共有しているのかが,個人的には気になっている.

あとで言及するけど,DB Designerというツールが一番の肝.

DeNAでのverticaを活用したアナリスト業務のご紹介

DeNAでどうやってVerticaを利用しているかの話.まだPrestoやImpalaが広まる前から利用しているようで, やはりHiveやPigをAd-hocクエリの代わりに使うのはつらかったという.

もちろんすべてをVerticaでやっているわけではなくて,データはHadoopクラスタにも入れていて, でかいサービスなどの場合はHadoopで中間データをつくってVerticaに入れているという,よくある構成.
ストレージと密結合しているMPPデータベースはこまめなロードが大抵苦手なので, データ量が大きいところでは皆この構成を取っている.

leadとかlagとかのWindow関数はHiveやPrestoでも使えるんだけど,timeserieseというgap-fillingな関数は少し面白いなと思った.

DeNAでのVertica運用について

FluentdとKafkaを使ってデータを収集している話があって,ここでもFluentdが!

ここでHadoopを機械学習にも使っているという話をしていた.何のプロジェクトを使っているんだろうか?懇親会で聞くの忘れてた.

運用に関して色々とTipsを話されていて,参考になる発表だった. データインポート時に型が一致してないレコードをデフォルトで捨てるのが,なかなか豪快だなぁという感じ.

あとクエリは基本Resource Poolで細かく制御するのが複数ユーザで使う時の前提. これはどこのMPPデータベースでも同じで,何もしないと一人がでかいクエリ投げると他の処理が止まってしまう.

CTC、Vertica はじめました!-テスト結果を共有!

「Verticaがすごい」という話だったんだけど,テスト内容の詳細がなくて, どういうスキーマで,どれくらいのデータがあって,どういうクエリかが分からずかなりふわっとしていた. あとグラフに目盛りとかもなかったので,さらにすごさがよく分からなかった…

お客さんのテスト結果ということらしいので詳細を話せないのは分かるのだけど, こういうオープンなイベントだとTPCとか使って分かるデータで見せないと, ちょっと厳しいかなぁという感じ(特にパフォーマンスとかを気にするエンジニアには).

Verticaの速さの秘密、プロジェクションに関して20分で!

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は基本マスターデータしか見に行かないので,増やしても意味ないらしい.

PrestoとかのようなMPPクエリエンジンと違ってストレージと結合しているし, この辺うまく使ってデータの読み込み効率化出来そうだなぁと思っているんだけど,ソースが見られないので何とも言えない…

あとクラスタの再配置やデータのリバランスは結構時間が掛かるらしく,数日かかることもあるとのこと. パフォーマンスはそんなに落ちないらしいけど,別クラスタを立てて一気に入れ替えるのが楽なのかなぁーという.

まー,やはり銀の弾丸はないので,皆それぞれ苦労するポイントはあるなという感じだった. 話を聞かせてくれた人達に感謝 (-人-)

まとめ

第一回ということもあり,基本的な話が多かった印象でした. ただ実際に使っている人の話とかはやはり参考になる.

第二回もあるかもとのことなので,またその時は参加するかもしれません. オープンソースではないので,気になる所の実装がチェック出来ないのがやっぱりつらい所…

データ転送ミドルウェア勉強会

| Comments

「古橋君がアメリカに帰る前にEmbulkのリリースイベントしちゃうか〜」というノリで1日で立ち上げたイベントでしたが,めちゃくちゃ人が集まって正直驚きでした.

Embulk以外にも,ファイル転送のドンであるHULFTの機能や20年以上つづく開発のアレコレ,Fluentdのv1までのバージョニングと実装予定の機能の説明,そしてHTTP2対応ウェブサーバであるh2oの話,などなど結構バラエティに富んだイベントになったんじゃないかと思っています.

質疑応答や懇親会でEmbulkに色々とフィードバックがあったり,その後触ってもらってバグ報告などもらったりして,イベントをやった甲斐があったなと実感してます.要望の多かったresume機能などもさっそく実装が始まっているので,随時チェックしてもらえればと思います.
また,FluentdとEmbulkの関係みたいなものも,別途記事にする予定です.

データ転送ミドルウェア勉強会みたいなイベント,結構需要があるようなので,また色々と開いて行きたいと思っています.

会場をかしてくれたSAP Japan,会場手配などをしてくれたdots,懇親会をスポンサーしてくれたTreasure Data,発表者の方々,また参加者の方々,皆さんお疲れ様でした!

スライドは上記に貼ってある”「データ転送ミドルウェア勉強会」レポート #dtm_meetup”でまとめられているので,気になる方は参照してみてください!