tagomorisのメモ置き場 RSSフィード

2014-09-01

YAPC::Asia 2014に行ってきた&しゃべってきた

YAPC::Asia Tokyo 2014

みなさんご存知のYAPC::Asiaに出したtalk提案が採択されたので、スピーカーとして参加してきた。スケジュールを見たら2日目の一番最後の枠(LTの直前)で、なんと初めてのホールでのtalk。

1日目午後は会社でお仕事上の用事があったので参加できず、2日目朝は前日夜に死ぬほど飲んでいたので動けず、2日目午後は自分のtalk前で気もそぞろ……という感じで聞く側としてはアレだったけど、いろんな人が会場にいていろいろ話したし、面白かった。

しゃべってきた

"Handling not so big data." というタイトルで、今現在における分散データ処理プラットフォームの世界はどうなっておるのか、ということをざっと概観しつつ、そういう仕事に踏み込むときには何が重要なのかについて少し話した。

分散データ処理についての話だけど、上でどんなロジックを動かしているか、データ実体の中身はどのようなものかを言わなくても語れる重要なことは山ほどあって、自分が最近あちこちで話をしているのはそれがものすごく大きいと思うんだけど、自分に限らず他の人ももっとそのメリットを活かしましょう、というのが最後のページの話でした。ちょっと時間足りなすぎて焦ってて、わかりにくい表現になってたかもしれないと後で思った。

スライド作ってみたら明らかに20分に収まらない感じでどうしようかと。だけど削れるような場所も無く、やべーどうしようと思った結果、図を増やして少しわかりやすくしつつ20分間耐久LTを行うという暴挙に出た。他のカンファレンスだったら顰蹙モノだけどYAPC::AsiaならLTで鍛えられているし大丈夫なはず!

で、やってみたところ、そこまで文句もなかったのかなということで、良かった良かった。

というか、ベストトーク賞2位をいただきました。びびった。ものすごく嬉しかったです。ありがとうございました!

喉がぶっこわれて声が出なくなりました。

さて

次は9月13日に台湾のHadoopConでがっつりとHadoopやNorikraやその他の話をしてきます。2週間先と思ってたけど、そうか、来週末か。英語……。

あとgcp ja night 28でBigQueryとFluentdをネタに適当な話をビール飲みながらやりますが、こちら、申し込みが定員をはるかにぶっちぎっておりますね。すごい。台湾の直後なんでいつ準備しようというのが目下の悩みどころです。

更にその直後にRubyKaigiがありますね。行く予定です。

更にその翌週にISUCON予選がありますね。どうするんだこれ。

2014-08-18

uuidtools gemの新版がリリースされました

https://rubygems.org/gems/uuidtools

uuidtoolsという便利なgemがありましてその名の通りuuidの生成に使えるものでしたが、その機能のうちMACアドレスからuuidを生成するという部分がifconfig外部コマンドに依存していました。

で、みなさんご存知の通りRHEL/CentOS 7ではこのifconfigコマンドが標準でインストールされなくなり、正常に動作しなくなりました。これに伴った修正がuuidtools gemでも行われましたが、長くリリースされない状況でした。

https://github.com/sporkmonger/uuidtools/issues/24

が、先日無事リリースされたため、みなさんアップデートしましょう、自分で作っているgemがuuidtools依存しているなら 2.1.5 以降に依存するよう変更しましょう、ということです。

みんな大好きFluentd関連で言いますと拙作 fluent-mixin-config-placeholders が uuidtools に依存しています。先程このgemを uuidtools 2.1.5 以降に依存するよう修正した 0.3.0 をリリースしました。

Fluentd pluginを作っており fluent-mixin-config-placeholders という名前に聞き覚えのあるみなさんは是非依存関係の更新にひと手間割いていただければと思います。

こちらからは以上です。(絶賛アップデート祭なう……。)

2014-08-04

NATやファイアウォールの向こうへデータをお届けする fluent-plugin-pull_forward を書いた

Fluentdにおけるネットワークごしデータ転送プラグインといえば forward が組み込みであるし、通信路を暗号化したければ secure-forward がある。

