そろそろ傷が癒えてきた。。
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自体を長く続けることはできません。過去の出題者として、問題作成のスケジュールの持ち方や出題チームでの役割分担、事前解答といった面で協力できるのではないかと思っています。
