hidekiy blog

概要 10月3日にISUCON10 本選にチーム名 hidekiy、チームメンバー @hidekiy, @kotaroy で参加して、結果8位でした。賞金圏内は逃しましたが、過去の本選出場時のやられっぷりに比べて、若干の進歩は感じました。 何をやったかメモ 10:00 レギュレーション、アプリ仕様確認 盛り沢山過ぎて過去の ISUCON 本選でほぼ何もできなかった悪夢が蘇って焦る。 11:00 アプリのコード確認、やはりボリューム感が凄くて気分が悪くなる。 予選と同じく Cloud Profiler, Cloud Trace 設定する。サーバー1号機がメモリ不足でアプリのビルドが遅すぎるので、仕方なくスペックが少し良さそうな2号機に移行したら行けた。 12:00 ホームディレクトリに作った Makefile から、make -C webapp/golang としていたら明後日の場所 ~/bin にバイナリが出来ていてデプロイ出来ていない事に気づく。(cd webapp/golang && make) として対処完了 13:00 ListNotifications の負荷が高いため、Web Push に移行する対応を行う。サンプルコードのおかげて特に難しい事は無く出来た。 14:00 Audience Dashboard はユーザーごとに変化させなくて良く、一律でキャッシュ可能なので、 singleflight  で一定時間内（1秒間）に来たユーザーには同じレスポンスを返しておく対応をする。シリアライズ後のバイナリを作るところまでを共通処理とした。 15:00 Leaderboard を対処するため、クエリ側からユーザー固有パラメーターを抜いて、ジョブ履歴とチーム一覧を全ユーザー共通で取得出来るようにし、ユーザー固有の調整（スコアフリーズ中のスコアなど）は後でアプリ側で行うことで、Audience Dashboard と同様にキャッシュ可能にする 16:00 ListNotifications で使っている loginRequired の負荷が高いので調べたところ、必ずしも getCurrentTeam しなくとも、contestant.TeamID が入っている事で判断出来るようなので修正 17:00 ListClarifications も同様に、

チーム名 hidekiy で、 @kotaroy と ISUCON10 予選に参加して、何とか通過しました。 ブログ記事の募集期間が終わらないうちに、当日の行動について記録しておきます。 タイムライン 12:20 予選開始 仕様把握、なぞって検索が本丸っぽい予想。 不要そうな node_modules, target を抜いて、コードを Git 管理する。SSH のエージェント転送で連れてきた鍵を使って、サーバーから直接 GitHub にアクセスしてデプロイとかやる事にする。 サンプルの SSH の設定ファイルに、8081~8083 でそれぞれのサーバーのポート80を開けるようにする設定を入れた LocalForward を追加してチーム内に共有した。 14:00 去年のISUCON予選1位チームのありがたい記事  ISUCON9 予選を全体1位で突破しました  で学んだ Cloud Trace, Cloud Profiler をまず設定する。New Relic はプロファイルが取れれば不要と思ったんで、入れない事とする。リソース監視は top を更新間隔1秒で目視確認して行う事にした。 いずれ問題になってくると思ったんで、nginx.conf でのボット対策を依頼した。 15:00 検索機能がクソ重い事分かったんで、ソート用にいくつかインデックスを追加 (EXPLAIN 確認してない) MySQL サーバーのスレーブ追加を依頼 16:00 なぞって検索のN+1クエリについて、1段目のクエリのWHERE条件に、後段の条件を追加する感じで修正して対応した。 SELECT  * FROM  estate WHERE   latitude <= ?  AND  latitude >= ?  AND  longitude <= ?  AND  longitude >= ?    AND  ST_Contains(ST_PolygonFromText(%s), ST_GeomFromText( CONCAT ( 'POINT(' , latitude,  ' ' , longitude,  ')' ))) ORDER BY  popularity  DESC , id  ASC latitude, lo

当ブログで使っている独自ドメイン hidekiy.com では、学習用で無駄に CAA レコード  を設定して証明書発行が出来る認証局を制限しているのですが、 Google Trust Services (GTS)  についてのレコードを追加した事についての記事です。 2018年に設定した当初は、 Blogger の独自ドメイン用証明書には Let's Encrypt が使われていたので、以下のような CAA レコードを設定していました。 0 issue "letsencrypt.org" 0 issuewild "letsencrypt.org" その後、巷の Blogger のブログでは GTS へ変更されているのに、何故か自分のブログだけ GTS に切り替わらないのが気になって調査した結果、GTS の証明書発行が出来るような CAA レコードを設定する必要がある事が分かり、 Google Trust Services, Certificate Policy などを参考に、 0 issue "pki.goog" 0 issuewild "pki.goog" を追加したところ、無事 GTS 発行の証明書に置き換わりました。  Blogger 側の挙動としては、GTS、Let's Encrypt の順で発行可能な証明書が発行されているような雰囲気があります。 関連記事 [blogger] ブログの HTTPS 化が完了しました