しかしこれらFluentdネットワーク転送プラグイン基本的に全て送信元から送信先に対してプッシュする形になっており、ネットワーク接続も送信元から送信先に対して行うことになっている。このため送信先のFluentdNAT下にある場合やファイアウォールで保護された場所にある場合、もしくはダイヤルアップ接続……は、まあ今は無いだろうけど、例えば移動するデバイス上にある場合など、こういったときにはうまくデータの転送を行う構成がとれない。

なぜこういう状況、つまりプッシュ型で転送を行うプラグインばかりなのかというと、FluentdのBuffer pluginの仕組みによる。細かく設計上の話をあれこれしてもアレだし面倒くさいので省くが。

という状況なのはわかっていたんだけどまあ自分に用途ないしいいか、と思って放置していたのだが、色々あって自宅(NAT下)でFluentd立ててそこに向けてデータ送りたいなー、という用途が発生してしまった。

fluent-plugin-pull_forward および fluent-plugin-buffer-pullpool つくった

用途が発生してしまったからにはしょうがないので、趣味プロダクトの一環ということで作った。まだ自宅で使いはじめてないんだけど、動く……はず。

f:id:tagomoris:20140804180656p:image

コードはこちら。

https://github.com/tagomoris/fluent-plugin-pull_forward

https://github.com/tagomoris/fluent-plugin-buffer-pullpool

ということで、これを使えばオフィス内のマシンとかけっこう電源落としたりする自宅サーバにもFluentdごしにデータを転送できる! やった! 便利!

しかもプロトコルHTTPS + Basic認証 + JSON なので、実は受け取り側はFluentdである必要すらなく、HTTPSのリクエストを発行できるあらゆるクライアントFluentdからイベントデータをJSONで好きなタイミングにフェッチできる。なんて便利なんだ!

このためにデータのflush(の実質的な処理)をpull型でできるようにするためのハックを加えたbuffer pluginも作った。対応したAPIをもったBufferedOutput pluginからのみ使用できる*1

注意点としては、フェッチされる前のデータは当然だがFluentdが起動しているノードにファイルとして残り続ける。なので buffer_chunk_limit および buffer_queue_limit の設定および空きディスク容量には注意が必要。あんまり高スループットな環境で使うものではないです。

ということで

実は割と刺さる人がいるのではないかと思います。みなさまぜひご利用ください。

*1:これはBuffer pluginにそういう処理を行うためのAPIが足りないため。将来的にはFluentdアップデート時になんとかしたい。

2014-07-10

Norikra meetupやってきた

Norikra meetup : ATND

DeNA Technology Seminar #Norikra meetup

Norikra がいい感じになってきたので、ユーザ(とコミッタ)もうちょっと増えないかなーと思い、Norikra meetupという勉強会をやった。会場、Ustream中継および懇親会を:DeNAさんにご提供いただきました。いつもいつも本当にお世話になっていますが、すばらしい会場をありがとうございます。

定員80人に対して参加は話す人も含めて60人ちょっとくらい? 自分が最近主催した勉強会はもっと出席率良かった気がするので気にしてなかったら、今回は少し低かった。もうちょっとサバ読んだ定員にしておけばよかった。補欠も含めた申し込み数は結局170人とかのままだったので、もったいなかった。

とはいえ、聞いてみたところこれから試してみる!という人がけっこういそうだったので嬉しい。みなさんでガンガン使ってガンガン広めていただけると非常にいいですね!

内容も基本的な使いかたからなんか極まった感じのまであれこれあって良い感じ。これまで本気でやろうとすると大分面倒だったことが割と気軽にやれるんだよ、という内容になってたと思う。たぶん。

しゃべってきた

ストリーム処理とはどういうもので、何が嬉しいのか、Norikraはどうなのか、みたいな基本まわりの話。

運用とかに効く突っ込んだ機能等のいくつかの紹介。

