たごもりすメモ

コードとかその他の話とか。

2015年を振り返ってみる

今年はとにかく仕事してた……。ということで、Blogエントリ数を見てみるとこれまでの数年に較べてだいぶ少ない。

転職した

大手インターネットサービス事業者から、いろいろあって結果的には西海岸のスタートアップ(の東京オフィス)に移った。

tagomoris.hatenablog.com
tagomoris.hatenablog.com

今年のいちばん大きな変化だったのは間違いない。このあとUSオフィスに少し行ってたり、この「いろいろあって」のときに考えてたことをエントリに書いたりもしていた。
結局その後に仕事をしていてこれまでと全く違う環境になったし、書くコードの種類や性質、考えかたなんかもけっこう変わったなという自覚はある。

あとこれまでに較べて格段に英語を使うようになった。おかげでだいぶ慣れてきたなとは思う。

書いたコード

OSSのコードはこれまでのプロダクトのメンテナンス系が多い、けど、Dockerのfluentd logging driverを書いたりmsgpack-rubyのメンテナをやることになったり、そこそこ新しいこともやってはいたかな。あんまり大物ではないけど、自分にとっては新しいものだったりそれなりに影響する範囲も広かったりで、面白い経験にはなっている。

あとはISUCON関係。これはあとで。
仕事関連だと社内向けの実装を直すことが多かったのがあって、ほとんどそういうエントリは書かなかったな。Hiveの挙動を一部乗っ取るためのコードをどこにどう書けばいいか、みたいな他社では役に立ちそうもないノウハウはだいぶ得たけど……。

発表やら執筆やら

海外のカンファレンスが2件、そのほか国内ではYAPC::Asia, RubyKaigi, 秋デブサミなどなど。秋デブサミのエントリは書き損ねてるな。7月まで大きいイベントや出張は皆無だったのに、8月からいくつも続いたのでだいぶばたばたしてた。いっぽう初めてヨーロッパに(2度も!)行けたのはいい経験だった。

割と概論や考え方についての話をするケースが多かったので、まあこれはこれで悪くはないんだけど、もうすこしコードの話をしたいなあと思ってはいる。そのためにはコード書かないとなー。いや書いてるんだけど、なんというか、もうすこし話にしやすいやつ……。

あと依頼があってWEB+DB PRESSにひとつ記事を寄稿した。個人的には記念にしたいくらいの思い出になりそう。

ISUCON

ISUCON5の出題をやった。9月末に予選、10月末に決勝というスケジュールを調整していたときは準備にたっぷり時間をかけられるはずだったんだけど、仕事の予定がズレ込んで、1年で(仕事だけで)いちばん忙しいという時期にISUCONの準備や各種発表が全部重なるという感じで、死にそうな2ヶ月になった。たぶんこれまでの人生でいちばん忙しくしてたと思う。

まあ、いろいろ不手際があって申し訳なかったとはいえ、いちおう成功したと言っていい終わりかただったのではないかとは思う。個人的にもJava8のコードをだいぶ書いたりで得たものは大きかった。ベンチマークツールはフレームワークになってるので、もうすこし直してちゃんと単独のプロダクトとして出すつもり。ちょこちょこまだ直している途中。

あれこれ

その他、ウケた記事もあった。YAPC::Asiaでの発表からの一連の流れはちょっと感激なくらいで、いろいろ考えてることをぼろっと外に出すと面白いことが起きることもある、といういい例になったかもしれない。

tagomoris.hatenablog.com
tagomoris.hatenablog.com

加えて転職の時期とISUCON後で2回も morisnite をやったり、いろんな人にお世話になってるなあ、と本当に思うことが多かった。みなさん本当にありがとうございました。

来年

Fluentd v0.14に向けたPlugin APIの作り直しを4〜5月頃に途中までやってたんだけど、その後に社内向けの大きい仕事にかかりきりになっていて済んでない。正直あれがblockerになってるので、まずいなあとは思ってる。2016年の最初の大きい仕事としてこれをやるつもり。

