Webアプリケーションの高速化に王道ありーーフロントエンドやWebサーバ、データベースにWebアプリケーション本体に至るまで、Webサービスを構成するあらゆる要素を制限時間内でチューニングし、最速を目指すコンテストが「ISUCON（Iikanjini Speed Up Contest）」です。LINEさんが主催する「本家」は既に7回目を数えるほか、有志が社内で独自にISUCONを企画・開催するケースも増えています。

リクルートテクノロジーズもその1つ。本家ISUCONに参加してその面白さに目覚めたメンバーが経験を持ち帰り、勉強会も兼ねて「R-ISUCON」を開催してきました。

さまざまな「気付き」「知見」が得られるという意味では、ISUCON参加者全員が勝者なのですが、競技という形を取る以上、得点面でどうしても勝者と敗者が生じます。負けたチームにとっては、雪辱を果たして負けた悔しさを晴らす機会が早く欲しいーーということで、2017年12月の第2回からそれほど時間を置かず、2018年3月30日、31日の2日間に渡り、「R-ISUCON 2018 Spring」が開催されました。

今回は、日ごろからお世話になっているライターの高橋　睦美さんに現場に潜入いただき、レポートしていただきました！(written By Mutsumi Takahashi)

会議室予約システムを高速化せよ！

3回目に当たるR-ISUCONは、リクルートテクノロジーズだけでなくリクルートグループ全体に参加対象を広げました。

時は折しも年度末。グループ全体が忙しくなる時期にもかかわらず運営側の想定を上回る多くの参加者があり、三浦海岸の宿泊所に集まった約50名とリモート参加の社員、計60名あまりが腕を競いました。

本家ISUCONに習って、第2回のR-ISUCONの優勝チームメンバーが問題作成・運営に当たりました。

過去2回のR-ISUCONではpixivさんやヤフーさん、が実施した「過去問」を流用していましたが、R-ISUCON 2018 Springでは「リクルートらしい問題作りをしたかった」（古川陽介さん）ということで、オリジナルの問題サーバを作成。宮地克弥さんと與那城有さんという2人の新入社員を含む運営チームは、ただでさえ忙しい年度末の合間を縫って準備を進めてきたそうです。

▲今回の運営メンバー。左から、髙橋憲一さん、濱岡俊介さん、與那城有さん、宮地克弥さん、古川陽介さん

チューニングの対象として用意された問題サーバは「りすこん会議室予約システム」というものです。
リクルートの中の人なら、四半期はじめの会議室予約の大変さを思い出してニヤリ、とされるかもしれません。

これはAmazon Web Services（AWS）上に、CentOS、NginxとMySQLを組み合わせて構築された会議室予約システムで、WebアプリケーションはJava、Node.js、Goの3種類で実装されていました。「リクルート社内でよく使われている言語、3つを選択しました」と古川さん。

できればPythonやRubyなども用意したかったそうですが、異なる癖を持つ言語を使い分けて同じ仕様のWebアプリを複製する作業はなかなか大変で、残念ながら間に合わなかったそうです。

りすこん会議室予約システムは、名前の通り会議室予約のためのWebアプリです。「データベースも知らず、フロントエンドもよく分からないような新入社員が作った、という想定で作りましたが、新人でもこんなダメなコードは書かないよね、っていう実装になりました」（古川さん）。逆に言えば、それだけチューニングできる余地があちこちにあった、というわけです。

実は当日、13時に予定されていた競技開始時間が、ベンチマークサーバの不具合で1時間ほどずれ込みました。運営側は急遽「リアルISUCON」でトラブルシューティングしつつ、暫定的にりすこん会議室予約システムに外からアクセスできるようにしたのですが、早速パフォーマンスを計測しようとChrome Dev Toolsなどを用いて解析に取りかかった各チームからは「重っ！」「何これ、ひどい！」の声が上がっていました。

理由の1つは、圧縮されておらず13MBもあったCSSです。「サーバサイドのエンジニアならばまずアプリケーションやバックエンドを疑いがちだけれど、実はフロントエンドが重かった、という仕掛けです。最近では回線速度の向上もあってCSSのミニファイが怠られることもありますが、原点回帰、それから嫌がらせも兼ねて（笑）用意しました」（古川さん）

