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

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:狭そう

2014-07-01

RedDotRubyConf 2014に行ってきた&発表してきた

シンガポールで行われるRubyカンファレンス RedDotRubyConf 2014 に出したプロポーザルが通ったので、Fluentdについて紹介してきた。旅費は勤務先のLINE株式会社に出してもらいました。

RedDotRubyConf 2014

RedDotRubyConf のオーガナイザーは配慮がすごくて、accept後の旅行の手配やら向こうでの行動やら、いろいろ気にかけてもらった。カンファレンス前夜のスピーカーディナーとかあるのも個人的にはすばらしいと思う。あれで色々な人としゃべれて、イベントへの入りみたいな気分がかなりできて落ち着けた。

Fluentd日本国内ではもうだいぶ認知されて使われているようだけど、海外だとアメリカで少し紹介されたくらいで、ユーザも少しずつ増えてはいるけどまだまだ、という状況だと思う。なので敢えて基礎から紹介する、という意味はあるだろうと思う。

f:id:tagomoris:20140701160140j:image:w600

実は自分にとってこれはたった2度目の海外旅行、しかも1度目は人に連れていってもらいほぼ着いていくだけ、行き先でもカンファレンス会場のあるホテルに籠もりっきりという感じだったので、海外で街中を一人でふらふらするのは完全に初の経験だった。しかも発表も英語でやるのはこれが初めてで、もう何もかも初めて尽くし。いろいろたいへんだった。

とはいえ、結論を書くと、シンガポールは初めて行くにはすごくいいのかなーという気がする。安全だし清潔だし交通機関は整っていてモバイルネットワークもどこでも普通に使える。

英語が通じるし、色々ななまりの人がいるからか、発音が聞きとれない、ということに関して割と寛容な人が多いんじゃないかなあと感じた。聞き返してもあんまり嫌な顔されないし、こっちが英語があんまりできないと分かるとすぐにゆっくり丁寧に話してもらえることが多かった。

自分の場合、東京で英語で話す機会がたまにあると、下手な英語をしゃべったり言葉に詰まったりしつつもコミュニケーションをとろうと頑張るんだけど、すぐに自分が何を言ったかを思い返して反省してしまうことが多い。英語の下手さばかりを自分に印象付けてしまってあんまり良くないなとは思っていた。*1

現地にいって否応なく英語にさらされていると、そういう変な内省みたいなものをする暇もなく次々と会話の機会がやってきてぶっちゃけ個々の事例(というか使った英語の文章自体)を覚えてられないので、最終的に「なんとかなった」という気分だけが残った。

今回日本からの他のスピーカーであるところの @_ko1 さんこと笹田さんと @hsbt さんこと柴田さん、どちらも慣れていて動じないし、さすがという感じしかしない。

英語圏で働きたい/生活したいとは特に思わないけど、ソフトウェアエンジニアをやっている以上は英語からはなかなか逃げられないし、自分(達)のOSSプロダクトを広めようと思えば海外の人に使ってもらわないと先がない。そのための最初の一歩としてはなかなか良かったんじゃないかなと思う。

しゃべってきた

で、Fluentdの話。日本のみなさまにはお馴染みの話かなあ。

初めての英語でのプレゼンということで、珍しく事前に資料作って会社で同僚を相手に練習とかもやって、フィードバックをもらって直したりしてた。同僚各位、その節はお世話になりました。

トーク中に聞いてみたところ、Fluentdを知っているかとの質問に会場の1/3くらいの人が手を挙げるということで、えええっ思ったよりは認知されているのだな、と。Q&Aでも既にFluentdのユーザだという人からの質問があったし(内容はメッセージのロストに対する対策は?とのことで、ACKとかの話も含めた回答をした)、そもそも司会役の人もFluentdのユーザだったり。After partyで聞いたところVikiもHQがシンガポールらしくて、そういえばその会社Fluentdユーザだって聞いたことあるわー、みたいな。

終わった直後はさすがに疲れて放心状態。翌日のお昼やAfter partyであれこれ聞いたら、特に聞きとれないような場所もなく普通の発表だったと思ってもらえていたみたい、だと思う。たぶん。

しかもこれまでFluentdを知らなかった人からも割とポジティブな反応がいくつもあって*2、やった甲斐はあった。これでこれまでに増して広まってくれると嬉しいなあ。

f:id:tagomoris:20140701160139j:image:w600

その他のRDRCの話

アメリカやその他の地域から来ている有名Rubyistがスピーカーにけっこう多く、その他も東南アジアインドオーストラリアなどの各地から来ていてものすごく多彩。いろんな種類の英語があってヒアリングの練習に良い。……そして話の間にはさまる小粋なジョークが聞きとれない&理解できなくてつらい。

とはいえ技術的な話題としては国内のカンファレンスと較べて違いがあるかというと、全体的にはそう違わないと思う。もちろん個々の話はいろいろ面白かったりスゲーなという感じだけど、まあそれは国内でも同じ。

そういう意味で日本のカンファレンスに参加してれば技術的なレベルはまあいいのかもなんだけど、逆に、普段やってることを持ってくればみなさん十分にスピーカーになれますね、と思う。

f:id:tagomoris:20140701160138j:image:w600

お昼の時間やAfter partyで、スピーカーをやっていれば顔を覚えてもらえているし話題もあるので話しやすい、というのも国内のカンファレンスとまったく同じ。

さすがにLINEは知られるだけはけっこう知られていて、Fluentdの話のほかにLINE自体の話もけっこう聞かれた。みんな他社が何をどうやっているかというのに興味はあるよなあ。そしてRDRCでそういう話ってほとんどなくて、もうちょっと各社がどういうソフトウェア構成で何をやっているかの話はあってもいいんじゃないかなと思う。

あと台湾から来てる人で自分のスライドとかを物凄く良く読んでくれている人がいて*3、地道に英語で書くようにしているとそういうこともあるんだなあとちょっと感動した。

まとめ

シンガポール、狭いところでいろいろな人種と文化と宗教の詰め合わせみたいになっていて、あらゆる意味で多様性があってものすごい感じだった。とにかく国内でできない経験ばっかりで、だいぶ疲れたけど、行ってみて本当によかった。

f:id:tagomoris:20140701160137j:image:w600

多分また次の良さそうな機会があれば、そこにプロポーザルを出してみると思う。その程度にはいい結果だった。楽しかった!

*1:しかしもしかしたらこういう行為のおかげでベターな英語の蓄積が自分の中にできていたのかもしれない、とも少しだけ思う。

*2:しかもGithubから来てるスピーカーの人からも、とか!

*3:質問がものすごく細かいところについての話でびびった