他に社内向けにはHadoop/Hiveよりも少しインフラっぽいことや便利ツールまわりをやろうとも思ってるので、そのへんの技術をさわってみることも増えると思う。というか、増やしたい。今年は春にひたすらChefと格闘してたくらいで、その後にそっちをあまり見られなくなってしまった。
あとは某分散処理をゴニョゴニョ。これは形になるのはもうちょっと先になるかな。面白いコードをあれこれ書ける予定があれこれあるので、楽しみたいと思う。

LogstashからFluentdにデータを転送する

このエントリはFluentd Advent Calendar 2015の12月25日分の記事です。4日遅れ!

で、本題ですが、もうタイトルそのまんま、logstash-output-fluentd を作りました。
logstash-output-fluentd | RubyGems.org | your community gem host
tagomoris/logstash-output-fluentd · GitHub

How to install / use

先日書いたものと全く一緒ですが、いちおう書いておきます。

とりあえずインストール。

$ bin/plugin install ../logstash-output-fluentd-0.1.0.gem 
Uninstalling logstash-output-fluentd
Validating ../logstash-output-fluentd-0.1.0.gem
Installing logstash-output-fluentd
Installation successful

そしたら以下の設定ファイルを用意します。stdinから読み込んで 127.0.0.1 (のデフォルトポート 24224)に送るやつ。

input {
  stdin {}
}
output {
  fluentd {
    host => "127.0.0.1"
    tag => "logstash"
  }
}

起動すればもう使えます。簡単ですね!

$ bin/logstash -f example.conf 
Settings: Default filter workers: 2
Logstash startup completed
line 1
line 2
line 3
line 4

https://i.gyazo.com/1205f1400186157524418e9ad4f0c3ef.png

Yay!

注意点など

まだごくシンプルに指定したホストの in_forward に向けてデータを投げ付けるだけですが、まあ、使えなくもないかなというところです。Fluentdのforwardプロトコルにはいろいろと機能があるんですが、そのへんやover SSL*1やらはまだ全くしておりません。また複数ホストへのロードバランスやら死活確認(つまりHA)やらも対応しておりません。
そのうちやろうかなあ、どうしようかなあ。

バッファは logstash-output-treasure_data と同じでオンメモリに適当に持っているだけです。デフォルトは短めで50イベントもしくは5秒。これも flush_size および flush_interval で制御できます。正常にシャットダウンすればflushされるけどその時に失敗したり異常終了したりしたらイベントが失われるのも同じです。

まとめ

Enjoy logging!

*1:つまりin_secure_forward対応

LogStashからTreasure Dataにデータを投入する

このエントリは(2日遅れましたが)Treasure Data Advent Calendar 2015の12月25日分の記事です!

みなさんTreasure Dataにログ入れてますか? FluentdやEmbulkで入れてますよね?
しかし世界的に見てFluentdはまだまだ最有力のソフトウェアとは言えず、特にUSやヨーロッパのスタートアップ界隈ではLogStashが強い勢力を誇っています。Treasure Dataにログを投入するためだけにFluentdをインストールするのには抵抗のある向きもそちらには多いのです。

ということで、しょうがないから作りました! 本日から使えます。
logstash-output-treasure_data | RubyGems.org | your community gem host
tagomoris/logstash-output-treasure_data · GitHub

ただし現状ではdev releaseのライブラリに依存しており、この後ちゃんとメンテナンスリリースが出せるよう直すつもりです。また公式のlogstash-pluginsに入れてもらえるようにするつもりです。2016年かな。

How to install / use

LogStashを手元に展開したら、以下のコマンド一発でインストールできます。

$ bin/plugin install logstash-output-treasure_data
Validating logstash-output-treasure_data
Installing logstash-output-treasure_data
Installation successful

そして設定ファイルを用意します。以下の設定は stdin を用いて標準入力から1行ずつ読み込み message というフィールドに入れ、そのイベントを treasure_data プラグインを用いてTreasure Dataの指定したデータベース/テーブルにアップロードします。(API Keyやデータベース名、テーブル名は実際に使用するものに置き換えてください)

