Date Sun 05 January 2014 Tags isucon

はじめに


あけましておめでとうございます。2013年に開催されたisucon 3の参加報告です。本blogのフレームワークをOctopressからPelicanに移行する等していたため開催から2ヶ月遅れの更新となりました。...年越してしまっていますね。

さて本題です。

2011 年度、2012 年度の isucon は本戦のみの一発勝負であるのに対し 2013 年度は Amazon EC2 を利用したリモート参加者によるオンライン予選と渋谷ヒカリエの LINE 本社で開催される本戦の二部構成となっています。

我々勝浦タンタンメンチームは予選は運良く 1 位通過できたものの本戦は Fail しスコア無しという惨敗結果に終わりました。チームの方針や反省点に関してはチームメンバーの@sechiro@qtakamitsuが詳細な blog*1 を書いてくれているので、来年の isucon に今回の反省を活かすためにも自分なりの視点で備忘録を書きたいと思います。

根本的に実力が不足していたことは間違いないですが、限られた力量の中で最善を尽くせたかというと、残念ながら良くない方向に振れてしまったかなと思います。「では技術面以外で不足していた点は何か?」という視点で敗因を書いていきたいと思います。

敗因1 : Technology Driven


第一の敗因は、本戦で使う技術・方向性をお題が出る前から固めたことだと考えています。本戦でどのような特性のアプリケーション・レギュレーションになるか分からないという不確定要素がある状況で、事前に技術の方向性を決定することは、勝負の結果を運任せにすることとほぼ同義になります。

C コーダーの多い勝浦タンタンメンの場合は、それなりに書き慣れている Apache Module(mod_isucon) を準備し、本戦ではお題目アプリを一気にポーティングしベストスコアを指すという事前方針でした。*2

予選のように単一マシンで縦方向の最適化が勝負の決め手になる場合はコンピュータの資源が限られている上に、複数マシン間における一貫性や同期等を考慮する必要がないためアプリケーションスタックはある程度限定される傾向にあります。そのような前提条件においては、お題目アプリケーションのネイティブアプリケーションへのポーティング & チューニングは、CPU bound である場合に LL 系言語と実行速度の差別化を図るという観点で有効に作用する可能性が相応にあります。

しかし本戦は 5 台のサーバを利用した分散システムです。従って、システム全体で最適なパフォーマンスを発揮するためのアーキテクチャ検討の重要性がより高くなり、垂直方向にアプリケーションのみを高速化するメリットが相対的に小さくなります。#3

結果論にはなりますが、もう少し丁寧に戦略を練っていれば事前に検討できたことだと思います。isucon 対策合宿や isucon hackathon 等を含め、今まで単一マシンのみで対策・検討してきたことが、想像力や思考を曇らせたことに寄与していると思います。

当日レギュレーションが発表された段階で、おおよそ mod_isucon で対応していては間に合わない上に性能向上のアプローチとして間違っていることが判明し、チームで方針を決定する上で冷静さに悪影響が出たかなと思います。

敗因 2 : 当日の戦略ミス


第二の敗因は、@sechiro が blog で「制限事項の理解と適切なアーキテクチャの選定ミス」という形でまとめてくれている部分ではあるのですが、自分の言葉でも書いておきたいと思います。isucon 本戦の競技時間は 7 時間しかありません。「時間」や「チームの能力」という限られた資源やレギュレーションから発生し得るボトルネック考察をもとに、実装できる最善の設計を可能な限り早く見極め、ひとつひとつ丁寧に実装していくことが大切です。しかし、当日はこの認識が不足していました。

レギュレーションの意識という観点では、勝浦タンタンメンでも、構成上 I/O bound になる設問であると当然早期に判断してはいました。しかし、フロントの帯域がサーバ一台あたり100 Mbps(12.5 MByte per sec) に制限されているという重要な前提を軽視したことにより、具体的な実装に落としこんでいく上で最も重要である「いかにフロントのネットワーク帯域を使い潰すか」という視点を失うことになりました。

また、時間や能力等を元に実現可能なアーキテクチャを検討するという観点では、時間的・能力的に制限時間に間に合わないリスクを伴う理想的な実装を追い求めた結果、最終計測に間に合わずに Fail するという結果になりました。チームメンバーは普段異なる会社で働き、肩を並べてコーディングした時間が少ないという点も影響したとは思います。しかし、それは最初から分かっていることなので、事前にもう少し踏み込んで、各個人ができること・できないことを共有し、戦略策定時に参考にする必要があったかなと反省しています。

isucon 予選のレギュレーションは Fail に対する罰則も軽く、ある程度は力技で通せる面もありましたが、本戦では Fail=即死 ですので一つでも問題があると命取りになります。チーム内の協調力や検討力、システムの安定性をより強く問う良問だったと思います。

最後に


isucon 3 を通じて技術的に大変多くのことを学ばせて頂きましたし、上記のような異種混合チームで極めて限られた時間の中で物事を進めていく際の難しさについても学ばせて頂きました。主催者チームの方、スポンサー企業様、関係者の皆様には深く感謝しています。

最後に、isucon への当事者としての参加は、チームの中で切磋琢磨できるだけではなく、他チームの技術的・戦略的な問題解決方法を自ずと深く勉強することになり、非常に得るものが多いです。次回以降どのような形式で開催頂けるのか分かりませんが、 isucon 3 に参加しなかったエンジニアの方々には次回への参加を強くオススメします。

*1 : 今更ながらの #isucon 3 参加報告:「isuconに勝てる銀の弾丸などなかった」 isucon 3 に参加しました

*2 : templateやDB接続部等を含めて事前に準備をしてくれた @qtakamitsu に感謝

*3 : 一方で優勝チームのように、どのようなお題が出たとしてもおおよそ必要になると思われる準備を事前に行うことは、時間制限のあるisuconにおいて極めて有効だと思います。


Comments

comments powered by Disqus