他の(弊社同僚なんかの)話にもあったけど、最初に書き上げた時点でサボってたor間抜けになってた実装はその後の運用期間にやっぱり問題として発覚していて、そのへんを既にちゃんと直してあるのは、ちゃんと手元で運用しているからこそじゃないかな、とは思う。関係した同僚にはご迷惑をおかけしまくってて申し訳ないんだけれども。w

Norikraに関しては他の自分のプロダクトからは考えられないくらいドキュメントも頑張ってるので、上記スライドで紹介した内容も含めて、いちど参照してみてほしい。お役立ち情報がいっぱいです。

http://norikra.github.io/

まとめ

やってよかった。いろいろ聞けた。

第2回は? という話があったけど、ユーザと使用例が増えたり変な機能が増えたりしたらしばらくして考えようかと思います。第2回をやろう、と決意する程度にユーザが増えてくれるんじゃないか、ぐらいの期待は持ってます。

さて、RedDotRubyConfからHadoopConferenceJapanを経由してNorikra meetupという流れが終わった。しばらくはちょっと落ち着いてコード書く……。

2014-07-09

Hadoop Conference Japan 2014いってきた&しゃべってきた

Hadoop Conference Japan 2014- Eventbrite

今年も開催されたのでいってきた。主催者の方は本当におつかれさまでした。毎回規模がでかくて、これやるのは本当大変だろうなと思う。参加登録者は1299名だそうな。

全体的な空気としてはいよいよYARN移行が避けられず、その上に乗っかるデータ処理フレームワークとしてMapReduceも今後存在しつづけるもののSparkやTez*1が登場し、処理記述言語としてはもう単純な処理についてはSQL一択ですかね、という感じ。機械学習系やそのほかのワークロードはまた違うだろうけど。あとはMPP系のエンジンがその脇にある、という。

今回は事例の話が極端に少なくなって、みんな各コンポーネントについての話をしてた気がする。技術的には過渡期だということかな。いいことだ。

参加者アンケートでFluentdを使っていると答えた人が200人近くもいて、これは正直びっくりした。自分のセッションの最初にもちょっと聞いてみたところ、知っている人という質問にはおそらくほぼ全員の手が上がり、使っている人を聞いても半分以上上がっていたと思う。懇親会でもFluentdのことについて話しかけられることも何度も。なんかもう日本のログコレクタ界*2にすごい勢いで広がってるな。ひええ。

いっぽう知らない人から「ちょうどNorikra使ってみようと思っているところなんです!」と話しかけてもらった回数が5回を優に超え、これはこれからNorikra流行るのでは、みたいな……どうかなw

しゃべってきた(メイントーク)

SQLを処理記述言語としてバッチ処理およびストリーム処理の両方で用いることについて、またバッチ処理ストリーム処理の特性の違いと使い分け方法(および併用することの重要性とその方法)などについて話した。ちょっと定性的な議論が多くなって聞く人の印象はどうかなと思ったけど、Twitterとかでは良かったという反応も見られたので、まあ良かったと思うことにしておこう。

ストリーム処理は実際やってみると速報値の算出や異常検知などにたいへん便利なんだけれど、これまではStormを立ててその上でアプリケーションを書くくらいしか実質的には選択肢がなく、それはそれであんまりだよね、普通の人は分散処理を前提としたストリーム処理が必要なほどのトラフィックはそうそう持ってないでしょ、という話も出てきます。Hadoop Conferenceで非分散処理なソフトウェアの話をするのもちょっとアレだったけど、まあ、まあ。

無事に終わったので総じて良いのではないでしょうか。

しゃべってきた(LT)

メイントークとLTと、どちらか通ったらいいなと思っていたら両方通ってしまったので、こっちもやってきた。じつは最近も開発がちゃんと行われておりYARN対応したりPresto対応したりしているShibの話。便利なのでみんな使うと良いと思います。

いっぽうLTだしと思って笑いを取りにいったところ非常に反応が薄くつらい思いをした。ハードル高い。

まとめ

じつに面白かったのでまたやってほしい!

そして今日は Norikra meetup ですよ!

*1:そういえばTezの話は無かったな、どっちかというとそちらを聞きたかった

*2:狭そう