そろそろ傷が癒えてきた。。
ISUCON5の本選にメルカリのインフラ改めSite Reliability Engineerで結成したチーム「GoBold」で参加して、最も速く決められた得点に到達したチームに与えられる特別賞と最終的に3位となりました。チームメンバーは @cubicdaiya、@shmorimo、@kazeburo の3人です
出題のtagomorisさん、kamipoさん、運営の941さん、LINEの皆様、テコラスの皆様ありがとうございました。
ソースコードとやったこと。
こちらにて公開しています
https://github.com/kazeburo/isucon5-final-public
構成は、Nignx + Perl + PostgreSQL + memcachedです。
課題となったサイトは、データベースに格納してある情報からいくつかのAPIに問い合わせて、その結果をまとめてクライアントに返すというもの。流行のマイクロサービスを間違った形で実装したものということでした。題材としてはかなり面白いものでした。
最初にアプリケーションの動作やコードを確認し、3人でどのような実装方法にするか、落書き帳に雑に書きながら相談しました。
方針としては
- 与えられた3台で動作するように変更
- cache時間の調整は必要になるだろうが、APIの問い合わせを全てmemcachedにcache
- cacheはDBを変更するタイミングで行う
- PostgreSQLへの問い合わせを出来る限り減らしていく
という感じです。
やった事と時系列を整理してみる
11:09:59 106211:23:09 1116 < rubyの初期スコア 11:53:25 84 FAIL: 11:58:22 2595 < perlの初期スコア 12:00:45 84 FAIL: 12:08:24 84 FAIL: 12:11:57 2817 12:17:50 2566 12:29:32 2700 12:35:46 10268 < ここで3台で動かす事に成功。usersとsubscriptionがmemcachedに 12:41:46 10274 12:52:32 0 FAIL: < このあたりはapiのcacheとuserのcacheを実装 12:52:46 0 FAIL: 12:58:55 10310 13:04:14 0 FAIL: < end_pointのcacheの実装 13:05:30 0 FAIL: 13:10:16 0 FAIL: 13:13:39 10291 13:16:32 65 FAIL: < ログイン周りもmemcachedに 13:37:11 10292 13:39:28 10732 13:42:13 0 FAIL: 13:46:49 90068 < apiのcacheが完成 13:49:06 0 FAIL: 13:55:56 40 FAIL: 14:01:01 98672 14:11:22 0 FAIL: 14:14:00 70209 14:16:22 100058 < nginxのログを切って特別賞get 14:19:52 87753 14:22:37 93487 14:31:43 102180 14:38:34 0 FAIL: 14:39:55 0 FAIL: 14:42:07 84 FAIL: 14:47:22 84 FAIL: 14:49:51 75 FAIL: 14:54:16 0 FAIL: 14:55:51 84 FAIL: 15:01:34 109671 15:10:21 97975 FAIL: 15:13:12 108082 < ここら辺でtenkiのcacheを1秒に 15:16:17 99331 15:17:29 80 FAIL: 15:23:16 100742 15:28:36 99526 15:32:58 103129 15:40:24 89299 FAIL: 15:45:53 0 FAIL: 15:49:46 38564 FAIL:1秒に。keepaliveもやめる 17:41:45 86611 17:47:03 65252 < tenkiのcacheを3秒に 17:49:59 74 FAIL: 17:51:41 84084 17:54:44 80924 17:58:35 65422
特別賞以降は何をしてもダメでした。自分たちの作ったbugだったり、ベンチマーカの挙動が変わったり、再現しないエラーが発生したり、初期チェックの段階でのAPIの問い合わせエラーが発生したりとかなり右往左往してしまいました。正直1回通ったベンチマーカの挙動は変えないで欲しいなと。。
ベンチマーカの競技中での動作変更や自分たちが感じたAPIサーバの不安定さは、事前解答など、出題側でのQuality確保の時間ががあれば、ある程度回避できたのではないでしょうか。ISUCONの準備には多くの時間がかかり、通常業務への影響も少なからずありますが、それでもデスマーチが前提ではISUCON自体を長く続けることはできません。過去の出題者として、問題作成のスケジュールの持ち方や出題チームでの役割分担、事前解答といった面で協力できるのではないかと思っています。