「もっとも多くの物を持ち帰った人こそがISUCONの勝者である」

mazrean氏：「発想の源としてのISUCON」というタイトルで発表します。

まず軽く自己紹介です。@mazereanです。東工大の修士1年で、別セッションでoribeさんが話していたtraPに所属をしています。ISUCONではISUCON11に本選に出場していました。

田籠さん（田籠聡氏）というISUCONの創始者の方がいるんですが、この方の言葉で「もっとも多くの物を持ち帰った人こそがISUCONの勝者である」という言葉が存在します。今回はこれに対して「より多くの物を持ち帰るにはどういう意識を持っていけばいいのか」ということで、自分の考えを話していこうかなと思っています。

ISUCONはエンジニアリングの要点と競技性のための制約が合わさっている

まず自分の考えるISUCONの特徴ですが、ISUCONという競技では、エンジニアリングの要点が凝縮されている特徴があるのかなと思っています。

具体的にいうと、ISUCONで使う・必要とされるような技術的な知識とか、あとは行うべき改善の優先順位付けなどの考え方などは、実際の開発などの業務でも役立つものだと思っています。

一方で、ISUCONでは競技性のために生まれている制約も多く存在しています。具体的には時間的な制約であったりサーバーのリソースの制約などはかなり厳しいものになっていると思います。これらによって、技術的なおもしろさと競技的なおもしろさが両立しているのが、ISUCONのおもしろさなのかなと思っています。

これらの特徴が得られる知識に、発想にどういうふうに影響してくるかというと、エンジニアリングの要点が凝縮されていることによって、一般的な開発やよくある状況が生まれやすくなっています。これによって、一般的な開発でも役に立つような汎用的な知識であったり発想が得やすくなっているのかなと思います。

一方で、競技性のために生まれた制約が存在していることで、ふだんの開発では珍しいような環境が生まれやすくなっています。これによって、ふだん思いつかないような新規性の高い発想が生まれやすくなっているのかなと思っています。

つまり、これらによってISUCONでは汎用的でかつ新規性の高い、つまり良い発想が生まれやすいのかなという考えを自分は持っています。

対ISUCONのツールを作成する中で得られた良い発想の事例

ここからは、自分が新しい、良い発想・良い経験を得られた事例について話していこうかなと思います。今回は「isutools」という、ISUCONでの初動時間を削減するために、アプリケーションのコード書き換えを自動で行うようなツールを自分が作成したんですが、この際の経験をもとに話していこうかなと思います。

最初に、このツールがどのような挙動をするツールかを、デモを見せようかなと思います。

（デモ開始）

（画面を示して）今回はISUCON10を題材にしていて、完全に初期状態からスタートしているので、メトリックなどは書き込まれていません。この状態でisutoolsを実行すると、複数のコード書き換えが実行されます。これによって、アプリケーションのソースコードがメトリクスを仕込まれた状態になっていています。

実際にデプロイを走らせると、ソースコードにisutoolsで行った変更が反映されて、こんな感じでコマンド1本でpprofなどのメトリクスがすべて引き込まれます。

これで実際にベンチマークを走らせると、こんな感じでpprofのままメトリクスが取れたり……。

こんな感じにリクエスト数などのメトリクスであったり、どんなSQLが実行されているかなどのメトリクスが取れる状態になります。

こんな感じでコマンド1本でメトリクスが取れる状態に持っていけるツールがisutoolsというツールです。

このツールを実装するにあたって大きく役に立ったもので、Goの静的解析パッケージのSuggestedFixという機能が存在します。これがどういうものかというと、VSCodeとかでエディタの警告に対してクイックフィックスというものが出てくることがあると思うんですが、これに当たるような機能を提供してくれるのがSuggestedFixです。行うべき変更が警告を出した際に、その警告に対してどういうような変更をすればいいかを提案した上で、実際に適用までやってくれるのがSuggestedFixです。

今回このisutoolsというツールではコード書き換えを行っているわけなんですが、この際に行う構文処理のうち、構文解析と変更適用の操作を全部SuggestedFix機能に任せることができて、その結果、大幅にコード書き換えの実装を楽にすることができました。

こんな感じで、今回は対ISUCONのツールを作っていく中で、コード書き換えを楽にする手法を知ることができました。

（デモ終了）

これが実際に一般開発の中でどういうふうに役に立つかというと、ライブラリの移行とかも、メトリクス監視系のツール、New Relicとかを導入していく際にはけっこう同じような変更を複数の箇所にしていくような状況が生まれています。こういうような状況でコード書き換えツールをいったん実装して、一発で適用するとけっこう楽に実装ができたりするという話があります。

ISUCON特有の状況を意識的に触ることで、新しい知識を得られる

こんな感じで、今回はコード書き換えでよくある状況とISUCON特有の時間的な制約という状況が重なった結果、SuggestedFixという新しい知識を得ることができました。こんな感じで、ふだんの開発でもある状況と、ISUCON特有の状況が重なった状況に触れることで、新しくて、しかも使えるような良い知識を得ることができます。

こんな感じで新しい知識を得ることはできるんですが、こういう状況をどういうふうに作れるのか、自分の考えを話します。

「よくある状況」というのは、ふだんから触れているので目に留まりやすいんですが、ISUCON特有の状況というのは、意識しないとそもそも目に留まらなくて、触れることはできないんですね。

これを踏まえて、ISUCON特有の状況、具体的には時間的な制約やリソースなどの状況を独特の制約に意識的に触っていくことで新しい知識を得られて、よりISUCONに楽しむことができるんじゃないのかなと思っています。これで発表を終わります。

Published at