input {
  stdin {}
}
output {
  treasure_data {
    apikey => "0/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    database => "dbname"
    table => "tablename"
  }
}

準備できたら起動するだけです。コンソールにメッセージを適当に入力し、終わったら Ctrl-D で入力を終端できます。終端したら自動的にflushされ、Treasure Dataへのアップロードが行われます。

$ bin/logstash -f ~/example.conf 
Settings: Default filter workers: 2
Logstash startup completed
line 1
line 2
line 3
line 4
line 5
Logstash shutdown completed

https://i.gyazo.com/fc5b009f4ce425e49e17b2e59daa0b38.png

簡単ですね! やった!

注意点

LogStashはソフトウェアの機能としてはバッファリング機構を持っておらず、そのため logstash-output-treasure_data では他の多くのプラグインにあわせる形で、オンメモリでのキャッシュを行っています。
Treasure Dataにあまり細かい単位でbulk importを行うのは非常に効率が悪いため、現在はデフォルトでは10,000レコード、もしくは5分毎にflushを行うことになっています。*1

通常の手順でLogStashをシャットダウンすればその際にflush/uploadが行われますが、プロセスの異常終了などが起きた場合はメモリ内のデータは失われるのでご注意ください。

まとめ

Happy Logging!

*1:これらの設定は flush_size および flush_interval で制御できます。

WEB+DB PRESS Vol.90にコラムを書いた

明後日ですね、12月23日発売の WEB+DB PRESS Vol.90 の15周年記念エッセイ「私を変えたソフトウェア」にて2ページ、記事を書きました。
たまに(?)このblogでもエモいアレを書いたりしますが、なんかそういうやつです。原稿料をもらってこういうのを書いたのは初めてです。たぶん。

gihyo.jp

内容は本誌を読んでいただきたいんですが*1、要するに今現在に毎日ミドルウェアを読み書きして生活するようになったきっかけは何だったか、という話です。きっかけひとつというわけでもなく幾つか段階があるなあと思ったので、それについてつらつら思い出話のようなものを書いてます。
改めて読んでみると最後の1ステップ(現職への転職)が抜けているのでそこに何の迷いもなかったようになってますが、もちろん実際はそんなことはありません。が、まあそれはソフトウェア開発者としての転機というよりは人生どう生きるかみたいな部分なので、いいかなと思います。

しかし他の3氏がものすごくて、Rubyの人とHSPの人とLispの人ですよ……。ひええ。あと他がみんな1990年以前の話なのに、自分のやつだけ2010年代になってます。並んでるソフトウェア名も Emacs、スペースインベーダー、Lisp と並んで "FluentdとNorikra" とか、うああ。*2
他の方よりもうちょっと卑近な例ということで、これはこれで存在意義があるに違いないと自分に言い聞かせてます。

他の記事だと自分には特に特集2のドラクエXの話が興味深くて、ほほうKTにCassandraにExadataとな……みたいな感じです。まだざっと目を通しただけなのでじっくり読みたい。大規模MMORPGのバックエンドについて詳しく雑誌に書かれるとはすごい時代だなと思いますね。

ということで、興味があれば読んでみてくださいな、という話でした。

*1:PDFでも1部単位で買えますね、いい時代だ

*2:書影出てくるまで他の著者が誰かとか知らなかったんだけど、これ知ってたら原稿書けてたのかな……。

RubyKaigi 2015に行ってきた＆しゃべってきた

この週末にあったRubyKaigi 2015に参加した。
RubyKaigiはRubyコミッタやその他の人々に、特に低レイヤや各種OSの事情に詳しい人なんかも多くて、これはこれで非常に刺激になっていていいなあ。言語ランタイムの最適化の話を何セッションも聞くとかは国内の他のカンファレンスでは自分はあまり経験しないので、いつも楽しい。

しゃべってきた

