ISUCON4 で "BIG丼 (学生枠)" が1日目予選トップを取れた理由

ISUCON4 予選に参加されたみなさん、お疲れ様ですー。
"BIG丼" というチーム名で学生枠で参加していた @hktechno です。

チームメンバーは

• @hktechno
• @KIM_TPDN
• @ipv4

の3人で参加しました。

全員筑波の入院生活民で、全員 SECCON CTF とかも出てるメンバーです。

全員 ISUCON 初挑戦です。準備も、何もしていませんでした。

まずは結果から...

僕達は、1日目の予選に参加したのですが、結果は以下のとおりです。

• ISUCON4 オンライン予選 一日目の結果発表 - ISUCON公式Blog

なんと、一般枠のチームを破り予選トップ！！

ISUCON という競技の性質上、そんなことがあっていいのか！

どうした現役インフラエンジニア！

と思うかもしれませんが、嘘を付いてもしょうがないので懺悔します。

正統派の方法で勝ち取った成績ではありません！！

1日目に提供されていたベンチマークプログラムにバグがあって、意図しない時間ベンチマークプログラムを流すことが出来る状態でした。

ベンチマークプログラムに与える workload のパラメーターの数値を極端に大きくすると、過負荷状態になって (load avg 100 とか) 本来想定していた時間に終了しないでベンチマークが流れてしまい、得点が上がるというバグを突いて驚異的な成績を叩き出しました。

これに気づいたのは、終了1時間ぐらい前でした。

少しつづ workload の数値を上げていくと、僅かながらベンチマークの数値が向上する現象を確認したので、頭打ちになる数値を確認していたのですが、上げれば上げるほど向上していくし、100を超えても上がり続けるんです...

そこで、あれ？なんか、おかしくね？なんかベンチマーク終わるの遅くね？って気づいたのですが、もしかしたらそういうゲームなのかもしれない...  あるはずないだろ！

と思いながら少しづつ観察していたのですが、300 とか 400 に上げたあたりで5分以上ベンチマークにかかる状態になり...

流石におかしいと思って、残り15分でサポートチャットで、この現象が意図したものか、違反ではないかということを確認しました。

この時点では、workload の数がいくつかとか、どうやったら発生するかとかは隠したままです。

あえてギリギリに報告したわけではないですが、この時間ではこれに気づいた他のチームも、たぶん同じことは出来なかったでしょう。

でも、既にこの問題に気づいていた他のチームもあったみたいです。

結果的に、今のところは最終的な結果は認められているようですが、2日目にはこの問題の修正が入ったようです。

ISUCON4 本選出場の一部基準変更について - ISUCON公式Blog

出場枠の扱いについてもいろいろ変更があるようです。

詳しくは、運営の皆さんからのアナウンスを待ちましょう。

僕達の本戦出場も、AMI 検査もありますし、結果が正当なものではないのでどうなるかはわかりません。

いろいろあると思いますが、こういう事態はコンテストにはつきものですね...

それがひとつの醍醐味でもありますし？

それと、全員 SECCON CTF の全国大会出場メンバーだからって、別に  benchmarker を逆アセかけて解読したりはしてないですからね...

運営の皆さんは、お疲れ様でした。

正統派な方法でどこまでやったか...

チートの話を聞いてもしょうがないので、少しちゃんとした話もしましょう。

僕達のチームの最終的な提出結果は --workload=350 で 

tag:benchmarker type:score success:401684 fail:166 score:86974

でした。 

--workload=16 ぐらいにすると、大体 20000 点台でしたね。

なので、本来は全然本戦出場枠に届いていないです。

基本的には、DB に Index をつけて、MySQL と Unicorn を TCP ではなく Unix Domain Socket を使うようにして、static なファイルを nginx から配信するようにして、TCP TIME_WAIT 対策をして... ぐらいで昼前に 20000 点超えた気がします。

午後からは、Ruby 2.1 にしてみたり、DB のスキーマとコードに手を入れていたのですが、どちらも完全に逆効果だったので、元に戻しました。

