100万件溜め込んだWebメールを一番「いい感じ」にできたチームは? - R-ISUCON 2019 winter レポート
山田青来
※編集注記:このイベントは、緊急事態宣言発令前の2020年2月に実施されたものです。
日々多くの人が当たり前のように利用しているWebサービス。その背後では、データベース、サーバシステム、フロントエンドの多種多様な技術が複雑に絡み合っています。ユーザーが「快適」「サクサク」と感じるサービスの裏には、エンジニアによる「高速化」の技が必ず隠れているのです。
この「Webサービスの高速化(チューニング)」を競技化し、毎回多くの出場者を集めているイベントとして、LINE社主催の「ISUCON※(Iikanjini Speed Up Contest)」(http://isucon.net/)があります。現在では、ISUCON形式のイベントを、エンジニアの学びや交流の場とすることを目的に、社内で独自に開催する企業も増えています。
リクルートでも、「R-ISUCON」という名称で、そうした「社内ISUCON」を定期的に開催しています。その第6回目となる「R-ISUCON 2019 Winter」が、2020年2月に、都内にあるホテルフクラシア晴海で開催されました。今回は、広報の山田よりレポートをお届けします。
※ ISUCONはLINE株式会社の商標または登録商標です。
これまでは、都心から少し離れた場所で行われることが多かったのですが、今回の会場は、リクルートグループの企業が多く集まる千代田区丸の内の東京駅前から、バスで30分ほどの場所。イベントがスタートする14時半が近づくにつれ、参加者が続々とホテルの研修室に集まり始めました。どの参加者にも移動疲れはなく、まだ体力、気合いともに十分な様子です。
●2日にわたるチューニングバトルが開幕
このイベントでは、1~3名のエンジニアで構成されたチームが、運営から出題される、必要最低限の機能だけを備えたWebサービス(参考実装)のチューニングに合宿形式で挑みます。制限時間は、出題が行われてから翌日正午までの約21時間。各チームはレギュレーションに沿ったベンチマークを随時行い、最終的に一番高いスコアを記録したチームが優勝となります。第6回となる今回は、29チーム78名が参加。前回の第5回をさらに上回る、過去最大規模での開催となりました。
出題は、前回の優勝チームによって行われるのが通例です。出題に先がけて、第5回(https://recruit-tech.co.jp/blog/2019/10/15/r-isucon-2019-summer/)で優勝した「isucon_friends」のメンバーであり、今回の運営にあたっている古川から、レギュレーションの説明がありました。この中にもチューニングのヒントが隠されているかもしれません。全員が真剣に説明に聞き入ります。
午後3時過ぎ、一斉に問題サーバのIPアドレスが通知され、競技がスタートしました。以降の作業場所は自由です。研修室で早速作戦会議を始めるチームもあれば、チームごとに割り当てられたホテルの部屋にこもるチームもあります。
各チームが実施したベンチマークのスコアは、全チームがポータルサーバ上で確認できます。最終的な順位を決めるスコアは、競技終了時点で「そのチームが記録した最新のもの」のみが対象となるため、どのタイミングでベンチマークを行うかの判断も重要です。他チームの状況をうかがいつつ、それを上回るスコアを出していく駆け引きが展開されます。
●「リクルートが直面する課題」を反映した出題-今年のテーマは?
本イベントならではのポイントとして、出題される問題は「リクルートグループが技術的に直面する課題」を何らかの形で反映したものになっている点が挙げられます。競技としてチューニングを行いながら、実際の業務で直面する可能性のある問題に、どう立ち向かえばいいのかを考え、ノウハウを共有していくことにプライオリティを置いているそうです。
参加者が問題サーバの全容を把握しようと一斉に作業に入ったタイミングで、運営チームの古川に今回の設問意図を聞きました。
今回の問題サーバは「R-mail」と名付けられたWebメーラです。参考実装としては、Java、Go、Node.jsによるものが用意されています。古川によると、近年、リクルートグループで開発するサービスの中にも、メールを扱うものが多くなっていることが、テーマ選定の大きな理由だったそうです。
「メールの送受信が関わるサービスをきちんと作ろうとすると結構大変。Webメールの仕組みには、データベースに保存されたデータのうち、よく使われるものとそうでないものをいかに分けて扱うかという『ホットデータ・コールドデータ』問題や、関連する一連のメールをスレッドとして扱う際のノウハウなど、パフォーマンスチューニングに直結するトピックが複数あります。今回は、MySQLに100万件という大量のメールがある状態で、これらについての良いやり方を考えてほしいと思いました」(古川)
また、今回は競技開始に先がけて、運営側より参加者に「Stackdriver Trace」用のGCPアカウントが提供されました。Stackdriver Traceは、Google Cloud Platform上で提供されているパフォーマンス分析ツールで、リクルートグループの社内でも利用者が増えているといいます。今回の出題意図のひとつには、このStackdriver Traceによるパフォーマンス分析のやり方を覚えて、業務の中でも活用できるようになってほしいという思いがあったそうです。
●「ベンチマークを通す」ことが最初のハードルに
問題サーバが公開されてから数時間。研修室で黙々と作業を続けていた参加者の顔に、訝るような表情が浮かび始めます。ポータルには、ベンチマークを実施したチームと、その結果が随時表示されるのですが、夕食前の段階で、並ぶ結果はベンチマークに失敗したことを示す「failed」ばかり。なかなか実際のスコアが出てきません。
採点ルールとして、計測ツールが実行される2分間で「メールの送信に成功した回数-10×レスポンス異常数」がスコアとなることは事前に説明されていたのですが、問題サーバの環境をそのまま動かしても、この条件に満たないのです。しかし、出題チームの與那城によれば、この状況は「織り込み済み」だったといいます。
「とりあえず、データにインデックスを付けるだけでも800点くらいまでは出るようになっています。とはいえ、そこにたどり着くまでにひと工夫が必要なのですが…。本番はそれからですね」(與那城)
ポータルに最初のスコアが表示されたのは、競技開始から約2時間半後の午後5時33分のことでした。記念すべき初スコアは「ふんばり温泉チーム」の「589点」。実はこのチーム、2019年10月に行われた本家「ISUCON9」にも出場し、本戦で6位入賞を果たした実績の持ち主です。今回優勝候補のひとつと目されているのですが、最終的な結果はどうなるでしょう。競技はまだ始まったばかりです。
●一気に戦況が動き出した夕食後-参加チームの秘策は?
ほとんどのチームがスコアを出していない状況が続く中、夕食の時間に入ります。合宿形式で行われる本イベントでは、複数のチームが食堂に集う夕食が、参加者にとってのブレイクタイム。食事を終えて一段落しているタイミングで、いくつかのチームに話を聞きました。
松本駿、瀧井寛史、松尾裕幸による「村八分」は、新卒入社のエンジニア3名によるチーム。2回目のイベント挑戦です。
「前回は、とりあえず動かしてみれば何らかのスコアが出て、そこからチューニングの方針を考えられたのですが、今回はまずどうやったらベンチマークに通るのかを考えないといけない。少しだけ戸惑いましたね」
そう話すのはリーダーの松本。「村八分」では、前回出場時の反省を生かして、競技スタート直後の各メンバーの役割を練ってきたそうです。作業環境の整備、システム構成の確認、データベース状況の調査を手分けして行い、全体の状況を把握してから効率良く作業を進めていくという戦略です。前回の経験を生かして、上位入賞を狙います。
「ふんばり温泉チーム」に続き、ポータル上にスコアを記録した2組目のチームが、明智那央、井上耕輔、浅野宏明による「帰ってきた明智と愉快な仲間たち」です。実はこのチーム、前回惜しくも2位に終わり、涙をのんでいました。今回は同じメンバーでのリベンジ戦です。リーダーの明智は「前回の講評でも強調されていたポイントなのですが『場当たりで作業するのではなく、まずは計測から』を今回は徹底しています。必ず勝ちにいきます」と力強く語りました。
●最高得点をひねり出せ-団子状態で続く攻防
夕食が終わると、多くのチームが続々とポータルにスコアを記録し始めました。ちなみに、勘所を理解したチームの中には、引き続きチューニングを続けるところも多かったようです。
その後、2000点台のスコアを出すチームが現れ、他のチームもそれに追従し始めました。しかし、なかなか頭一つ抜け出すチームが出てきません。ここからは、最適化だけでなく、システムを安定させた上でベンチマークを繰り返し、いかに他チームより多くスコアをひねりだすかの勝負になりそうです。上位数チームが団子状態のまま、翌日の終盤を迎えます。
午前10時には、チェックアウトを済ませた参加者が、次々と研修室へ戻ってきました。とはいえ、競技はまだ続行中です。競技終了となる正午までの約2時間、それぞれのチームが最善を尽くします。競技終了の1時間前からは、他チームのスコアが見られなくなります。ここからはいわば「自分たちとの戦い」です。
「え!? なんでこのスコアなの?」
「手詰まり感すごい…」
「やろうと思えばできるけど、エラーを出さない自信がない…」
「あと2分!」
「通った! もう触らない!」
といった声が研修室のあちこちから上がる中、正午、運営からSlackに合図が流れ、競技は終了しました。
●番狂わせも起こりつつ優勝チームが決定-第6回の勝者は?
その後、運営による審査が行われ、昼食を挟んで14時より、結果発表と入賞チームによる振り返りが行われました。今回の問題に運営チームが込めた意図を知り、入賞チームがどのような方法で高いスコアを出すことができたのかが共有される「学び」の多い時間です。いわば、本イベントのハイライトともいえます。先ほどまで緊張が張り詰めていた研修室には、飲み物や軽食が用意され、一気にリラックスしたムードで結果発表が行われました。
運営による審査に基づき、最終結果が確定。入賞チームとスコアは以下のようになりました。
順位 | チーム名 | 最終スコア |
優勝 | 帰ってきた明智と愉快な仲間たち | 2780点 |
第2位 | 壊れたFirewall直し隊 | 2766点 |
第3位 | FirstClassEngineer | 2564点 |
第4位 | 帰ってきたあのギャル | 2530点 |
第5位 | 生きる-アメーバから人まで | 2141点 |
第6位 | ヤムチャ | 1691点 |
第7位 | コアラの街 | 1376点 |
第8位 | メトロチーズ | 1065点 |
上位チーム間での順位争いは、最終的にかなり熾烈なものになりました。今回、運営チームでは、問題サーバと完全に同条件でのテストは事前に行わず、参加者チームと並行して検証作業を行っていたのですが、その中で判明した理論上の限界スコアは「約3100点」。上位入賞のチームは、いずれもそれに近いところまでチューニングできていたことになります。
優勝は、前夜の段階で「勝ちにいきます!」と力強く宣言していた「帰ってきた明智と愉快な仲間たち」チーム。見事、前回の雪辱を果たしました。
中には、最後に実施したベンチマークが通らずスコアが0点になったチーム、再起動テストに失敗したことで惜しくも入賞を逃したチームもありました。特に残念だったのが、優勝候補だった「ふんばり温泉チーム」。実は、運営による再起動後のテストでは「2801点」という、優勝チームを超えるスコアを出していたのですが、競技時間内で最後に行ったベンチマークに失敗してしまい、ルール上入賞は果たせませんでした。
●必要な対応を優先順位に沿って実施できたかどうかがスコアに反映
入賞した各チームのコメントからは、運営の見込みどおり「100万件」という大量のメールデータをどう効率的に扱うか、その方法にどれだけ早いタイミングで気付けたかが結果に反映されたことが伺えました。「データにインデックスをつける」という部分には多くのチームが早い段階で気づけていたようですが、実は特定条件のクエリに対してインデックスが利かないというトラップがありました。
そのほかにも、インデックスの initialize にかかる負荷が非常に高いという問題が多くのチームを悩ませていました。これについて、運営では「100万件のメールの101万件以上を削除し、auto_incrementのidを100万に戻して、userテーブルだけ再作成する」というテクニックの利用を想定していたといいます。実際、上位入賞したチームのいくつかは、この方法でスコアを上げていました。
運営から参加者には、リソースが異なる複数のサーバインスタンスが提供されていたのですが、どうしても負荷が高くなる処理を、それらのサーバに対してどのように割り当てるか、あるいは分散処理できるようにするかといった判断も重要でした。また、実装言語の違いでそれぞれに直面する問題(Go実装はコネクションプールがないのでプールを独自に実装する必要がある、Node.js実装はデフォルトでは2min以上のリクエストがタイムアウトする、Java実装は環境変数が間違っているので修正する必要がある、など)を見つけ出して対応できるかどうかが問われていたといいます。
今回のR-ISUCONは、問題サーバに仕組まれたこれらのトラップまたはバグを、優先順位の高いものから順に解除しつつチューニングしていくことによって、段階的にスコアを高められるような出題となっていました。入賞チームのコメントや運営チームによる想定解の解説を聞いた参加者は、みな納得や感心の表情を浮かべていました。
●エンジニアの「学びの場」としてのR-ISUCONの進化に注目
イベントは盛況のうちに幕を閉じました。今回、リクルートテクノロジーズの執行役員である宮川も、参加チームの一員として競技に挑んでいました。回を重ねるごとに参加者が増えているR-ISUCONについて、宮川は次のように話しました。
「さすがにこれだけ規模が大きくなってくると、イベントの形も、参加人数が少なかった時からは徐々に変えていく必要があるかもしれません。具体的なイメージはまだないのですが、グループのエンジニアが楽しみながら、技術に対する気付きや、深い学びを得られる場は、今後も継続して設けていきたいと考えています」(宮川)
●社内ISUCONから本家ISUCONへ
そしてこの度、運営チームの古川が率いるリクルート代表チームが、今年9~10月に開催される「ISUCON10」の問題作成を行うことになりました。
縁があって、LINE社主催の本家のISUCONにも出題側で参加できることになりました。ISUCONで得られた知見を社内ISUCONという形で会社に還元できたように、今度はリクルートで得られた知見を本家ISUCONにも還元していきたいと思います。(古川)
こうした流れを経て、次回以降このイベントがどのような姿に進化していくのかにも要注目です。