エンジニアHubPowered by エン転職

若手Webエンジニアのための情報メディア

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

Webサービスの高速化を競うISUCONで何度も優勝し問題作成も手がける藤原俊一郎さんに、その攻略方法と魅力、エンジニアが持ち帰れるものを聞きました。

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

ISUCON8 まとめ : ISUCON公式Blog

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

藤原 俊一郎(ふじわら・しゅんいちろう)fujiwara fujiwara

2011年より面白法人カヤック。技術部SREチームリーダー。主にソーシャルゲーム、自社サービスを担当。ISUCON優勝3回、出題2回。最近の趣味はマネージドサービスの隙間を埋める隙間家具のようなツールをGoで作ってOSSにすること。著書に『みんなのGo言語[現場で使える実践テクニック](共著、技術評論社)がある。

また、2011年の第1回大会で初優勝して以来、出題した回を除いて全てのISUCONで本戦に出場している(2回目までは予選なし)。戦歴の詳細についてはブログ「酒日記 はてな支店」を参照。

結果 対応する藤原さんのブログ記事
1 優勝 #isucon で優勝してきました
2 優勝 #isucon2 で優勝してきました
3 出題 ISUCON3 を開催しました
4 3位 ISUCON4本選で3位に敗れました
5 優勝 ISUCON5 で優勝しました
6 準優勝 ISUCON6で準優勝でした
7 本戦敗退 ISUCON 7 本選で負けてきました
8 出題 ISUCON8 本選出題記

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

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

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

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

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

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

koebuは、2007年に開設された音声コンテンツによるWebコミュニティ。2014年にサイバーエージェントに譲渡され、2016年9月をもって終了した。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

※プログラミング言語Perlの開発者であるラリー・ウォール(Larry Wall)氏は、プログラマーにはLaziness(無精または怠惰)、Impatience(短気)、Hubris(傲慢)という3つの大きな美徳(great virtues)が必要だと、講演や著書で説いている。

関連記事

取材・執筆:高橋睦美

*1:ISUCONの名称は、Iikanjini Speed Up CONtestの略とされている。