/ が、ほぼ静的なページなのでどうにかしようと思ってましたが、うまくいかなさそうなのでやめました。

なので、ほぼコードには手に入れてない状態です。

チートな方法では、ファイルディスクリプタの制限にかかり始めたので、limits.conf や ulimit をいじって上げたりもしました。

ISUCON は、コードから手を入れるのは沼にはまっていくのはわかっていたので、午前はいじらずに行けるところまでいって調子良かったのですが、午後からつまりましたね...

結果的に、午後からはほぼスコアが向上しなかったです。

>> 追記
その後、延長戦を勝手にやっていたのですが Sinatra が development モードで動いてる事がわかり、production モードで動くように設定したら一気にスコアが向上しました。
さらに、MySQL のパラメータをちょこっとチューニングしたら、38000 ぐらいまでスコアが上がりました。

うまく改善した効果が出なかったのはこんなボトルネックがあったとは...
これはひどい。
>> 追記ここまで

敗因は、何が原因で詰まってるかを解析する方法がちゃんと用意出来ていなかったので、完全に手探りだったところですかね...

次出るときは、その辺りをちゃんと固めたいと思います。

まとめ

なにがさすがだ。実際はゴミクズ以下だった僕を慰めてくれ。

PyCon JP 2014 で Micro Python の話をした #pyconjp

9月13,14,15 の3連休は PyCon JP 2014 に参加してました。
参加してました、というか僕は今年もスタッフ側です... (これとか)

スタッフ話は別のエントリで書くとして、今年はスピーカーとしても参加しました。
Micro Python の話をしてきました。

LINE のインターンシップに参加してきた

8月中はずっと LINE 株式会社でインターンシップをしていました。
はい、噂のアレです。

お前も40万円に釣られたのか！！って思うかもしれませんが、なかなか答えづらい質問ですね。
とはいえ、LINE ってよく考えたらインターンに行くにはすごく魅力的な会社じゃないですか？

• 登録ユーザー数 x 億人のアプリ
• 出来てからまだ3年しか経ってない
• サービスの質もよく出来ているように見える
• なのに、日本ベースの会社
• いい噂も、悪い噂も沢山
• サービスの仕組みやプロトコル、バックエンドの規模が割と謎

せっかく機会があるのだから、これに飛びつかないのはもったいない気がします。

実際の所を言うと、他のインターンシップに申し込んでいてのですが落ちて、丁度その後申し込むのにいい期間に募集を行っていて、かつ8月中の1ヶ月間というのが僕にとってすごく予定的に都合が良かったので、他と吟味した結果申し込んだ感じです。

また、40万円という重さが逆に良い面もあって、それだけ重さのある業務に携われるし、結果も求められる、という意味では悪くないかと。

IT 企業のインターンシップというと、よくあるのがインターンシップ参加者でグループを組んで... とか、新しいサービスを... とか、弊社社員が講義を... とか、そういうところも多いと思います。

今回の LINE のインターンシップは、個人の能力にあった部署に配属されて、そこで個別に課題をこなしていくという感じで、実際に会社の業務が体験できるような形式でした。(僕はこっちが好き)

ただ、この方式だと、人によってやったことも満足度も違うと思うので、このエントリはあくまで僕の感想ということで。
せっかくなので、参加してきて思ったことを書ける範囲で書こうと思います。

インターン期間中の課題

僕は、LINE サーバー開発室という、LINE のメッセージアプリケーション本体のサーバー開発・運用を行っている部署に配属されました。
その中でも、HBase を管理しているチームのチューターさんにお世話になって、HBase 関連の仕事をインターンシップでやりました。

LINE のメッセージアプリケーションのストレージはメインとして、今現在は HBase が使われています。
LINE のインフラでオープンになっている情報は以下にまとまっています。

• http://www.atmarkit.co.jp/ait/articles/1404/23/news034.html
• http://developers.linecorp.com/blog/?p=3041
• http://developers.linecorp.com/blog/?p=1420

僕が扱っていたのは、上の記事に書いてある通りの以下のようなものです

