@hasi_t です。 http://klabgames.tech.blog.jp.klab.com/archives/1072352628.html の続きです。

hasi_tがやったことの時系列

  • 10:00-11:30 問題を把握する
  • 11:30-12:30 nginxをインストールする
  • 12:30-13:00 昼食
  • 13:00-14:40 getEventsとgetEventを修正する : getEventsからgetEventを呼ばないようにし、SELECT * FROM sheetsを1回にし、SELECT * FROM reservationsのN+1問題を対処
  • 14:40-15:30 /admin/api/reports/sales, /admin/api/reports/events/:id/sales修正 : order by reserved_at asc を削り、数値比較でソートするように修正、getEvent呼出を削除
  • 15:30-16:00 Failしているのをなんとかしようとする
  • 16:00-16:20 SQLのロックを外して、goでロックを取るように修正
  • 16:20-17:00 /api/users/:id修正 : getEventの結果の使いまわしを実装、getEventNoDetail・getEventNoSheetsを作成
  • 17:00-17:10 reservations.user_idにINDEXを張る
  • 17:10-17:40 オンメモリキャッシュのつなぎ込み
  • 17:40-18:00 おしゃべり

目立った点

nginx化

sudo yum install nginx で適当にインストールして実行ユーザを変えたのですが、
nginxのテンポラリディレクトリの権限を付けておらず、
/admin/api/reports/events/:id/sales/admin/api/reports/sales のようにレスポンスデータが大きい場合のみエラーが発生する、
という問題を起こしてしまいました。

nginxのエラーログを見たら Permission denied が出まくってるのですぐ気づきそうなものだったのですが、
全く見ておらず、それに気づかず16時までfailし続けていました。
動作が遅いからfailしているのでは?とか言っていろいろ修正していたのですが、
ブラウザでダウンロードしようとするとネットワークエラーになり、
ログを見たらエラーが出ているという状況でした。
ベンチマーカのログを見てちゃんと確認したらすぐ分かったことで、深く反省していますorz

野蛮なロック

予約/キャンセルAPI全体のロック を取りました。
これによってSQLのFOR UPDATEは不要になります。
常日頃から並列処理やロックは扱えないと公言して憚らないので、自分としては普段どおりです。(自慢できることではない)
結果的にはダブルブッキングやデッドロックといった様々な問題が未然に防げたようなので良かったです。

感想

反省点は多いですが、結果的には良かったので良かったです。
準備してもらったレポートツールはとても優秀で楽しくチューニングできました。

昨年作問を担当したので運営側の大変さはとてもわかるのですが、 特にベンチマーカがどんな実装だったのかと気になっています。
これを作るのはめちゃくちゃ大変だったのでは…

本選を楽しみにしています!