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

── 参加するだけでなく、出題するようになったのはどんな経緯からでしょう。

藤原　第1回・第2回と連覇した後に、懇親会で主催者から「次はやってくれるよね？」と言われまして……。それで出題することになったのですが、とにかく「出題のための出題」「コンテストのためのコンテスト」にはしたくないと思っていました。

　私の場合に限らず、第1回はブログ、第2回はチケット販売サイト、他にも画像投稿やゲームといった具合に、実際のサービスを踏まえて、仕事の中でハマったこと、困ったことや解決した問題をエッセンスに作られています。現実で役に立たない問題を解いて、それで高いスコアを出しても意味がないですから。

── 現実に即したというのは、例えばどんな問題を？

藤原　第3回の出題では、画像投稿サイトを題材に、投稿があるとリアルタイムに通知を行う機能を用意しました。投稿からなるべくリアルタイムに近いタイミングで通知を送るとスコアが上がるんですが、あまりにリアルタイムにし過ぎるとクライアントが同時にどっと押し寄せてくるので、簡単にサーバが死ねるんですね。クライアントの集中に耐えられる状態を作っていればスコアが上がるけれど、その準備がないうちに通知だけ早くしても自分の首を絞めてしまうので、そのバランスが大事という問題です。

── これまで出題側が用意したチューニングポイントを全て押さえたチームはあったんでしょうか？

藤原　そこまでいかないことの方が多いですね。ただ、競技として盛り上がるよう、ある一定のスコアに一番に達したチームには「特別賞」を出すようにしています。第8回で出題したときはそのラインをかなり意識して、まぐれでは絶対にいかないけれど、いくつか基本的な要素を押さえたら絶対に達成するスコアを時間をかけて設定しました。狙い通り、ちょうど14時くらいに特別賞が出て盛り上がりましたね。

── 出題側の想定を超えたチューニングを行うチームもあるんでしょうか？

藤原　第8回の優勝チーム「最大の敵は時差」がまさにそれですね。私たちが想定していたのとは違う場所をチューニングし、すごくスコアを伸ばしました。しかも、正当なチューニングで。いろんな人に参加してもらうと「なるほど、そっちから攻めたか」と思わされることもありますね。

── このチームもそうでしたが、回を重ねるたびに学生の参加が増えてますね。

藤原　はい。しかも彼らは決してまぐれではなく、根拠を持ってチューニングを行い、スコアを伸ばしていった、とても実力のあるチームでした。全体としてみると平均点数は学生より社会人の方が上ですが、上位チームはほとんど変わりがありませんね。

　ISUCONでは過去問が公開されていますが、社会人でわざわざ解く人は少ないのに学生さんはちゃんと練習するし、コンピュータサイエンスをしっかり学んでいてとても優秀です。

── ということは、過去問を繰り返し練習すればコンテストには勝てると？

藤原　いえ、出題のための出題にはしないようにしていますから、そこはあまり関係ないと思います。ただ練習することで、チームとして方針を立てたらすぐに手を動かしてデプロイし、ベンチマークを回していく手の早さが身に付きますから、ゲームに慣れるという意味では有効だと思います。

　また最近、新しい言語を習得するのに、ISUCONの問題をその言語で実装し直している人がいるという話も聞きました。確かにサイズが数百行と手頃な上、データベースにアクセスしたり、セッション管理したりと実践的な機能が含まれています。それにベンチマークがあるので、動いていないこと、ちゃんとできていないことが分かるのもあって、学習にも便利でしょうね。

── ISUCONに参加することで得られるものって、何でしょうか？

藤原　今まで知らなかったアプリ、毛色が違うアプリに触れられるのも面白いし、何がうまくいかなかったのかが分かるのもいいことだと思います。一口に「分からなかった」といっても単に知識がないのか、知識としては知っていたけれど見つけられなかったパターンなのか……。

　参加者の方が書いた感想ブログを見ると、みんなが何の目的で、どうやってその手を打ったか、どのメトリクスを見ればどんなことが分かるのか、といった具合に他の人がやったこと・自分の知らなかったことが分かります。しかもスコアが出ていますから、自分がどのくらい足りないかも具体的に分かりますね。

はてなブックマークで、タイトルに「ISUCON 本戦」を含む記事を検索

　それから、現実のサービスでは、パフォーマンスチューニングって実はあまりやらないんですよ。安定しているサービスならばそもそも問題が起きませんし、障害が起きるくらいやばいパフォーマンスの劣化が起きている場合は、のんびりやっていられないので、できる人がさっさと直してしまうでしょう。プロジェクトに加わっていても指をくわえて見ているだけになりがちです。

　その点、ISUCONならたっぷりできますよね。いつ終わるかが見えない本当の障害対応とは違って、競技の8時間が終わればビールを飲んで反省すればいいだけですし。

── ご自身が、ISUCONで得た経験を実サービスに反映したケースはありますか？

藤原　はい。第2回には、キャッシュ作成にとても時間のかかるサービスが出題されました。リクエストされたタイミングでそのつどキャッシュを作ると、多くのクライアントが同時にキャッシュを作りにいってしまい、なかなかできません。

　そこで、キャッシュの生成とリクエストを分離して、裏側で常に1秒ごとにキャッシュを生成し続けるものを動かして、表から読み出すだけにするとリクエストを効果的にさばける……という解法があったんですが、これを実際に業務で応用したことがあります。

　困っていることを題材に出題しているんですから、業務にも応用できる要素はあるはずなんです。