メインストレージとして利用されているHBASEの総容量は1PBに上っている。また、ログ解析、統計に活用されているHadoopの総容量は7PBで、そのうち約42％が使用されている。

そうです、LINE の PB 級のストレージが目の前にある状況に1ヶ月間居ました。インフラ好きにとっては堪らないインターンシップでした。

実際にインターンの課題としてやっていたことは、HBase や HDFS のサーバーが大量にあるので、だんだん管理とメンテナンスが大変になってきているようで、それをまとめて管理できるようなツールの開発です。
特に、HBase, HDFS の metrics の監視、RegionServer, DataNode の起動・終了、Region の移動などを Web から操作出来るような監視ツールを作っていました。

Hadoop や HBase の経験もほとんどなかったのですが、なんとなく知っている知識とチューターさんからのアドバイスを得て、HBase や HDFS についてちょっとだけ知識を得た気がします。
開発言語は特に指定はなくて、やりやすいものを使ってくれという感じでしたが、Hadoop 周りの環境はすべて Java で書かれていますし、その他諸々の理由で Java + Play Framework 2 を選択しました。

個人的には、Java を開発した経験はそれまで殆どなかったのですが、それなりにうまく馴染めたので、Java と Scala (view だけ) を使った良い開発経験になりました。

LINE インターンシップでよかった所

LINE の裏側がわかった気分になった

やっぱり、LINE のインフラを知ることが出来た事が個人的には大きな経験になったと思います。
特に、インターンの人たちには隠される情報などなく、むしろサーバーアーキテクチャの解説を時間を取って説明してくれたり、いろいろな質問に答えてくれたり、社内のコードも見放題でしたし、運用中のサーバーを触らせてくれるなど、とても自由でした。

実際の開発会議にも何回か参加させてもらいました。
LINE は日本の会社ではありますが、元々 NAVER だったこともあって、今では韓国の人がすごく開発に関わっています。
なので、会議も韓国とビデオ会議でやりますし、出張も多い感じで、アジアの中とはいえ非常に国際的な会社ですね。悪い意味の日本文化はあまり無くてよかったです。

また、韓国の人もみんな日本語しゃべれるのでコミュニケーションも問題なかったですし、仲良くなれて楽しかったです。
それ以外にも、日本と韓国、更にそれ以外が結構混じりあっているので、開発系の文章などは英語のやりとりが多い感じでした。

ちなみに僕は行きませんでしたが、インターンシップ生で韓国に出張に連れて行ってもらってた人も居ました。(ちょっと驚き)

コードレビュー

また、開発した成果は GitHub Enterprise 上で Pull request を投げる方式で開発していったのですが、書いたコードに対して丁寧にコードレビューをして頂きました。
実際の業務と同じように、Pull request とレビューコメント、そのレスポンスは全て英語でやりとりしました。

チューターの方には "これでも実際の業務よりは甘い" と言われてしまったのですが、僕にとっては自分のコードを人にレビューされる機会はそんなになかったですし、とてもよい経験です。
自分の癖や気づけない所が結構あって、自分も結構適当なコード書いてるな... と反省する機会になりましたし、視点が変わりましたね。

英語 Pull request 力が少し高まったので、これからも精進していきたいです。

会社の雰囲気

会社の中は、とても過ごしやすいですし、かなりいい感じです。
カフェもあって、気軽にコーヒーが飲めます。LINE キャラクターをラテアートしてくれます。

LINE のキャラクターが至る所に書かれていたり、社員の人がみんな机にグッズをおいていたり、オフィスの雰囲気がすごい楽しいです。
椅子は、アーロンチェアです。全く背中も腰も痛くなりません。

LINE インターンシップに参加した仲間

今回のインターンシップは、合計10名が参加していました。

他の人の課題は、スタンプの解析や、ボット作成、ショップの機能追加、fluentd の何か (実際に upstream にパッチ投げてた)、アプリの作成、などでした。

LINE は CTO が女性の方なのですが、そのおかげもあって？かこの手のインターンシップでは珍しく、参加者に女の子も3人居て diversity を感じましたね。
しかも、そのうち2人はインフラ寄りの部隊で、がっつりコード書いてました。