もちろん、チューニングのポイントは他にもたくさんあります。「より多くのリクエストをさばけるようになればなるほど、ボトルネックのポイントは変わってきます。データベースネックからCPUネック、フロントネックと、Webアプリサーバを使い倒そうとすると、その時々のタイミングによって考えなくてはいけないポイントが変わってきます」と古川さんは述べ、フロントエンドもバックエンドもまんべんなく対応できる力が問われると説明しました。

新入社員から役員まで、横一線でもくもく

R-ISUCONは、30日14時から翌日の13時まで、1泊2日の合宿形式で行われました。ベンチマークが無事動き出してからは各チームとも目の色が変わり、用意してきた小型のホワイトボードにフローや要点を書き出したり、持参の専門書やWeb上のコマンドリファレンスを参照してはconfigを書き変えたりと、思い思いにチューニングに取り組み始めました。

中には、リフレッシュして新しい発想を得ようと海岸に繰り出してエクストリームプログラミングしていたチームもあったようです。

中でも異彩を放っていたのは、エグゼクティブ・執行役員ら3名で構成された「EMSM」チーム。普通の企業の執行役員のイメージはPowerpointやExcelで上がってくるレポートを見ながら判断する人、というものでしょうが、彼らがいじっているのはgitのリポジトリ。

他のチーム同様に、「シンタックスエラー出るの、何でかなぁ……」などとぼやきながらもくもくとPCに向かっていました。

集中する「EMSM」チーム

おいしい夕食も用意されましたが、各チームはリフレッシュもそこそこに各部屋に引きこもり、もくもくと作業に取り組んでいたようです。中には、他のチームメイトが寝てからもチューニングを進めてハイスコアをたたき出し、嬉しいけれど同僚を起こしてはいけないと、1人でひっそりガッツポーズを取った人もいたとか。

実際、Slackのログに張られたスコアボードからも分かるように、序盤は動きの少なかったR-ISUCONでしたが、夜がふけるにつれ勢いは増し、運営チームが寝静まった後に何と100万点を超えるスコアが記録されました。古川さんらは当初、「数十万点台の勝負になるだろう」と見込んでいたそうですが、それを遥かに上回るハイレベルな争いになりました。

夜が明けて2日目、競技の最終盤になると、体力や集中力もかなり限界に近づいてきます。その中でも粘り強くチューニングに取り組み、「やっと爆速にできた！ 何でこれに気付かなかったんだーーー！」と叫ぶ声が聞こえたりと、競技は最後まで白熱し、最後の最後までベンチマーク待ちのキューが並びました。そして競技終了後には、あちこちから「こんなに難しいと思わなかったけど、新しいことが学べた」「何もかも足りないことが分かった」、そして「疲れたけど、楽しかったぁ！」という声が飛び交いました。

優勝を飾ったのは、ISUCONに特化したチューニングをしなかったチーム

最後に、問題サーバの種明かしと結果発表、講評が運営チームより行われました。

まず最初に古川さんが、

・CSSファイルの改善
・ログインセッション周りの改善
・Imagemagicによる画像変換処理の変更
・SQL文（いわゆる「n+1問題」）の最適化
・画像ならびにCSSのキャッシュ活用

という「想定回答」を紹介し、「このあたりに気付けば、数十万点の壁を乗り越えられると思います」と説明しました。ただ、実際にはそれ以上のスコアを記録したチームがあり、まさに「未知の領域」だったそうです。

上位に入ったチームでは、gzip staticをオンにしたり、Nginxでhttp2を有効にしたり（ベンチマークサーバ側の挙動に怪しい部分があったためどこまで有効だったかは不明ですが）、JavaのThymeleafテンプレートエンジンの代わりに文字列を内部で生成したり、かと思えばSQLのn+1問題を解決するため「ユーザーの所属する組織は2の24乗通りしかないので、これを2の12乗通りずつに分けて処理し、マージすることで高速化した」という技を駆使したり……と、思いもよらない知見が紹介されました。