新しい技術のアンテナは「不満のしきい値」を下げることから

── 藤原さんはご自身はずっとインフラエンジニア一筋なんでしょうか？

藤原　私がこの仕事に携わるようになった1998年当時は、アプリを作る人がサーバもやってました。当時は小さい会社にいたので、サーバもセットアップすればプログラムも書くし、何だったらHTMLやJavaScriptも書くという具合で、1人で何でもできた、というかやらざるを得なかったんですね。

　経験を積んでいくうちに、自分はどうもバックエンド寄りが好きだなと。やっぱり、コードにしてもサーバの設計にしても、自分の作った仕組みがうまく動いているのを見るのが好きなんでしょうね。カヤックに転職すると、フロントエンドが得意な人が多かったこともあり、自分は自然とバックエンド寄りになりました。

── 1998年からこの20年で、Webの作り方もずいぶん変わりましたよね。

藤原　いや、やっていることはあまり変わらないと思います。昔のCGIも今のサービスも、HTTPでやってきたリクエストを受けて何か返したり、送られてきた情報をデータベースに保存したり……それだけなんですよ。APIが中心になってきたとはいえ、Webアプリというものの本質はそんなに変わっていないと思います。

　ただ、変わったこととしては、クラウドが出てきて、サーバをソフトウェアとして扱えるようになってきたことでしょう。配線やラッキングといった作業が隠蔽され、今まで体を動かしてやっていたことがソフトウェアでできるようになり、コードでできる範囲が広がったことではないでしょうか。

── その変化はWebのエンジニアにどういう影響があるのでしょう？

藤原　クラウドの普及で、自分でいろんなソフトウェアをインストールしてサーバを立てる機会が減ってきているようには思います。データベースもマネージドで提供してくれるし、コンテンツ配信もやってくれるので、アプリを動かすだけでよく、自分でミドルウェアをあまり用意しなくなっています。そうなるとどうしてもブラックボックスになっちゃいますね。

　サーバもデータベースも用意しなくてよく、アプリだけ書けば動かせる時代というのは、それはそれで便利ですが、そうなると目の前の仕事だけ、アプリを書くならアプリのことしか分からなくなる可能性がある。個人的には、自分のやっていることの隣のレイヤくらいは、ある程度知っておかないといけないんじゃないかなと思います。

　自分のやっているものは、複数のいろんなものに依存しています。その裏にあるアーキテクチャをちゃんと理解し、適切に組み合わせて使うスキルが必要になってくるのではないでしょうか。「無限にスケールします」というサービスがあったとしても、原理を無視して変な使い方をするとパフォーマンスが出ないこともあるでしょう。裏側の原理を知った上で、便利なものを適切に使う能力が必要です。

　ISUCONはそういう普段触らないものに触れるいい機会だし、触っておけば「ここはこうなってるからここが重くなるのね」と分かるんじゃないでしょうか。

── ISUCONに求められるスキルも変わってくるのでしょうか？

藤原　今の形態であと何年続くかは分からないですね。もしかすると10年後には、「Linuxにsshで入るなんてあり得ない」なんて世界になって、今の競技形態自体が化石化してしまうかもしれません。今でもその気配はあって、もうちょっとクラウド的な要素はISUCONにも必要になってくるんじゃないかな、という気はしています。

── それでは最後の質問ですが、新しい技術が次々と登場する中で、これからどんな技術に注目すべきだと思いますか？

藤原　確かに新しいものが話題になるスピードは速くなっているようですが、たいてい前からあるものではないでしょうか。この2～3年でよく聞くようになった技術でも、アカデミーの世界やGoogleのように巨大なサービスが実は10年前に発表していることがあります。それに振り回されて、流行（はや）りだからといって必要ないものを入れても仕方ないでしょう。

　この先5年後は分からないとしても、2～3年後の自分やビジネス、サービスに何が必要かを考えることが重要ではないでしょうか。現状だけ見ていては現状最適だけで終わってしまいますが、かといって流行っているものを何でもかんでも取り入れていくと身動きがとれなくなります。少し先を見ていくことですね。

　私は年に何回かサービスをリリースするペースで開発をしてるんですが、そのときにはコピペで全く同じものを作るのではなく、必ず何か新しい要素、概念や機能を、小さくてもちょっとずつ入れるようにしています。そうして、いいものがあれば次はもっと拡大していけばいいし、いけてないなら外せばいい。それをせずにコピペを繰り返すだけでは、3年後には完全に古い陳腐化したものだけが残ることになるでしょう。

── その「新しい要素」に気付くアンテナはどうすれば磨けますか？

藤原　何か不満だったり、不便だったりすることがないかを常に考えて、よりよくなりそうなものを取り入れていくことでしょうか。「不満のしきい値」を下げておくといいかもしれません。

　夜中に1度でもアラートで起こされたら、もう絶対のそのアラートは受けたくないという気持ちで原因を究明したり、しきい値を見直したり……そういう気持ちを常に持っていると、不満を解消できる可能性を持った技術に対する感度が高くなるかもしれません。もちろん、実際に入れるときには慎重になる必要がありますが。

　とにかく、何事も今が最高なわけではありません。ラリー・ウォール氏が言ったプログラマーの三大美徳である「無精、短気、傲慢」じゃないですが、これはちょっとよくないな、ということをそのままにしないで、「もっといい方法が絶対にあるはずだ」という気持ちを常に持つことでしょう。

── ありがとうございました。

取材・執筆：高橋睦美