特に同じセンターだった、自称 Python アイドルとか、突然数学について目をキラキラさせて話し始める氏とか、Python 書いてた毎日ごはんに誘ってくる氏にはお世話になりました。
他のセンターの人も、皆さんお疲れ様でした。

他の参加者のブログも載せておきますね (随時追加)

• http://cocodrips.hateblo.jp/entry/2014/08/30/224335
• http://onedd.net/2014/09/internship-line/ (タイ語)
• http://iridium77.hatenablog.com/entry/2014/09/07/161511

さいごに

今成長中のアツい会社で、有意義な1ヶ月が過ごせたと思います。

このタイミングでこんな会社にインターンシップにいけたのは、自分にとってはとても良い経験になりましたし、とても満足しました。

1ヶ月という期間は、短いようでしたが、調度よかったようにも感じます。(実際これ以上長かったら参加を躊躇していたかも？)

ちなみに、超個人的見解ですが、LINE はいろいろな噂がありますが、安心して使えてよく出来ているメッセージングアプリだと、このインターンシップに来て思いました。(これ以上はいろいろあるので言えませんが)

僕も、インターンシップに来る前までは半信半疑でしたし、余り使っていなかったのですが、インターンシップに来てから LINE をもっと使っていこうと思いましたね。

大学院生最初で最後の楽しい夏が終わってしまった気分です...

40 万円は... 趣味の車や電子工作に使いたいところですが、そんなに遊んでる暇もないので、QoL の向上 (?) に使いたいと思います。

でも、旅行とかいけたらいいですね。

FreeRXduino で GR-SAKURA のローカルビルド環境を整えてみた

最近、GR-SAKURA の Web コンパイラのバックエンドライブラリとして使われていた、RXduino が自由にダウンロードできるようになり、FreeRXduino として公開されたようです。
http://rx.tokudenkairo.co.jp/freesoft.html