EuRuKo 2015で話したのと同じタイトルだけど内容はけっこう違ってて、なぜTDではRubyでqueue/workerシステムを必死に作っているか、みたいな話をメインに据えて話してきた。あまりRubyのコードそのものに触れることができなかったのがちょっと残念だけど、前提条件から丁寧に、必要性とどうなっているかを説明できたかなという気はする。
あとシステムを改善するときにどうしたらいいかという方針の話を質疑応答で少しできて、それもすごくよかった。質問してくれた @joker1007 さんのおかげです。

来年

京都だ! 楽しみ。行きたいなあ。そのためにもうちょっとコードそのものについて話せるようなネタを作りたいなー。

ISUCON5の出題をやった

(11/2 11:03 末尾に追記と得点経過グラフ掲載)

正確にはいままさに決勝のイベント中なのだが、思った以上に順調にイベントが進行していてヒマな上、完徹の後でコードとか書いてる最中に意識が飛んだりするのでコードも書けない。のでつらつらこれを書いている。

9月末にISUCON5予選をやり、10月末のいま決勝をやってます。3年ぶりのISUCON出題側でしたが、いやはや、過去最高にきつかった回だった。ちょっとday jobのほうでもクリティカルなあれこれが重なったのもあるけど。
しかし両方とも、直前までの死ぬ寸前みたいな追い込み状況に対し、イベントとしては*1大きな破綻もなく進み、本当に良かったと思っている。このイベントがイベントとして成立したことが本当に嬉しい。

そういったあれこれは本当に一緒に出題をやってくれた@kamipoさん、そして実装を手伝ってくれた@hydrakecatさん、@najeiraさん、@makingさん、@taroleoさん、@hokacchaさんのおかげだと思う。出題の傾向・内容ともにだいぶハードだった上、じぶんの作業の遅れがモロにイベント直前に皺寄せでいってしまった。
このような状況でコンテストが成立したのは本当にこの人達のおかげだ。ありがとうございました。

これまで何度か言っていたけど、ISUCONを予選だけで終える人達が大多数になってしまった以上、一度は「自分たちが知っている決勝の問題」を予選でもやってみたかった。今年の予選は(ちょっとギリギリ感があったけど)、それがいまできる最大限にできたと思う。今年の予選に参加した人には胸をはって言える。あれはISUCONだ。

決勝はこれまでとだいぶ方向性を変えてみた。詳しい解説は別途書く機会があると思うが、これまでのISUCONとはだいぶ違う。
これはふたつの理由があって、ひとつは*2これまでと同じような問題では同じような人達が勝ってしまうから、やはり方向を変えたい、ということ。もうひとつは、なんとなくだけど、ISUCONの出題内容・傾向をいちばんドラスティックに変えやすいメンタリティを持っているのは自分なのかなと思ったことがある。

ISUCONはまだ、たかだか5回しかやっていないだけの技術イベントだ。守らないといけないものはないし、これだけ出題というものが大変なんだから、出題者はなんでもやりたいことをやればいいと思う。参加者は不満があれば、自分で勝手にイベントをforkして出題をしてみればいい。

そうやって、全体として面白い、幅広く懐の深い開発者コミュニティになっていければいいなと、そう思う。

ああ楽しかった! 2年参加して今回出題したから、次は少なくとも4年は参加側かな! 超疲れたし!

結果

また! またしても! fujiwara組に勝たれてしまった!!!

他チームの得点が見えなくなった時間帯も含めた得点グラフはこちら。最終計測のもプロットされてます。

f:id:tagomoris:20151102110542p:plain

ベンチマーク走行は全体で1409回、優勝チームは46回実行リクエストがあったようです。最多チームは91回でした。

ということで

夜な夜なコードを書いていてゆっくりビールも飲めなかった俺の冷蔵庫を溢れさせてやろうという方は ぜひこちらのwishlistをどうぞ! 本当に溢れたらまたmorisniteやるかー?

*1:トラブルやバグはあれこれあったものの

*2:ISUCON2の時にも思っていたことだけど

EuRuKo2015に行ってきた

