みんなでバリバリチューニング!第2回チューニンガソン開催

ある秋の穏やかな昼下がり、渋谷の道玄坂を登り切った真新しいオフィスビルに、腕に覚えのあるインフラエンジニアたちが続々と集結しつつありました。10月1日。奇しくもこの日社名変更となったVOYAGE GROUP(旧社名、ECナビ)オフィス内の「パンゲア」ミーティングルームにて、第2回チューニンガソンが開催されたのです。

会場は、10月1日に社名変更したVOYAGE GROUPの会議スペース「パンゲア」にて
会場は、10月1日に社名変更したVOYAGE GROUPの会議スペース「パンゲア」にて 会場は、10月1日に社名変更したVOYAGE GROUPの会議スペース「パンゲア」にて

チューニンガソンとは

チューニンガソン(Tuningathon)とは、システムのチューニングとマラソンをかけ合わせた造語です。たとえばハッカソン(Hackathon)といえば、プログラマーが一カ所に集まり期間を限って集中的にハックするイベントですが、そのシステムチューニング版と考えればよいでしょう。

チューニンガソンでは、Webアプリケーションのパフォーマンスを向上させることを目的とします。ただし、アプリケーションプログラムそのものには手を入れることなく、下回りとなるWebサーバやDBサーバをチューニングしたり、そのほかシステム構成に手を加えることでどれだけ性能を発揮できるかを競います。

縁の下の力持ちになりがちなインフラ技術にスポットを当てるとともに、エンジニア間で知識や技能を共有するため、ゼロスタートの山崎徳之氏の呼びかけで7月9日に第1回が開催されました。今回はその第2回目です。39人、35組(ペア4組含む)のエンジニアが集合しましたが、無断欠席者なしという高い参加率にもその意気込みが表れています。

呼びかけ人の山崎氏。gihyo.jpの連載達人が語る、インフラエンジニアの心得でもお馴染みです
呼びかけ人の山崎氏。gihyo.jpの連載「達人が語る、インフラエンジニアの心得」でもお馴染みです

今回の競技ルールなど

チューニンガソンでは本番までお題が公表されません。当日明らかにされたチューニングターゲットは、⁠MediaWikiで構築されたWikipediaミラーサーバの読み込み速度」の向上です。前回がWordpressだったため、2回続けてPHPアプリケーションが選ばれたことになります。

参加チームにはAmazon EC2のミディアムインスタンスが2個ずつ割り当てられ、Amazon Linux 2011-02上のLAMP環境にMediaWikiがインストールされています。Wikipediaからダウンロードされた約150万項目がデータベースに登録されており、初期状態でWikipediaのミラーサーバとして動作するよう設定されています。なお、EC2のインスタンスはクラウドスポンサーであるAmazon Web Services LLCの提供です。

Amazon Web Services
http://aws.amazon.com/jp/

