ISUCONの第一人者・藤原俊一郎さんが語る攻略と学び ― 大切なのは「不満のしきい値」を下げること

• 改善し、計測する ― ISUCONとは開発サイクルを回すこと
• 「コンテストのためのコンテスト」ではない、現実に即した出題
• 新しい技術のアンテナは「不満のしきい値」を下げることから

与えられたWebサービスの高速化を競うITエンジニアの総合格闘技、ISUCON。決められたレギュレーションの中で、いかに自分の知識とスキルを生かしてアプリケーションをいい感じに高速化するか¹という課題に魅力を感じるエンジニアも多く、回を重ねるごとに参加者も増えて、2018年10月に開催された「ISUCON8」では528組、1,392名がオンライン予選に参加しました。

ISUCON8 まとめ : ISUCON公式Blog

2011年の初開催から何度となくISUCONに参加してなんと3回の優勝を果たし、時に出題者に回って参加者を楽しませる側に立ってきたのが、面白法人カヤックで主にバックエンド側のエンジニアとして活躍している組長こと藤原俊一郎さん（@fujiwara）です。ISUCON8の問題作成にも携わった同氏に、その攻略方法とコンテストの魅力、そしてISUCONからエンジニアが持ち帰れるものは何かを聞きました。

改善し、計測する ― ISUCONとは開発サイクルを回すこと

── 藤原さんがISUCONに参加するきっかけは何でしたか？

藤原　ISUCONの前に「チューニンガソン」というイベントがありました。データベースの割り当てメモリを増やしたり、同時接続数を増やしたりとインフラ側でいろいろチューニングできるコンテストです。ただし、アプリケーションのコードに手を入れることは許されないレギュレーションで、「それだけじゃ面白くないよね」と@tagomorisさんが言い出して始まったのが、ISUCONです。

　はっきりとは覚えていないんですが、その案内をたぶんTwitterで見たんでしょうね。先着20チームが参加できるというので、すぐ当時の同僚と組んでエントリーしました。

── 第1回でいきなり優勝できた勝因は何だったと思いますか？

藤原　参加したのはカヤックに転職して約半年後だったんですが、その当時手がけていた「koebu」というサービスが長く負荷に苦しんでおり、入社以来、いろいろ安定させたり、サーバを移転させたりして戦っていた経験がありました。そこでやってきたことがうまくはまったんだと思います。

── ISUCONでは3人までのチームを組むため、個人の経験だけでなくチームとしてどう臨むかも大切になりますよね。

藤原　ISUCONで参加者がやれることはいっぱいあるのですが、競技時間は8時間（朝10時から夕方18時まで）しかないため、複数のメンバーが同じ作業をしても意味がありません。かといって、互いのやっていることを全く知らなくてもダメなんです。方針を決めて共有しておくことが大切ですね。一人で好き勝手にコードを書いてても動きませんから。

　「ここはこう直しましょう」と方針を決めて、役割分担をして作業し、できたら結合して、ベンチマークをかけるという一連のサイクルを効率的に回せると、点数につながります。私はこれまで、基本的に会社の人か元同僚と一緒に出ているので、互いの得意なこと・できることを知っていたことも大きかったと思います。

── そのサイクルは、インフラエンジニアとしての普段の業務に近いのでしょうか？

藤原　いえ、インフラの設定だけいじっていてもスコアは全然変わらないので、どちらかというとアプリケーション開発フローに近く、それを回すことが大切になってきます。

　立てた方針に意味があったかはどうかは、ベンチマークのスコアを見れば分かります。また、スコアは変わらなくてもサーバの負荷が下がることもあり、これもサーバのリソースが空くという意味で有効な手ですから、ベンチマークはもちろん、他のメトリクスを計測して、意味があったかどうかを判断しています。

── 8時間という時間の使い方も重要になると思いますが、どう配分しているのですか？

藤原　最初の1時間は、サーバ上で快適に作業できる環境作りに費やすようにしています。問題サーバにはデプロイ用のツールも何も用意されておらず、ただファイルが置いてあるだけです。それをGitで管理して、プルリクエストをマージしたらすぐデプロイされる環境を作ったり、開発に必要なツールをインストールします。

　競技中には、負荷を見るツールとしてdstatやnetdataを、ログを解析するツールとしてはalpやpt-query-digestを使っています。他には、kataribeを使っている方も多いようです。

　私がそうしたタスクを担当して、環境が構築できるまでの間、他の2人にはコードを下読みして、明らかにおかしいところを探してもらいます。ISUCONの問題のコードは何千行もないので、ざっと見れば何をやっているかが分かります。

　あとは、計測ですね。先ほども言いましたが、いろんなメトリクスを見るコマンドやツールを使ったり、どの処理にどのくらい時間がかかるかをログに記録したりします。すると、「このAPIは平均1秒かかるけれど、こっちは0.5秒で済む」といったことが見えてきます。

　ここで大事なのは、重いところを直すことです。軽いところをいくら直しても、重いところに引っ張られて全然性能が出ないので。そうやって直すと、相対的に別のところが重くなる。これを順番に繰り返して直していくと、理想的にはどんどん早くなるはずです。

── 時間の使い方で他に大切なことがあれば教えてください。

藤原　大きな決断をいつまでに下すかもポイントですね。ISUCONでは、いくら途中で高いスコアを出しても、最終的に動かないと0点になるので、あまりギリギリになって大きな改造をすると動かなくなるリスクがあります。

　私の場合、データベースの載せ替えといったレベルの大改造をするなら、15時（8時間のうち5時間が経過）を1つのデッドラインにして、それまでに決断が下せないなら今までの延長戦上でいく、そういうざっくりしたタイムラインを設けています。

　もう1つ、最後の30分から1時間は動作確認に費やしています。よくあるのが、インストールしたアプリが動かない、起動しないケースです。再起動しないと有無を言わせず失格なので、ちゃんと再起動して動作するかの確認に当てています。

　準備をして方針を決め、大改造のデッドラインを決めて作業し、最後に仕上げをする……うまくいった回はそれが全部はまりましたね。逆にダメなときはそこがぐだぐだで、大改造の決断ができないうちにズルズルいって、最後の動作確認も遅れに引きずられて……という感じでした。

── どんなところがうまくいかなかったんでしょうか？

藤原　例えば、第4回では、Cache-Controlヘッダーをいじれば一気に負荷が下がるのに、そこに気付けませんでした。

　また、第7回は大敗北したんですが、敗因は分かっていて、WebSocketでやり取りされるメッセージの計測がちゃんとできていなかったんですよ。それで効率的な手が打てませんでした。

藤原俊一郎さん、面白法人カヤック 技術部

「コンテストのためのコンテスト」ではない、現実に即した出題