今まで、GR-SAKURA の開発環境は、Web コンパイラがあったわけですが、そのプロジェクトをローカルにダウンロードして、手元でビルドすることはライセンス的に不可能でした。
(詳細: http://rx.tokudenkairo.co.jp/license_gr.html)

しかし、FreeRXduino が公開されたことで、手元のローカルマシンでビルドすることが、ライセンス違反なく、自由にできるようになります。
ただし、オープンソースではないので、ビルド環境ごと再配布したり、RXduino を改変した物を公開したり、 GPL のソースコードとともにコンパイルしたバイナリを再配布したりすることも不可能です (LGPL なら問題ないはずです)。

# ちなみに、最近 Web コンパイラに、GR-SAKURA ライブラリ v2.00 が追加されました。こちらはオープンソースとなるようですが。つまり、RXduino は終焉の方向？

そこで、久しぶりに GR-SAKURA を持ちだして、少しいじってみました。
(とはいえ、実は目的があってのことなのですが、それは後日)

xv6 を自作 CPU に移植して mruby を動かした話をした #kernelvm

先日の日曜日、第十回 カーネル／VM探検隊＆懇親会 (#kernelvm) に参加してきました。
相変わらず、カーネルVMは濃かった。僕の低レイヤー欲が非常に満たされる感じでした。
何故か、PDP-11 が熱かったです。勿論、美しいアーキテクチャですが、かと言って今の時代に PDP-11 というのも変な話ですが。

その前の週に LinuxCon Japan 2014 も学生無料枠 (first50) 参加したのでで、非常に濃い1週間でしたね。各所で話題になっていた、"ワタシハリナックスチョットデキル" Tシャツも頂きました、大切に使います。

ところで、僕はどんな LT をしたかというと、卒論ネタに少し絡めて発表しました。
卒論は主に SSDAlloc という、ハイブリッドメモリアーキテクチャ？を元に mist32 プロセッサの MMU を改造してフラッシュメモリをメモリの一部のように利用できる MMU を提案してみる、みたいな研究でした。
そこで、mist32 プロセッサ向けに OS を何か移植する必要があって、更に何かアプリケーションも動かす必要があったので、その時の話をちょっと。

具体的には、xv6 という UNIX V6 を参考に作られた x86 向けの MIT で使われている教育用 OS を、mist32 に移植して、更にその上で mruby を走らせられるようにポートしました。

xv6 移植については少し wiki の方にまとめました。
http://open-arch.org/software/porting_xv6

スライドは以下に乗せておきます。
もっと詳しく書きたいのですが、時間もないので聞きたいことがあったら気軽に @hktechno に聞いてください。

# しかし、自作プロセッサを作って OS を移植した程度では、#kernelvm 的には何の驚きも提供出来ないことがわかったので、さらなる高みを目指す必要がある。

xv6 + mist32 + mruby from Hirotaka Kawata

SECCON 2013 全国大会に参加してきた

今年も、SECCON 2013 の全国大会に AC な ifconfig チームとして、参加してきました。
メンバーは、@x86_64, @KIM_TPDN, @rkmathi, @hktechno という AC な感じです。
結果はというと、20チーム中5位でした。(たぶん)
まずまずといったところでしょうか。去年は6位だったし。
持ち帰れる問題が少なかったので、結局夜はしっかり寝れて今までの SECCON のなかでは、体力的に楽な感じでした。
(本当はあったのけど、ダウンロードが完了しなかったので、諦め。)

普段から CTF に参加している人達を集めたわけでなく、セキュリティ専門系の人はくりす (@x86_64) だけでしたし、僕を含め SECCON 以外の CTF に殆ど出たことない人で ifconfig チームは構成されています。
なので、地方大会ならまだ良いのですが、全国大会レベルになると、やはりくりすに頼りきりな感じでした。
筑波からは、もう1チーム出ていて、後輩ですが urandom チームが3位になっていました。

個人的な感想としては、Metasploit などのツールやシェルコードの構築の仕方、突けそうな場所の探し方など、普段専門的なことをやっていない事もあって、慣れてないと負けますね...
時間をかけて解くことはできるのですが、調べてる時間に追い越されますし、難しい。

特に、今回の SECCON は、いち早くフラグを立てて、他チームを防衛することで点数を大きく稼げる点数方式だったので、単純に解けることより、素早くコントロールを奪える事が重要でした。
それぞれのサーバーを進んでいくと出てくるキーワードのポイントが1個 100 点であるのに対して、フラグは立てておくだけで5分おきに数十ポイント入ってくる(山分け)ので、独占してフラグを立て続けることが大事です。
防衛方法も、徹底して自動化することで、他を寄せ付けないことも重要な気がしました。

実際、僕達は1日目の後半に某チームと ssh セッションを殺しあう肉弾戦になりましたが、残念ながら2日目は対策をされて手が出ませんでした。
結局、キーワードは結構見つけてそれなりにポイント確保したのですが、全くフラグをまともに建てられず、みるみる差を付けられていった感じですね。特に2日目。

今年も参加してみて思ったけど、CTF はいろいろな知識を網羅していないと解けないし、自分の知識や技術を向上する機会になるので、楽しいし見直す機会になってとても良い。
こんなものに、政府が支援しても良いのかという話があるらしいけど、攻撃だけではなくて、防御もしなければいけないし、攻撃しなければ防御する方法も学べないし、セキュリティの分野は、近年は綺麗事言ってる所ではないぐらいヤバいので、それについてちゃんと世間の理解が浸透して欲しいところ。
防御側として攻撃手法について理解があるのは当たり前であるので、それを手っ取り早く学べるのは、CTF だったりすると思うし、攻撃手法を学ばせてはいけないというのは、何かおかしい。
まあ、グダグダ言ってないで、自分でセキュリティ知識の理解を深めてから発言してほしいものだと思う。
セキュリティの専門家で、CTF 反対の人がいたら、またその意見も聞いてみたい。

ところで、今年はニコニコ生放送があったり、NICT の NIRVANA 改 という可視化システムが運用されていたり、去年よりなかなか面白かったです。
まあ、目の前の画面に集中して、それどころではなかったですが、可視化システムはたまに各チームから噴水が発射されてて興味深かったですね。