EuRuKo 2015 に出したトークのproposalが通ったので話しに行ってきた。往復旅費は現勤務先であるTreasure Dataに出してもらいました。ありがたや。宿泊費はなんとオーガナイザーが出してくれた。すごい。
2ヶ月ぶり生涯二度目のヨーロッパ、今回はオーストリアのザルツブルク。あいかわらず行くのは遠いし乗り継ぎも必要でちょっと大変だけど、それでも行ってよかった。たいへんよかった。

前のドイツ行きとちがって今回は日本から他の参加者もいたので、というかまつもとさん、笹田さん、鳥井さんという……ひええ、超豪華メンバー、だったので、英語で疲れたときに普通に日本語で話ができるのがありがたかった。あんまり大勢日本人がいるのも風情がないが完全にぼっちというのもきついので、このくらいだと英語でしゃべる機会もそこそこあるし、いいな。

ということでしゃべってきた。

ふつうに会社名をタイトルに入れてCFPに応募したのが通ったからそのまましゃべってきたんだけど、カンファレンス全体的に他のスピーカーの人達がまったく自社企業のアピールをしないので、ええコレまずかったのかな、という気分にちょっとなったのは事実。でもこれで通ったしなあ。
データ解析系の話は縁が遠い人が多いのかなという印象の反応だったけど、それでも終わったあとで色んな人とあれこれ話をした。自分で作ってる人はやっぱりデータストアやら何やらに苦しんでいる人が多いいっぽう、自分でHDFSとかをホストせずS3に頼ったほうがよいアーキテクチャだということには懐疑的な人も多いようだった。いやー、S3のパフォーマンスすごいよ、という話を何度かした。
いっぽう縁が遠い人にはなんでいちいちそんなソフトウェアを自分達で(Rubyで)書いてるんだ、ということがうまく伝わらなかったようなので、その部分はもっとちゃんと話すべきだなあという感じ。じつは同じ話で RubyKaigi 2015 にも通っているので、そのあたりを直してやりたいと思ってる。

他のスピーカーの話は、なんというか、いろいろ。あまりプロダクションシステムの話をする人は多くなくて、教育だとか素朴な要素技術(SSL/TLSの話とか!)とか、良くも悪くもアカデミックに近いというか開発者コミュニティそのままのカンファレンスという手触りだった。これはEuRuKoだからなのかヨーロッパだからなのか、興味深いところ。隣に座ってた人と話してたらPerl6を話の例に出されてうおっヨーロッパっぽい! と思ったこともあった。

雑談してるときの英語にほとんど困らなくなってたのはよかった。プレゼンテーションも資料を作るところ含めて日本国内でやる場合とほぼ同じ程度の準備、で、まあ英語についてはそう悪くなくやれたんじゃないかな。これはTreasure Dataに入ってから明らかに進歩したところだと思う。

しかしザルツブルクはとにかく街がすごい。まさに多くの日本人が色んなものの刷り込みの結果脳裏に思うような、古き良きヨーロッパの街だ! という感じがする。だって川と橋と教会・聖堂と広場と市壁と断崖と城だぞ。石造りの建物が密集してその間に狭い路地がはりめぐらされてるし、ちょっと山っぽいところを歩いていると木々のむこうから古い城館が現れるし、あちこちに怪しげな門があるし。もうたまらん。

あとは肉を食べ肉を食べ芋を食べチーズを食べ肉を食べ。

ビールビールビールビールビール。

ザルツブルクにも大きいビールメーカーがあるらしいし、そのほか地方のビールもあれこれあった。そんなに多く飲んだわけじゃないけど、けっこう満足できる感じでたいへんよい。

ウィーンだと甘いものがすごいことになってたらしいが、ザルツブルクでもちょっとだけ楽しんだ。よかった。

ということで、非常に良い旅行だった。来年はブルガリアのソフィアらしい。
とにかく普段と異なる経験、USやアジアのカンファレンスに行くのとはまた全然違う経験ができるので、未経験の人には本当にお薦めです。楽しかった!