2012年11月06日

#isucon2 に向けて、かなり間違った方向に本気出してみた(recaro 誕生秘話)

はてなブックマークに登録

先日、NHNさん主催の #isucon2@methane と参加してきたので、事前準備や当日の状況などを数回に分けてレポートしようと思います。#isucon2 が終わって少し体調を崩していた @pandax381 です。

すべてはここから始まった

社内のIRCチャンネルで #isucon2 の開催が話題になっていて、隣の席の @methane が真っ先に参加を表明し、パートナーを募集していました。僕はというと、面白そうだなぁと思いつつも、WebアプリとかDBとよくわかんないし戦力にならんだろうと「椅子投げコンテストw」とか言ってスルーしていたんですが、@methane から「一緒に出ようぜ!」とルフィばりの熱い誘いを受け、参加を決意することになりました。ちょうど #isucon2 開催1ヶ月前の話です。

L7未満は全部なんとかしてくれ!

そんなこんなで #isucon2 への参加が決まり、準備とか何すっかなーと考えてたところ、ペアの @methane が驚愕のツイートをしてるのを発見。

15

ちょっwwwこれはヤバい。草とか生やしてる場合じゃない。「きっと @methane が全部なんとかしてくれる!」とか考えてたら完全に先を越された。まぁ、役割分担的に @methane がアプリを全部 Python で書き下ろしたり、SQLのチューニングをやるだろうから、僕はネットワーク周りとかロードバランサ・Webサーバあたりをやるのかなと思っていたけど。そんなわけで LVS で DSR 構成組んだり nginx をチューニングしたり、sysctl でネットワーク周りのパラメータ調整したりと、ベタな内容で社内にテスト環境を構築して ab でベンチマーク比較しながら最速の構成を考えてました。

最速のWebサーバを求めて

「やっぱり最速は nginx かねー」とか「meinheld を更にいじって nginx より早くしたったw」とか最速Webサーバ話に花を咲かせていたら、どこからともなく「つ khttpd・・」という声が。「khttpdとかオワコンw kernel 2.6系じゃ動かないし」と軽くスルーしてたんですが、またもや @methane から凶悪ツイートががが・・・

41

まぁ、ab ベンチマーク対決のために kernel module で Webサーバ書き下ろすとか完全に頭おかしいんですけど、ネタにマジレスしてみるのも面白いかなとか思いはじめて、お遊びでカーネル空間で動くWebサーバ「tkhttpd」を作ってみました。そしたら、コレが思った以上に性能が出て、物理サーバだと nginx の 5倍くらいの性能を叩き出し、見事「最速Webサーバ」の座を得たのでした。(Hello World のような単純なページを返すだけだと keep-aliveなしで 30,000 req/sec、keep-aliveありで 150,000 req/sec くらい出ていました)

ただ、このバージョンは ab 最速を叩き出すためのチート仕様(手抜き仕様)だったので、折角なのでもう少しまともな作りにしようと、joyent/http-parser(nginx のパーサを切り出したもので、node.js で使ってるやつ)を組み込んだり、リバースプロクシ機能を組み込んだりして、幾度となくカーネルパニックに泣かされつつも、Webサーバと公言して恥ずかしくない程度に仕上げていきました。

ユーザー空間に出たら負け。カーネル空間に引きこもろう!

「うぎゃ!カーネルごと死んだw」とか「カーネル先生まじパネェ!」とか独り言いいながら作っていたら、次第に周りの人達も興味を持ちはじめて、僕の周りでは空前のカーネル空間ブームが到来!パートナーの @methane も「じゃぁ俺はカーネル空間で動く memcached つくるわ!」とか言い出す始末。そして「kmemcached」というプロジェクトを見つけてきて、次はこれを動かしてみようということになりました。

しかし、この kmemcached がなかなかの曲者で、2年くらいメンテされていなくて、とりあえず動かしてはみたものの、並列処理ができなかったり、そのままカーネルごとお亡くなりになったりと、そのまま使うには課題の多い代物でした。まぁ、さすがに memcached まではやりすぎだよな・・・とか思っていたら、なんと @methane が数日で kmemcached を魔改造して実用レベルに仕上げるというマジキチっぷりを発揮してくれました。

この頃から、僕たち二人は「#isucon1 は DBへアクセスが行ったら負けだったようだけど、#isucon2 はユーザー空間へアクセスが行ったら負けだよね!」とカーネル空間に引きこもることを決意。(はい、どうみても完全に間違った方向に進んでます。本当にありがとうございました)どうせやるなら考え得るなかで最高のパフォーマンスを求めようと言うことで、可能な限りカーネル空間で処理するという作戦を選びました。

対 #isucon2 用 最終決戦兵器「recaro」誕生

こうして、僕と @methane が 約1ヶ月の期間を掛けて作り上げたのが、最終決戦兵器「recaro」です。kernel module で実装した Webサーバ「tkhttpd」と「kmemcached」をリンクして、tkhttpd から kmemcached のストレージにダイレクトにアクセスすることでmemcachedプロトコルのオーバーヘッドを取り除き、別次元とも言えるスピードを実現しました。

また、#isucon1 の教訓を生かして、キャッシュが腐らないように SSI も実装し、動的ページの生成にも対応しました。どうしてもカーネル空間での処理が難しいケースに備えて、tkhttpd のリバースプロクシ機能で、ユーザー空間で動いている別のWebサーバへリダイレクトして、キャッシュ更新までの処理を委譲する仕組みも盛り込みました。

その結果、最終的には #isucon1 のベンチマークで「DBへアクセスが行ったら負け」と言っていたお遊びチームのスコアを余裕で超える性能を出し「ユーザー空間へアクセスが行ったら負け」という僕らの考えは正しかった!と、既に #isucon2 で優勝する気満々で「優勝後のブログ記事はどんなこと書くか」とかそんな話題で盛り上がっていました。

そう、あんなことが起きるまでは・・・(つづく)


@pandax381
klab_gijutsu2 at 15:01│Comments(0)TrackBack(0)kernel | network

トラックバックURL

この記事にコメントする

名前:
URL:
  情報を記憶: 評価: 顔   
 
 
 
Blog内検索
Archives
このブログについて
DSASとは、KLab が構築し運用しているコンテンツサービス用のLinuxベースのインフラです。現在5ヶ所のデータセンタにて構築し、運用していますが、我々はDSASをより使いやすく、より安全に、そしてより省力で運用できることを目指して、日々改良に勤しんでいます。
このブログでは、そんな DSAS で使っている技術の紹介や、実験してみた結果の報告、トラブルに巻き込まれた時の経験談など、広く深く、色々な話題を織りまぜて紹介していきたいと思います。
最新コメント