とはいえ、デフォルトでは毎秒0.8リクエスト程度のパフォーマンス。スコアは、秒間に処理できるリクエスト数をhttp_loadで計測します(条件は同一ゾーン内から4並列で100個のURLにアクセス⁠⁠。コンテンツの読み込みのみで、更新処理はありません。チューニングにかけられる時間は前回の2時間半から2倍の5時間に増えたとはいえ、2.0リクエスト/秒がひとつの目安になるだろうと当初は予想されました。

競技中の様子

12時ちょうどにチューニング開始です。参加者は思い思いの席から持参したノートPCでインスタンスにログインします。Macの利用者が半数くらいでしょうか。IT系のイベントとしては少ないほうかもしれません。堅牢性に定評のあるレッツノートがやや目に付きます。

いよいよスタート!皆、真剣な顔つきで取り組みます
いよいよスタート!皆、真剣な顔つきで取り組みます いよいよスタート!皆、真剣な顔つきで取り組みます

1時間ほど経つと緊張もほぐれてきたのか、少しざわつきはじめ、飲み物を取りにいったりトイレに立つ人も増えてきます。また、チーム内あるいは近くの席のエンジニア同士で相談する声も聞こえはじめます。

ペアのチームは相談しながら、また、一人でチャレンジしている人はリラックスしながらチューニング!
ペアのチームは相談しながら、また、一人でチャレンジしている人はリラックスしながらチューニング! ペアのチームは相談しながら、また、一人でチャレンジしている人はリラックスしながらチューニング!

イベントスタッフによって小さな音でBGMが流されていましたが(Twitterでリクエストも受け付けていたようです⁠⁠、ちょうど中間地点の2時半ごろ〈きゃりーぱみゅぱみゅ〉から〈あやまんJPAN〉という集中力が問われる選曲に騒然とする一幕もありました。このころには床に寝そべるなど、自分にとって楽な姿勢を模索する参加者も増えてきました。

最後は皆、チューニングしやすいスタイルで!
最後は皆、チューニングしやすいスタイルで! 最後は皆、チューニングしやすいスタイルで!

あと1時間となった16時ごろには、なかなか効果の上がらないことを嘆く声も聞こえはじめ疲れの色も見えてきます。あと10分となると運動会の徒競走でよく使われるクラシックの定番曲が流され、ラストスパートを煽り、そのままゴールインです。

りすこさんも運営&撮影部隊として大活躍!
りすこさんも運営&撮影部隊として大活躍!

結果発表

5時間のチューニングは長いようで短く、さまざまな手法が選択できるようでそうでもなく、前回と同じような「もう少しあれば」感でタイムアップしました。計測の間、しばしの歓談をおいて、いよいよ結果発表です。

優勝はhamanoさん。3.7リクエスト/秒という驚くべき数字を叩き出しました。この秘密はほかの参加者とは違ったチューニング手法にありました(詳しくはこの後⁠⁠。

優勝したhamanoさん
優勝したhamanoさん

準優勝には、前回チャンピオンのmethaneさんがさすがの貫禄を見せました。

前回覇者、今回2位となったmethaneさん
前回覇者、今回2位となったmethaneさん
3位のkarakaniさん(顔出しNG)までが3.5を超える高スコア!
3位のkarakaniさん(顔出しNG)までが3.5を超える高スコア!

以下、トップ10の順位は表のとおりです。約40組の参加者のうち4分の一が2.0を超え、トップ3は3.5を超えるという予想外の好成績となりました。

成績発表では10位から順に紹介され、それぞれがどのような手法でチューニングしたかを自らコメントしました。主なチューニングのポイントをまとめてみましょう

 IDスコア(リクエスト/秒)備考
1位hamano3.73128 
2位methane3.62312前回チャンピオン
3位karakani3.51609 
4位jbking3.25615 
5位netmarkjp3.17339 
6位haruta_makoto3.07282 
7位masudaK, mikedaペア2.95559 
8位Kazuho Oku2.32911 
9位n0ts, xcirペア2.04679 
10位ijin2.04330 

チューニング手法1:PHP

今回のお題では、Webの三層モデルのうちアプリケーションの負荷が大きな課題でした。まずMediaWiki自体が重いわけですが、アプリそのものに手を入れることは今回の禁則事項です。となるとチューニングターゲットになるのはPHPです。

対策としては、まずベータ版のPHP 5.4に入れ替えます。あわせて中間コードをキャッシュするアクセラレータ「APC(Alternative PHP Cache⁠⁠」をインストールします。この手法は前回のチューニンガソンで有効だったため、今回は多くのひとがが取り組んだようです。

さらに、MediaWikiのマニュアルにPerformance tuningのページがあり、mbstringをオフにするなどが記載されています。10位のijinさんのコメントで紹介されると、会場から「そんなページあったんだ!?」という声も上がっていましたが、使用するアプリケーションのマニュアルをチェックすることはチューニングにも有用ということでしょうか(3位のkarakaniさんも言及⁠⁠。

そんな中、2位のmethaneさんが紹介したPHPのビルドオプションが注目を集めました。コメントによると「PHPは、VMの命令ディスパッチをビルドオプションで変更できるんです。デフォルトは関数ポインタテーブルなんですが、これを⁠computed goto⁠に変えると若干速くなります」とのこと。詳細は本業の開発者ブログにphpを高速化するcomputed gotoとして紹介済みだそうです。

チューニング手法2:MySQL

データベース層であるMySQLでは、それぞれにさまざまなチューニングがされていたようです。コメントから拾ってみると次のような手法がありました。

Percona Serverを導入(10位のijinさん) ・InnoDB pluginの導入(9位:n0tsさんとxcirさんのペア) ・バッファプールを増やす(7位:masudaKさんとmikedaさんのペア) ・クエリキャッシュを増やす(3位のkarakaniさん)

さらにDB自体をPostgreSQLに入れ替えようと試みたチームもありましたが、MediaWikiのインストールディレクトリ以下は改変禁止というレギュレーションに縛られて設定ファイルが変更できず、実現できませんでした。また、methaneさんはPHP高速化のためにGree Fast Processorの導入も検討したそうですが、これも同ルールによってできませんでした。

一方で、2台のサーバで役割を分担した構成にすることは事前のルール説明でOKとされていましたが、そのためには同じく設定ファイルを書き換えなければならず、この矛盾した扱いをめぐっては最終的に残り2時間という時点で「LocalSettings.phpの$wgDBserverのみ変更可とする」というレギュレーションで決着をみました。

チューニングを競技とする際に公平性を担保するレギュレーションの難しさが課題として残ったと言えるでしょう。

チューニング手法3:Apache

Webサーバ層では、5時間でできることはあまりないと判断されたのか手を加えた参加者は少なかったようですが、1位に輝いたhamanoさんはApacheでコンテンツのキャッシュにチャレンジし、見事に成果を上げました。

アプリケーションが重いわけですから、アプリケーションに仕事をさせず、Webサーバのみで処理を完了できれば大幅な高速化が期待できます。しかし、今回はデータが150万項目のWikipediaで、そのうち100項目だけが計測されるというルールのため、中途半端にキャシュを作成してもまったくヒットしない可能性もあります。

このあたりをhamanoさんは次のように考えました。Apacheのmod_disk_cacheモジュールを使って、キャッシュがどれくらいのるか見積もったところ、ディスクには全部乗らないんじゃないかと予想されました。ですが、削除されたページもたくさん含まれていることに気づいたので、有効なページだけを見つけ出してキャッシュすることにしました⁠⁠。

さらに、⁠キャッシュを集めまくるために、クライアントをGNU Parallelを使って並行に走らせるということに14時ごろに気がついて、間に合いました」ともコメントしていました。詳細は、ご自身が第2回 Tuningathon チューニングメモで公開されています。

おそらく競技時間がさらに長ければ、キャッシュを作成するチームも他にあったことでしょう。そこを5時間という短期間で挑戦し、効果をあげられる手法を考えだしたhamanoさんのジャッジメントは、時間的な制約が課せられるトラブルシューティングに直面しがちなインフラエンジニアにとって必要な技術のひとつといえるのかもしれません。成果発表でも大きな拍手を浴びていました。

まとめ

最後に主催の山崎氏は、今回の結果に対して「2.0を超えればかなり上位かなと思っていたんですけど、それより上に行っているような状況で、予想以上に結果が良くて驚きました」と参加者チューニング力に舌を巻いていました。

また、今後については「3ヵ月に1回くらいは開催していきたいし、内容も1ヵ月半前には発表できるようにしたい。前回に続いて今回もPHPというのは非常に心苦しいのですが、できるだけ一般的に使われていて、普通にOSSとして流通しているアプリケーションを探したためです。どんなアプリケーションをチューニングしたいかも随時募集しますので、ぜひ意見をいただければとおもいます」と語りました。

大会のあとは懇親会がありました。アルコールも入れながら、今回の振り返りや結果についての議論、チューニングのポイントやインフラ技術に関する熱い思いを語りながら、長いチューニングの一日は暮れていきました。

お互いの健闘を讃え合い、情報を交換し、盛り上がった懇親会
お互いの健闘を讃え合い、情報を交換し、盛り上がった懇親会 お互いの健闘を讃え合い、情報を交換し、盛り上がった懇親会

当日の様子は、ゼロスタートの広報ブログにも「⁠⁠レポート】第2弾!いろいろチューニングしてパフォーマンスを競うバトルイベント!Tuningathon2として詳しく紹介されてみますので、合わせてご覧になると当日の雰囲気がよくわかるでしょう。

おすすめ記事

記事・ニュース一覧