YAPC::Asia Tokyo 2015 にいってきた＆しゃべってきた
毎年おなじみのYAPC::Asia Tokyo 2015が今年も行われたので参加した。いやー、たのしかった。
しゃべってきた
Talk proposalは出してあって、acceptされたというので話してきた。前夜祭。ビール飲みながら発表ができるぞ! ということで、内容はガチでコードの話というよりはもうちょっとだけふわっとした気分で、OSSをどう開発するか、それをどう継続して広げていくか、みたいな話。
枠は前夜祭……と思ったら、前夜祭のところにはRejectconと書いてあって、えっそうなの、みたいな感じ。まあいいけど*1。思ったよりだいぶ多くの方に聞いてもらえてよかったです。満席になって立ち見も出てた。
ウケるOSSの作り方、そしてコミュニティを盛り上げる方法！ YAPCモリストーク #yapcasia #yapcasiaD - Togetterまとめ
スライド以外に口でしゃべったこともあるし、質疑応答も非常に濃い状態になっていたと思うので、気になる人は動画を見てみてほしい。
あとでTLを遡ってみたところ、けっこう評判よかったようで安心した。していたら、こんな反応エントリも出てきた。うわお。
@t_wada さんや @hsbt さんとはカンファレンス期間中などにも(他の人も含めて)いろいろ話した。この話題は長くなるので、別エントリに分けて書く。
いってきた
毎年様々な人から聞く「YAPCの同窓会感がすごい」っていうやつ、これまでは色々な人と会えるしすごいなーと思う程度だったんだけど、今年行くと前職の同僚とかがいっぱいいて、あっこれ同窓会だ! ってなってた。
同時に今年は他言語なんかのコミュニティ・カンファレンスの知り合いも本当に多く来ていて、あらゆるところであらゆるところからの知り合いに会った。この何でもアリという感じはすごい……というか、あらゆるプログラミング言語・あらゆる問題意識の開発者が集まってきてやるカンファレンスはこれしかないのかもしれない。
会場がビッグサイトになったのもあってスペース全体の問題は去年に較べればはるかに改善されてた。ただトークによっては(というか結構な数のトークが)満員になっていて、満員だからもう入れない、というのもけっこうあった。話す側としては満員になってるとモチベーション高く話しやすいのは確かだけど。
ということで、いくつか特に気になるトークはちゃんと聞きつつ、あとは適当に会場内をふらふらして知り合いと話したりもしてた。わいわい。コーヒースペースが本当にすばらしかった。
今年でJPA主催という形で行われるこのイベントは最後(来年は無い)とのことなので残念ではあるが、どんなプログラマでも来られるカンファレンスというのがBeaconなのかな、という気がする。
まあなんだかんだいってYAPC::Asia TokyoはPerlという枠で収めず大きくなり続けていったので、それをいったんリセットして、誰でも来られるカンファレンスと、Perlに集中したもうすこし小さいカンファレンス*2に分ける、というのは悪くないアイデアだと思う。
何にしろ、いいヤップシーだった。主催者、スタッフ、スピーカー、参加者のみなさま、おつかれさまでした。またね!
JRubyConf.EU と Eurucamp に行ってきた
JRubyConf.EU 2015 のCFPにsubmitしたproposalが通ったのでポツダムに行ってきた。……のは7月末〜8月頭にかけてだったのでもう2週間以上経ってしまった。反省。
ポツダムはドイツ北東部、ベルリンのすぐ隣の街。人生で最も遠くへの旅になった。旅費はTreasure Dataに出してもらった。ありがたい。
すごくよくオーガナイズされたカンファレンスで、主催者にはあれこれ親切にしてもらって、滞在中は不便なことは皆無だった。ぐれーと。
話したスライドはこちら。JRubyをJavaなソフトウェアの上にプラグイン層を作るために使うと良いよ、という話。
JRubyConf.EU は Eurucamp という別のRubyコミュニティのカンファレンスのイベント内イベントという感じ。なのでJRubyConfには参加せずEurucampのみの参加という人もすごく多くて、スピーカーとしての立場が使えない英会話を行わざるをえなかった。なけなしの英会話力をふりしぼっている側にはけっこうきつい。今回は日本から行ったのは自分だけだったので、途中でコミュ力を使い果たしてカンファレンス最終日はほとんどくたばっていた。Eurucampはコードよりはかなりコミュニティ側に寄った内容のトークばかりだったというのも、まあ、あるかなあ。参加者の人に聞いたらこのカンファレンスが特徴的にそうらしいけど。
話した中ではやはり日本は遠い……ということでTDもFluentdもあまり知られていない。けど話すとそれはいいね! みたいにわかってはもらえる。もっと人の行き来が増えるといいなー、というか、もっと向こう行って話さないとな、というところ。遠いんだけどねえ。
LogStashの開発者と話せたりというあれこれはあった。日本に長いこと住んでいたドイツ人の人とか、日本の企業でリモートで働いているベルリン在住の人とかとも話せて、いやはや世界は広いのか狭いのか。貴重な経験だった。
ということで面白かったんだけど、次は10月にEuruko 2015がオーストリアのザルツブルグであって、こっちも通っているので、また話しに行くのでした。
Docker 1.8 に Fluentd logging driver が入りました
以前に書いた話の続きなんだけど、Docker 1.8が出た。
で、それに Fluentd logging driver が入っている。これで Docker container で起動したプロセスのSTDOUTやSTDERRを直接Fluentdに向けて投げることが可能になった。Dockerにpull-reqを送ったのは初めてだったんだけど、無事マージされてリリースまでこぎつけたので、本当に出たときはほっとした。途中だいぶ大変だったので……。
Collecting All Docker Logs with Fluentd | Treasure Data Blog
5 Use Cases Enabled by Docker 1.8’s Fluentd Logging Driver | Treasure Data Blog
Treasure Data blogで既にいくつかエントリが出てる。あと既に試したりしてる人もいるよう。すごい。
概要などについては以下のスライドがわかりやすい。
ということで、Dockerもだいぶ便利になりました! Enjoy Logging!
YAPC::Asia前夜祭でOSS開発者としての話をします
俺の考えるISUCON
ISUCONというイベントがある。要するに技術コンテストイベントだ。領域はWebアプリケーションにかかわる全てといってよい。
これがなんなのか、そろそろ一発説明しておくか、という気分にちょっとなったので書く。実は何を隠すこともなく次の出題者なのでいかに出題内容にひっかからないように書くかがちょっと大変かもしれないが、どうせ出題内容とかまだ確定しているわけでもないので、いいや。
ISUCONとは何か
ある日の朝、Webアプリケーションが一式、適当に設定されたサーバごと渡されます。あとベンチマークツールも渡されます。
さて夕方までにこのベンチマークツールの計測するスコアを可能な限り上げてください、そのためなら渡されたサーバ上で何をやっても構いません。ただしベンチマークツールはアプリケーションの動作が変わっていないかどうかチェックするための機構を備えているので、そいつが違反を検出したらスコアは無効です。
これだけです。もちろんコンテストなので詳細は当日朝にレギュレーション文章として渡されます*1が、想定外の事態を防ぎたいだけで、内容としては本当に上のものだけです。
世の中一般におけるWebアプリケーションというやつは通常、Webサーバ、アプリケーションサーバ、アプリケーションサーバ上で動作するプログラムコード、およびデータベースから成ります。データベースは多くの場合はRDBMSですが、まれにNoSQLオンリーという強烈な構成のものも世の中にはあります。あとキャッシュサーバを追加したりもしますね。
ISUCONにおけるWebアプリケーションもだいたいはこういうやつです。学生の頃には自分もRDBMSをさわったりはほとんどしなかったけど、お金を稼ぐためにRDBMSは非常に強力なソフトウェアなので、だいたい働きはじめると使うことになります。
ISUCONにおける「何をやってもいい」というのは本当に何でもよくて、別言語でスクラッチから実装し直そうがサーバソフトウェアの構成を完全に変えようがOSから入れ替えようが、何でもいいです。Webアプリケーションの動作さえ変えなければ。これはそれらしい用語ではブラックボックステストとか言ったりします。
これは要するに「あなたに全てをぶっこわす権利をあげます」ということです。それで勝てるもんなら勝ってください。それを見てみたい。
現代のISUCON
むかしむかし、ISUCONには一人で参加できました。現代のISUCONには一人では参加できません。必ず2人か3人でチームを組む必要があります。なぜか。
極めて簡単で、これは1人で勝てるものではない、ということがやってみて明らかになったからです。1人では絶対に勝てません。本当は2人でもつらくて、これまでの優勝チームは漏れなく3人チームですし、上位入賞チームもほとんどが3人です*2。
むかしむかし、ISUCONは先着申し込み順での決勝1日だけのイベントでした。現代のISUCONは予選をリモートで行い、通過者が会場に集まって決勝を行うことになっています。なぜか。
最初はこんなコンテストにこんなに参加者が集まるとは思っていなかったからです。が、今となっては70以上のチームが参加*3するイベントになりました。他に似たようなイベントがなかったのが目新しいからでしょうか。
一方会場に集まって決勝をやるスタイルはそのままです。これは単純に、そのほうが盛り上がるからです。イベント後に飲みながらお互い何をやったか話し合うのが、もう、めちゃくちゃに面白いからです。
むかしむかし、ISUCONのWebアプリケーション提供はPerl, Ruby, Node.jsのみで行われました。現代のISUCONではPerl, Ruby, PHP, Golang, Python, Java, Node.jsなどから、増えたり減ったりしつついくつも提供されています。
これは主催者が考えるに、スコアが出せるかどうかは言語の問題ではない、と思うからです。どの言語だろうと勝つ人は勝ちます。速い言語遅い言語で勝負がつくようなつまんない問題は過去一度も出されませんでした。
だがしかし、過去4回の優勝チームの使用言語は全てPerlでした。今年はどうかな?
ISUCONの技術
ISUCONでは様々な技術が必要とされます。もちろん、ごく基本的なWebアプリケーションを書く能力は真っ先に求められます。いわゆるWeb一般の知識、HTTPやHTML/Javascript/CSSなどの基本および応用的な知識も必要でしょう。
性能を出すためには各種ミドルウェアを適切に設定する必要もあります。Webサーバ、アプリケーションサーバ、データベース、Key-Value-Storage、OSなどは少なくとも一ヶ所ずつ手を入れることになるでしょう。
ISUCON出題者はナンセンスな設定を参加者に押し付けることはありません。最初からそこそこ動く設定はおそらく行われています。しかしスコアを出すためにはそこに安住できないのはもちろんのことです。
ISUCONで勝とうと思ったらアプリケーションの改造を恐れてはいけません。高パフォーマンスなアプリケーションを作るためには、適切なキャッシュの管理、RDBMSへのクエリの最適化と適切なインデックスの作成、データの持ちかたの変更、その他ありとあらゆる計算量・処理データ量の削減の努力が求められます。
それを最適な形で実現するために、アプリケーションコード以外のあらゆる部分の変更の可能性を検討すると同時に、アプリケーションコードの変更を組み合わせることを考えてください。
現代のISUCONはチーム戦です。厳しい制限時間の中で、2人が同じことをやっている余裕はありません。コミュニケーションをとり、お互いを信頼して作業を進めましょう。
そしてその結果をお互いにチェックしあいましょう。人間はミスをするものです。ミスを相互にカバーできるのがチームです。
ISUCONの勝敗
最終的に、勝敗はつきます。勝敗は大事です。勝つために参加しているのです。
しかし、最も大事なものは勝敗ではありません。決勝なら25以上のチーム、予選なら去年はなんと185ものチームが、同じ時間に、同じ問題に、同じ目的で、最大限集中して取り組んだということが一番大事なことです。
普段我々が手にできない、全く同じ前提条件でのフラットな技術的な議論ができる場が、そこにできるのです。
その意味では、ISUCON参加前と参加後に最も多くのものを持ち帰った人こそが勝者と言えるでしょう。
まとめ
ISUCONは超面白いので、今年のもたぶん面白くなると思うので、みんな参加したらいいと思う。
とはいえ、普段Webサービスを開発している人にとっては普段の仕事領域だけど、学生の人達にはRDBMSなんか触ったこともない、という人もいると思う。まあ機会なけりゃそんなもんだよね。しかしRDBMSを使ってみたという経験がこの後に無駄になることは100%ありえないので、ぜひこの機会にやってみてほしい。
ということで機会があります。学生の方はいかがでしょうか。isucon.net
さー今年のISUCONの問題はどうしよっかなー!
Hive GenericUDFの挙動がおかしい場合
コンストラクタで初期化処理をやってしまっていないか気をつけよう。
通常 GenericUDF を継承したUDFを実装する場合、初期化処理は initialize メソッド内で行う。コンストラクタで行ってはいけない。それでも古いほうのHiveのバージョンでは動くケースがあったようだが、Hive 0.13で動かなくなっているケースが出て難儀した。
なにしろデータソースによって動いたり動かなかったりする。普通にカラムの入力データを食わせると動かないが、入力データをHiveQLの中で文字列リテラルで与えると動いたりして地獄だった。動かないというのもエラーになるとかじゃなくて、なんかありえない挙動を示す。正規表現マッチのグルーピングが本来の挙動に対してひとつズレた結果が返ってくるとか。
詳しくはそこまで調べてないのであまり書くと嘘になってしまうが、どうもUDFのインスタンスを生成するタイミングと、それを実際に各Task内でinitializeするタイミングが異なるせいではないか、そしてその間に何らかのシリアライズ・デシリアライズが挟まってるのではないか、という感じ。Serializableでない内部状態をコンストラクタ内で作ってしまうと、それが再現できずに(あるいは中途半端に再現されて)以降の処理がおかしいことになる。
ということで、GenericUDFを継承したUDFを作るとき、初期化処理は initialize() メソッド内でやりましょう。
なおUDFを継承したUDFを作るとき(ややこしいな!)は、そのコンストラクタは実際にはGenericUDFのinitialize()から呼ばれるので、使ってよい、ということでした。id:myui さんに教えてもらった。詳しい人がそのへんに座ってるの超便利……!
Hadoop MapReduceのプロファイルをとる
Hadoop MapReduceのジョブは各スレーブノード上で1タスクごとにJVMが1プロセス起動する形で実行される。
で、それらのアプリケーションのプロファイルをとりたい場合、各々のJVMごとにとることになる。これにはhprofを使う。
Apache Hadoop 2.7.0 – MapReduce Tutorial
この記述に従って以下のプロパティをセットする。ジョブ起動時に指定すれば有効にできる。プロファイラのパラメータはデフォルトがあるという話だったけど、やってみたら指定しないとエラーになった。以下の指定は自分が試したとき用にいじってある。
mapreduce.task.profile=true mapreduce.task.profile.params=-agentlib:hprof=depth=4,interval=100,cutoff=0.001,cpu=samples,heap=sites,force=n,thread=n,verbose=n,file=%s # MRv1の場合は mapred.task.profile などとする
プロファイラのオプション指定についてはOracle Java SE doucumentを見ればいいのかなと思うけど、なんかいまいち詳しくない。自分が設定する分にはIBMのサイトの日本語解説が役にたった。IBMのやつとOracleので違いがあるかもしれないけど、特に気付かなかった。
HPROF: A Heap/CPU Profiling Tool
IBM Knowledge Center HPROF プロファイラーの使用
このオプションを有効にしてジョブを実行すると、ジョブ終了時(正確にはプロファイラを有効にしたtaskの終了時)に profile.out が生成され、そこにプロファイル結果が出力される。これはJobHistoryServerもしくはJobTrackerのWeb UIから該当のattempt(もしくはtask)を選んで*1、そのログを見れば見られる。いちいちHDFSやローカルファイルシステムに見にいかなくてもいいのは便利。
YARN MRv2での問題
MRv1ならこれだけで一発で結果が得られるんだけど、YARN + MRv2で実行しているとこの結果がちゃんと出てこない。起動時のバナーだけ見られたり、あるいはプロファイル結果の出力が途中でブチ切れた状態になっていたりする。
これはhprofの結果出力がJVMがTERMシグナルを受け取って働く終了処理の中で行われるからだ。んでYARNはTERMを送ったら250msだけ待って終了していないとすぐKILLを送る。ので、プロファイラの結果出力の最中でJVMがKILLられて結果出力がちゃんと得られない、ということになる。
この問題についてはApache JIRAにissueがある。Resolvedになっているが該当バージョンは 2.8.0 だ!
[MAPREDUCE-5465] Tasks are often killed before they exit on their own - ASF JIRA
2.8.0 を待っているわけにはいかないので、どうにか設定をいじってattemptのコンテナがKILLられてしまうまで猶予を作ってみる。これは各スレーブノードで設定して NodeManager を再起動する。
<property> <name>yarn.nodemanager.process-kill-wait.ms</name> <value>30000</value> </property> <property> <name>yarn.nodemanager.sleep-delay-before-sigkill.ms</name> <value>30000</value> </property>
ジョブのConfigurationを見てもこの変更が反映されていなくてアレっと思ったが、試してみた限りでは想定通りに動いているようだ。ちゃんとプロファイル結果が最後まで出力されるようになった。
何か副作用があるかどうかというと、もしかして特定の条件で30秒間だけ長く生き残ってしまうattempt containerが出てしまうかもしれないけど……まあ、特に問題でもないでしょう。
めでたしめでたし。
まとめ
Enjoy profiling!
*1:プロファイラが有効になっているものは明らかに実行時間が長くなるからすぐにわかる