特に強い印象を残したのは、上位の2チームです。

2位に入った「後で決めます～」は、メンバーの一人が以前リクルートマーケティングパートナーズ（RMP）社内で行われたISUCONで最下位に終わり、そこから巻き返しを図るべく参加したそうです。想定回答に挙げられた策をしっかり講じただけでなく、「実行するタイミングによって、ベンチマークのスコアがけっこう変わることが分かりました。そこで、たくさんベンチマークを実行する方がいいと思って、寝ている間に3分に1回のペースで自動でベンチマークを回すようにしました」とのこと。

ベンチマークの夜間自動実行という思わぬ発想に会場は大爆笑に包まれましたが、こうした努力もあって134万453点を記録しました。

▲2位の「あとで決めます～」

堂々の優勝を飾ったのは「Theorem」で、何と216万7317点というハイスコアを記録しました。ISUCON向けにさぞかしかりかりにチューニングしたのかと思いきや、「コンセプトとして、ISUCONに特化したチューニングはしたくなかった」とのこと。

AWSのインスタンスで2コアを使い切るようクラスタリングするなど、実サービスでも通用する手法を実践しての結果に、会場はどよめきました。

▲1位の「Theorem」の3人

Theoremでは3人のうち1人が計測、残る2人がチューニングを実施したそうです。パフォーマンスチューニングというと、目の前の仕組みの個別最適化ばかりに集中してしまいがちです。しかしTheoremは、「急がば回れ」ではありませんが、全体を見据えたチューニングに取り組んだことが印象的でした。

「キャパシティ以上のリクエストが来るとさばききれず、そこがボトルネックになることが分かったので、想定以上のリクエストが来たらNginxで500を返して、スムーズにレスポンスを返すようにしました」という戦略には、聴いている側が思わず「なるほど！」「ユーザーが多いときの流入制限と同じだ」ともらしていました。

またSQLに関して、selectを使いまくっていた最初の状態を修正し、joinで1つにまとめて高速化したチームはいくつかありました。ですがTheoremでは「select文を1つではなく、あえて『自分がどの部屋を予約できるか』と『何の予約があるか』の2つに分けてまとめました。予約可能な部屋はユーザーの所属が変わらない限り変更がないため、今回はそこは無視して、ユーザごとにどの部屋を予約できるかをRedisでキャッシュするようにしました」と、やはりひと味違ったチューニングを実施していたそうです。

ちなみに第2回のR-ISUCONでは、ベンチマークの得点のみが指標でしたが、「実は再起動に失敗していたので、その反省を踏まえ、今回は、再起動チェックに失敗したチームは失格とするレギュレーションにしました」（古川さん）。残念ながらその再起動チェックにひっかかり、涙をのんだチームもありました。

こうしてR-ISUCON 2018 Springは幕を閉じました。

参加者にとっては、新人からベテランまでさまざまな社員が参加し、ほぼ24時間に渡る競技とその後の振り返りを通じて、高速化に向けた新たな知見やアプローチを共有できる貴重な機会になったようです。古川さんは「パフォーマンスは、非機能要件の中でも重要な要件。リクルートグループのさまざまなエンジニアが集まり、互いにどんな思想で、どんな風にパフォーマンス向上に取り組んだかを知り、知見やツールを共有することで、皆の技術力アップにつながるのではないかと思います」と述べました。

またEMSMの一員として、リベンジも期して参加した宮川典久さん（リクルートテクノロジーズ執行役員）は、リクルートグループからこれだけの参加者があったことを踏まえ、「この規模でヨコのつながりができる機会はなかなかないこと。今後も定期的に開催し、リクルートのエンジニアが一体となって取り組んでいけるように交流し、ヨコのつながりを増やしていきたい」と述べていました。

なお、皆が競技に没頭してしまったため出番はありませんでしたが、スーツケースいっぱいに「ドミニオン」や「カタン」といったボードゲームを持ち込む社員もいました。次の開催時には、そんな余暇を楽しむ時間ができる……でしょうか？ 早くも次回に期待大です！