wtatsuruの技術方面のブログ

はてなスタッフ id:wtatsuru です。日常ブログはこちら https://tatsuru.hatenablog.com/

ISUCON11 予選に参加しました #isucon

ISUCON11予選に、去年と同じヌルポインターマリアユニバースというチームで id:polamjag id:Pasta-K と出場しました。
isucon.net
最終スコアは36971 でした。リポジトリはこちらです。
github.com

問題・競技環境が素晴らしかった

まず、今回の出題は本当にすごくよかったです。出題者の方、おつかれさまです。
問題は、シンプルな割にボリュームが多く、ボトルネックが移りかわるすごくいい問題だし、見てて面白かったです。実装も綺麗で読みやすかったのがよかったです。
ベンチマーカーのトラブルもちょっとあったとはいえ、全般的にほぼ待ち時間なくて快適。全体的に最高です。

個人のふりかえり

いい問題だっただけに、点数を出せなくて個人としての反省点は多い。
まず、手数が足りなかった。ボリュームが多かったけど、手を動かす速度に課題あったなーという感じ。凡ミス多かったり、ログとかデプロイとかやるだけのことものんびりやってしまった。最近業務で手を動かしてないし、ちょっとずつ鈍ってきている可能性がある。
作戦ミスもあったかなー。書き込み叩き落としてるのがおかしい・ポイントが多いとスコアが何倍にもなることはわかってたし、データ量も多い。結局叩き落とす数を減らせなかったので、大技をそこに集中してもよかった。

何をやったの

今回も15分スプリントでやりました。変化する状況はスプリント会に詳しいです https://github.com/tatsuru/isucon11-qualify/issues/3
自分の視点を中心に思い出してます。酒を飲んでるので微妙な前後はあるかも。

  • 基本的には今回もインフラ担当、あとは他2人がペア作業するあいだの司令塔っぽいこととかファシリとか。
  • Cfn適用、計測環境、デプロイ設定、あたりの設定。MariaDBMySQLで設定値が違うところで若干ハマる
    • すぐできそうなSQL改善して17000くらい
  • サーバ分散。DBヘヴィなこと、ISUからの投稿先を指定できることもあって、分散すると大事だろうとなったので早めに着手
    • チームメンバが condition の調査も始めてる
  • この辺で昼休み
    • 2台構成で動いてる
    • ここから、アプリケーション側は condition に手を付け始める。参照側のチューニングからやってたけど、今振り返るとMySQLを脱出するところをやるべきだったポイント。
  • 3台構成にした
    • DB動かしたときにちょっと不具合出してハマった
    • このへんで30000弱
  • 小細工
    • dropProbability 一気に下げてみたり
    • conditional get 実装したり(効いてなかった...)
    • dropProbability 0.75 にして 36000
  • デバッグの手伝いしつつ作戦考える
    • 画像がDBに入ってるのでファイルに書くやつハマってた。エラーログ見づらかったりしたのでデバッグ手間取ってたので一緒に見た。Go に慣れてなさがあってちょっと無駄にした...
    • 後でどうせやるやつを入れてた。でかいやつはgzipInnoDB はデータサイズ見えたので buffer pool と trx_commit を調整するいつものやつ
    • リクエスト状況見て次の作戦考えてた
  • 画像をファイルに書くの成功
    • 苦戦したけど成功
    • DBが暇になって、バランスが結構変わった
  • 1時間前になってベンチマーカー停止
    • あんまり分散できてないのでDBネックを解消する手を作ってた。アプリが片方暇なので仕事のバランス調整準備
    • クライアントキャッシュきいてないねっての直したり
  • ベンチマーカー復活、分散作戦考えていく
    • 負荷が変わらない前提でホストの分散具合を調整していく
    • チームメンバは大技として trend の N+1 に取り組む
  • 最後のあがき
    • ログ切ったりモニタリング止めたり、dropProbability 調整したり
    • 最後5分で db.SetMaxOpenConns(10) のままだったのを見つけたので100にしてみる
    • 最後のベンチ、速くなった気がするけど制限時間に終わらなかったのでスコアわからず

まとめ

問題は成功、個人としては反省。1年間つらい気持ちで過ごしそうな気がする。精進しよう。
ちなみに去年はこちら
wtatsuru.hatenadiary.com
このブログISUCONばっかりになってるな

リモート勤務用の部屋を作った

3月頃から自宅勤務をメインにしており、2年くらいはリモートメインになりそうな状況になった。チームメンバもだいたいリモート作業していて、仕事を進める上でそんなに不自由はしていない。しかしこれまで自宅に作業スペースがなく、ソファで仕事していてあまりいい状態でなかったので、この機会に仕事用・作業用の部屋を作った。
pr.hatenastaff.com

まずは引っ越し

会社の近くに住むメリットがなく、また作業場所を作ろうにも物理的に場所がなかったこともあり、まずは引っ越しをした。
10年以上それなりの都会に住んでたので、いきなり離れすぎることに対する不安もあり、会社からある程度の距離に収まる(電車で1時間以内)範囲から探した。ちょっと郊外のベッドタウンで駅徒歩10分ちょい、5畳くらいの個室を確保できる分譲賃貸マンションで、いいところが見つかった。

作業環境作り

f:id:wtatsuru:20201104192727j:plain
作業環境

まずは机。会社で教えてもらった、かなでもののデスクを注文した。部屋のサイズぴったりで注文できて、ちょうどいい位置に配線孔もつけてくれる。揺れないしっかりしたつくりで、いまのところすごく気に入っている。最近話題の昇降デスクも考えたが、会社においてある昇降デスクを全く使ったことがないので今回は見送った。
THE TABLE / 杉無垢材 × Black Steelkanademono.design

椅子は、会社で使ってるオカムラのヴィスコンテを中古で調達した。入社した日にそこに置いてあったから使ってるんだけど、背筋が伸びるしちょっと座面が広いので気に入っている。

ディスプレイはDELLのU3219Q。USB-Cで給電と出力できるのが必須で、会社で使ってる27インチからもうちょっと広いやつにしてみようかなという挑戦。まだ慣れなくて、端っこの方にはウィンドウ置かずに使ってる。プライムデー前後にちょっと安くなってたタイミングで購入して、エルゴトロンのアームにつけて使ってる。

キーボードとトラックパッドは、これまで使ってたHHKB BTとMagic Trackpad 2。会社に置いてあるHHKB Hybrid Type-S のほうが静かなので、こちらを家で使おうかなと思ってる。

Apple Magic Trackpad 2 - スペースグレイ

Apple Magic Trackpad 2 - スペースグレイ

  • 発売日: 2018/05/16
  • メディア: Personal Computers

リモートの会話は有線のイヤホンでやっている。スピーカー置いたりマイク置いたりしてデスクがごちゃごちゃしてくるのもなんか微妙だなと思って、いったん無しで過ごしている。困ったら考える。

結果

家でめっちゃ集中して仕事ができるようになった。食事・ゲーム・テレビみたいな空間と地続きの作業場だとどうしても気持ちを切り替えられなかったりだらだら休憩してしまいがちだったのが、場所を分けることでだいぶ切り替えがやりやすくなっている。連休明けなどは仕事しすぎてしまうが、まあそこは調整すればいいかな。
悩みとしては、昼夜のごはんの準備が大変なことくらいか。以前と比べて徒歩圏内の飲食店が少し減ったりUberEatsの選択肢がちょっと狭まったのもあり、自炊の効率化などもう少し考えていきたい。

ISUCON10 本選に出場しました。7位でした。

ISUCON10 決勝にヌルポインターマリアユニバースとして id:polamjag id:Pasta-K と出てきました。スコアは28628の7位。個人としては ISUCON5 以来の本選で、もうちょっと上を目指せたなと悔しさ残るものの、今はこんなもんかなとも思う結果となりました。
isucon.net

当日の様子

リポジトリ公開したので、詳しくはこちらをどうぞ。 https://github.com/tatsuru/isucon10-final

  • 本番までにやることTODO · Issue #1 · tatsuru/isucon10-final · GitHub
    • 事前に予選の振り返り会とアクション出し。わりといいTRY出たものの、やったのはだいたい当日の朝。まあそんなもんだね。
  • 10:50 問題読み会場 · Issue #5 · tatsuru/isucon10-final · GitHub
    • 全員で問題読んで様子を把握。ここまで50分くらい、ほぼ作業せずに様子の把握に集中。
  • 10:55 スプリント会 · Issue #11 · tatsuru/isucon10-final · GitHub
    • 今回のみどころ、15分スプリント開始
  • 12:15 作戦会議 · Issue #10 · tatsuru/isucon10-final
    • コード読み・ログ出しと全貌把握が完了して全体の方向性決めたのがこのあたり。インフラ作業進めつつ dashboard から取り組もう、という動き出し。
    • まだコード全くいじってないしデプロイもしてない。ここまでがもうちょっと早くできたらよかったかな。
  • 14:00頃
    • ペア作業事始めとしてN+1を1つ倒している。効率が悪いので VSCode Live Share やろうぜってのがよかった。
    • インフラ面はデプロイ・ログ分析体制あたりを粛々と入れてる。この辺からスクラムマスター役を全部巻き取る。
  • 15:43頃
    • ペアプロがノッてくる。/api/audience/dashboard の1秒キャッシュ(雑)と50秒フリーズが順調に終わって成果が出始める。
    • インフラ側はベンチ回して負荷や TeamCapacity での変化を見たり、DBチューニングをちょっと入れたり。スコア上げると増える通知周りを次のターゲットにした。
  • 16:55頃
    • 通知周りが一通り完成、サーバー分散準備。
    • 全部入れてTeamCapacity = 20 で2万点くらい。ちょうどいい状態でリーダーボード固定されたので自分たちの位置は認識できた。
    • スプリント会はここで途切れている...
  • 17:30頃
    • 終了30分前、あがくと決めてた最終ライン。
    • サーバー構成の試行錯誤、TeamCapacity 変更あたりを回して調整。スコアの仕組みを見てキャパシティトライしたり、web push 入れたから通知レスポンスは空でいけることに気づけるなど、土壇場でルール把握が効いた。
    • しかし試行錯誤の時間が足りず、最終的には TeamCapacity 65 でやめている。
    • Envoy 突然死を LimitNOFILE=65535 で一発回避したのはナイスだが、焦っててログに残してない。
  • 最後
    • 再起動試験として1台落としたところ、上がってこず焦る。運営チャットで問い合わせたらすぐに再起動してもらえて九死に一生を得る。
    • 最後まで回し続けて微調整。17:58 のベンチで Fail したときは青ざめた...。

振り返り

  • それなりによいスコアで終われた
    • まあ今の実力としてはこんなところじゃないか。トップを狙うにはもうひと押し足りなかった。
  • 15分スプリントがうまくワークした
    • ハマった作業を諦める、適度に休憩する、など人間的な生活を送れている。生活の知恵。
  • インフラ作業と司令塔みたいなのは、それなり。
    • 前半、全体に目がいきすぎてログ分析が疎かになった。全体のボトルネックになっていたと感じる。
    • 後半で粛々と進めつつ、残り2人の進行をサポートするのは悪くなかった。
  • 個人として、テクニカルなスキルは微妙かなぁ...。
    • Commits · tatsuru/isucon10-final · GitHubインフラ作業ログ · Issue #4 · tatsuru/isucon10-final
    • 今回とくにインフラ作業ばかりやってた。Envoy微妙に慣れないけど致命的ではなかったし、作業の精度は及第点、速度もギリギリOKだと思う。
    • デプロイ、サーバー構成なんかは普通にやることやった感じ。3番にDB持っていけば速いだろうというのはわかってたのに、残り時間が少ない+メモリ消費に日和って諦めてしまった、これは猛省。

仕事でエンジニア業から離れて全然手を動かしてないという危機意識から現状の確認をしたいというのが最近ISUCONに出る理由なんですが、今回は手応え半分、危機感半分ってとこです。伝統的なペットの面倒を見る作業は70点、Envoy gRPC あたりで戸惑うというちょっと遅れてる感で -20点。司令塔・マネージャーとしての方が最近の本業で加点してもいいけど、今回コード書いてないので相殺。

サーバ運営や問題はすごくよかったです。サーバートラブルはほとんどなかったし、ベンチマークは快適で競技に集中できる環境でした。問題も、ボリュームと複雑さ、ISUCON運営という意表をついたテーマ、インフラもアプリも工夫の余地が散りばめられていた点、など近年まれに見るよい問題だったと思います。Youtube Live や副賞あたりの盛り上がり施策も楽しかったですね、あとでじっくり録画見ます。運営の皆様、おつかれさまでした。

ISUCON10予選 ヌルポインターマリアユニバースとして出てギリギリで本戦いけました

ISUCON10、ヌルポインターマリアユニバースというチームで id:polamjag id:Pasta-K と一緒に出てきました。
isucon.net
最終スコアはたぶん2335、なんとか予選突破できました。

振り返り

今回はあまり役割を決めず、時々で臨機応変に動くぞとやってました。結果的にインフラ面はだいたいやることになったし、結果につながったのはよかった。とはいえやった作業自体は簡単なものなので、もうちょっとコードを見られたはずだし、絶対的に足りない気はしてる...。

  • 最初にルールを全員で読んだ
    • これはよかった。スコア算出、ルールの問題についての認識は最後まで問題なかった
  • リポジトリに入れるのをまかせつつ、ログ出したりデプロイ準備したりしてた
    • デプロイ準備は長引いてしまった。問題についての雑談をしながら準備してしまったからで、ここはひたすら作業だとわかってたから思い切って集中してよかった気がする
  • alp の上位を見てどうしようかねーって話ながらランチタイム
    • これはよかった。椅子がドアに入るかどうかのロジック、「なんかありそうだねー」くらいで、ボトルネックじゃないから後回しにするみたいな話を力を抜いてできた
  • 昼過ぎは作業分担。search 高速化は置いといて、low_priced と nazotte の N+1 みたいな、やればいい+効果高そうなところにはじめから取り組めた。同時に複数台の仕込みも始めた。ついでにINDEXも貼った。
    • 軽そう、効果高そう、みたいなポイントから取り組めてよかった
    • INDEX やればいいしいれないと分からないみたいなやつに早めにと思ってたので、まあよかった
    • 一番効果高い search のところ、全員で会話していいアイデアがなくて、ちょっと後回しになってしまった。最後までいい解は思いつかなかったので、いいのか悪いのか。
  • N+1 を解決するのとDBホストを分けたことで2000くらいまで上がった。このへんで15分スプリントをやった
    • 15分スプリント、1つのレビューとか作業がちょうどよく終わる感じでよかった
    • 本番で順に試したことで、やれたことに対して試行錯誤の時間がちょっと長かった気がする

  • 最後の2時間、search を range じゃなくて id 使うことで高速化するのをお願いしつつ、自分は slave 複数台分散をやった。ついでに query cache と innodb_buffer_pool の増加をやった。スプリントは崩壊した。
    • それぞれハマりがちになって、口数は減った。15分は短いけど、30分くらいで状況共有できたらよかった気がする。
    • slave 分散、sqlx のインスタンスを複数用意しといて使い分けるみたいな器用なことはできなかったが、search だけ振り分けるのをインフラだけの最小工数でできてよかった。準備しかなかったので試す時間を持てなかったのと、実は SELECT ... FOR UPDATE を無視してるのがだめ
    • search の改善はめっちゃでかい必殺技なわりに、着手が遅くなったので結局入れられなかった
    • DBのチューニング、やるべきかどうか微妙だと思ってた buffer_poool と query_cache にもちょっと早めに取り組めた。意外と効果が上がって、盲点だった
  • 最後の1時間で微妙な調整とか nginx 複数台分散のトライをやった。
    • DBのCPUでサチってるので、分散したら速いだろうというのはわかってた。レプリケーションの構成とかシュッとできてすぐ試せたのがよかった(やればできるだろうと油断はしてた)
    • nginx 分散、なんかデプロイでミスってた気がして焦ったけど、なんとか入れられてよかった。レプリ遅延対策で initialize に wait 入れたのもここだった...
    • ベンチマークの結果は安定してたし、ガチャする時間もあってちょっと余裕は合った

詳しくは

リポジトリは公開してるので、詳しくはこれ見てください https://github.com/tatsuru/isucon10q
公開前に deploy key 無効にするとかまずい情報無いことは確認してますが、なんかこれまずそうみたいなの見つけた方はこっそり教えてください。

本線がんばります

Go のコード読むの遅いし、コード書く時間もあまり取れてなかった。
本番はもうちょっとインフラ面が複雑になるかも知れないけど、もうちょっと手を広げられるようにしていきたい

The Amazon Builders' Library がなかなか面白い

タイトルが全て。みんな読んでみてほしい(主語がでかい)。
aws.amazon.com
Amazon が自社のシステムを構築する中で構築してきたノウハウを集めた場所。以前 Cloud Design Pattern みたいなものがあったけど、より背景事情を深めつつ洗練されている印象。昨年末に発表されてから素早く翻訳されており、日本語で読めるコンテンツとしてはかなりよいものだと感じた。
内容についてっは、分散システムがなぜ難しいのか、ということから始まり、タイムアウトやキャッシュ戦略、ヘルスチェックなど特定のトピックでの課題について深めていく形。ときどきに出てくる用語や現象について個別項目の知識はインターネットに散在しているが、メリットだけでなくどういうリスクとトレードオフなのか、どのレイヤで考えるのか、まで伝えてくれており、知見の結晶という感じ。コンテンツの追加が楽しみだ。
ちなみに分散システム自体の知識はあまり解説してくれず、AWS Developer Blog にちょっとリンクが貼ってあったりする程度。この辺の前提知識は、今だとOreillyの本かな。

AWS Solution Architect Professional を取得した

ちょっと機会があったので、AWS Solution Architect Professional という認定を取得した。この試験自体は知っていたが、資格試験系全体にあまり興味がないのもあり、スルーしていた。実際に受けてみて、知識の確認・補完としては悪くないと思ったので書いておく。
AWS 認定ソリューションアーキテクト – プロフェッショナル

AWS Solution Architect Professional ってなに

公式の説明はこんな感じ。一般的な「アーキテクト」の能力(の一部)を評価する、という印象。

認定によって検証される能力
  • AWS で、動的なスケーラビリティ、高可用性、耐障害性、信頼性を備えたアプリケーションを設計し、デプロイする
  • 提示された要件に基づくアプリケーションの設計とデプロイに適した AWS のサービスを選択する
  • AWS で複雑な多層アプリケーションを移行する
  • AWSエンタープライズ規模のスケーラブルな運用を設計し、デプロイする
  • コストコトロール戦略を導入する
https://aws.amazon.com/jp/certification/certified-solutions-architect-professional/

サンプル問題 があるので、まずはこれを見るのがイメージしやすい。典型的な課題やユースケースを出し、AWSを使って解決する最適な手段を選択肢の中から選ぶ感じ。前提が多いものもあり、1つの企業内でやってる自分なんかだと、普段はあまり縁のない状況も多くあった。
ちなみにAWSの認定ってざっくり言うけど、実はいろいろあるらしいというのも今回知ったところ。
AWS 認定 – AWS クラウドコンピューティング認定プログラム | AWS

実際に受けてみた感触

だいたい10月から準備し始めて、11月はじめに試験を受けた。試験を受ける、そのために勉強するという体験がそもそも大学院入試以来で、緊張やらペースづくりからどうやっていこうねという状態からスタートした。
自分の性格的に漫然と過ごしていてもまず勉強しないので、最初に試験に申し込んで締切を作ってからスタート。締め切りを作るのだいじ。その後の対策としてやったことは、おおよそこの3つ。

  • 会社で勉強会をして強制的に時間をつくる。
  • 模試と対策講義を見て傾向を知る。
  • AWS が出している Blackbelt Seminar の資料を眺めて足りない知識を補完する。

勉強については、AWS自体はずっと(初めてAWSについて発表 してからでも8年だ)見てるし、その間にいろいろ変化も見てきた・会社でも使用を広げてきたので、多少知識を補完すればいけるかなという目論みがあり、実際に模試を受けてもそんなに悪くはなかったので、この作戦は悪くなかったと思う。
勉強して一番役に立つと感じたのは、実際にリリース情報やサービスの概要は見ていて「何をするものか」をなんとなく把握していても、「どんなユースケースでハマるか」の肌感がない領域の知識を得られること。頭の片隅に置いておいて損はないタイプの知識だと思う。自分で構築・運用しているものや、社外で近い領域の人からインプットをもらう機会があればいいが、そうでない領域についてもある程度網羅的に得られる機会があるのはよかった。自分の場合は長らく触れていなかった AWS Organization のフル機能だったり、手を動かすのをサボっていたSQS Kinesiis あたりの非同期処理の設計。ただし、やっぱり自分で触ってないと実感はこもらないので試験対策だけで勉強する部分ばかりになるとちょっとつらいし、ある程度の知識・経験は前提として持っている方が役立てるものだと思う。
他には、「AWSでやるならどうするか」という観点で考え続ける機会が得られる点はよかったかな。現実の課題を解決する上ではもう少し自由に手段を考えるのだけど、現代においてはまずクラウドプラットフォーム上で取りうる最善を考えた上で、それでもやりづらいところのみ作り込む・足りない要望を出す、という順は悪くないと思うので、こういう縛りプレイはよい方向に転がるはず。まあしかし、ソースコードを変更できないとか、理不尽な組織構造が前提になった問題にあたると、さすがにそこを変更しようよという気持ちになることもあるのだけど。
良くも悪くもコンソールを触ることすらなく勉強できる範囲なので、スキルの確認という意味ではあくまで参考にする程度かなというのは全体の感想。

勉強内容

自分の場合の事例。

  • 社内の勉強会を週1で開催する。だいたい1-2時間くらい時間を確保。
  • まずはひとつ下の Solution Architect Associate (SAA) を受けてみることに。
    • 黒い本 徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書 を読んで勉強。どういう領域が出題されるか、体系的に書いてある感・安心感を得られるのが書籍のいいところ。
    • 模試を受けて感触を得る、足りない部分を把握する。模試ではどこが間違ったか教えてくれないので、せめて迷ったサービスについてはメモっておくと後で勉強しやすい。
    • AWS INNOVATE というオンラインカンファレンスでちょうどセッションやってたので見て雰囲気をつかむ。これはまさに学校の受験対策という風情でよかったので、AWS様にはぜひとも復活させてほしいコンテンツです。
  • SAA本試験
    • テストセンターに行って受けた。オンラインで開催する試験を行う専用の会場で、手荷物を預けた状態で専用のPCが並んでいる部屋に案内され、そこで受験する。最近は漢検なんかもこういう場所で受けるらしい、知識が20年前で止まってて全く知らなかった。
    • 小さくて解像度の荒いディスプレイを見続けてちょっとつらかった。
    • 867/1000で合格。時間はわりと余ったが、見直しなどせずにサッと出てきてしまった(よくない)。
  • Solution Architect Professional (SAP) に向けて勉強。
    • AWS INNOVATE に Professional 対策講座があったので見ておく。Associateと同様、まさに試験対策という趣でよかった。
    • 模試を受けてみる。85%。Design for New Solutions という分野が弱いことがわかった、この辺は↑にも書いた通り手を動かすことをサボってた分野でもある。
    • INNOVATE と模試で弱いなと思ったサービスの Blackbelt Seminar を読んでいく。日本語のスライドだと1つ10分くらいでサクサクいけるとテンポよく読んでいける。
    • AWS公式のコース にある該当ホワイトペーパーに行けるのでそれも読んでみたが、2,3読んだところで飽きた。自分にはあまり合わない、楽しさが足りなかった。
  • SAP本試験
    • 別会場、土日であることもあってかSAAの時より人が多かった。隣にいるのは気にならないが、正面の席を立つ人など視界内で動かれるとさすがにちょっと気になる。
    • 今度はディスプレイが少し大きいものの、相変わらず解像度低くて荒いし、アスペクト比もなんか変な気がした...。
    • Associate のノリでゆっくり問いてたら時間がなくなり、結局最後ギリギリになってしまった。180分集中するのはだいぶ疲れる。
    • 結果は合格。837/1000
  • 内容について
    • 試験内容については、守秘義務があるので細かいことは言えない。
    • 日本語で受けたものの、翻訳に違和感を感じたらすぐに英語で読むようにした。これはよかったと思う。
    • 回答方針は「出題者の気持ちになって考える」がよいと感じた。多少前提条件が足りなくてもクラウドのプラクティスに乗るのが善という価値観に立ってみる。

まとめ

AWSの認定を受けてみた。知識の確認と補完にはそれなりによいとは感じる。AWSのイベントで認定者ラウンジとか見たので、次は使ってみよう。
f:id:wtatsuru:20191201012134p:plain:w200

ISUCON9 予選に出て敗退した

だいぶたってしまったけど、ISUCON9 の思い出を供養しておく。
サザン不定形ストーリーズというチームで出て、結果は予選敗退だった。
isucon.net

チーム編成と事前準備

出るぞとだけ言ってギリギリまで何もしてなかったのだけど、直前に誘ってもらったチームがあったので入れてもらった。
事前に集まって、多少準備をしてた。これまでチームメンバは出たことあるメンバで組むことが多かったので、コミュニケーションチャンネルなど1から整理していったのが新鮮だった。

  • Alibaba Cloud アカウントを作ってみんなで触る練習
  • GitHub リポジトリ、Slack チャンネル、Scrapboxページなど準備
  • 言語、当日の集合
  • 予習ネタ集める

当日の動き

当日、明らかに一番コード書けないのが自分だったので、足回りの整備と作戦とりまとめみたいな動きを主にしていた。

  • 10:00 ルール読み
    • 他のメンバは、最速でアプリケーション動かしてコードを読む担当、Alibaba Cloud でインスタンス起動して全員サインインできるようにする、などやってもらってた
  • 10:30 nginx ログ設定だけ入れて初期ベンチ回す
    • alp でログ解析するところまで。alp 予選前日にリリースされてるし、Starも増えててISUCON専用ツールとして存在感を増している感がある。
    • 他のメンバは、コード読みとデプロイ整備をやってもらった。デプロイスクリプトは前日にひな形置いてたやつベース。
  • 11:00 作戦会議
    • 各自の作業概要共有、大まかな方針確認。
    • ここでキャンペーン試行錯誤すべきか、なども会話できた。順調だった。
  • 初手の改善
    • 自分は、デプロイからスムーズに動くまでをやってた。手元からログ解析打てるようにする、デプロイ直しつつ nginx で static file 配信、ついでにルーティングファイルからエンドポイントごとに nginx location 分離。画像アップロード先修正忘れてたので対応したり。
    • 他の2人で N+1 ペアプロ、カテゴリを初期化時にオンメモリで持つように。
    • キャンペーンの値もちょっといじってみて様子を観察。
  • 13:32 作戦会議2
    • やることはやった段階での作戦会議。
    • キャンペーンやると購入リクエストが殺到する、/buy が遅くて売上られていない、外部APIがたまにタイムアウトしてる、ということはわかってたので、対応を検討。
      • API リトライって話も出てたけどなんでやらなかったんだっけ...
  • 複数台化、リクエスト試行錯誤
    • 自分は粛々と作業して複数台化。MySQL 外部からアクセスしてアクセス先IP固定、初期化やアップロード関連など一部の処理だけ01に振る、など粛々と作業。
    • アプリケーション的には、トランザクションが長い対策として for update 消せるやつは消したりしてた。
    • innodb_lock_timeout = 3 で意外と簡単にタイムアウトしてくれた。実際に使ってみたのは初めてだった。
  • 14:30 作戦会議3
    • 複数台化の残作業。カテゴリをオンメモリ化した関係で全台に initialize 渡す必要がある > ここは自分が担当
    • 購入リクエストのトランザクションがとにかく長いので、「購入中」というステータスを作って分離することを考える。がっつりペアプロしてもらった。自分はこっちは戦力外。
  • 16:00 作戦会議4
    • /buy 分割したことでボトルネックが移った。買えないときに素早く失敗してる。
    • item 関連、user 関連タイムラインが遅いのでインデックス貼っていく。/login は遅いけど bcrypt だしレギュレーション的にどうしようもないねって会話した。
  • 17:00
    • 複数台でリクエスト受けた瞬間に fail 多発
    • 並列でAPI投げてる?など疑って httpclient 使いまわしてみたり
    • キャンペーンガチャやってみても同様に fail が多発する
  • 18:00
    • 最後に fail しなかったそれっぽいスコアで終了。たしか2700くらい
    • 3710 がベストスコアだった。

振り返り

  • 準備はまあまあよかった
    • 起動してデプロイしてログを観察する、まで含めて
  • 問題は適度に複雑でよかった
  • 最初は状況認識はできていた
    • 上と合わせて、良くも悪くもISUCONに慣れてるということ
  • 途中から焦りがでた
    • APIのリトライ、あとでやろうとして忘れ去っていた案があった。
  • 落ち着いてシステムの理解ができていなかった
    • ホワイトボードに描いてコードも眺めてたつもりだったが、結果としては状態遷移の考慮が甘かったのが敗因となっている。
    • ユーザ視点、システムが実現しようとしていること、を落ち着いて考えることが必要だった。自分はそこができた立場だっただけにちょっと悔しい。
  • Go 言語にみんな慣れてなかった
    • 仕事で使い込んではいないメンバ。APIエラーをダンプするだけでもそれなりに時間を食ったり何かとアクションが遅かった。
    • 自分はコード書くの遅かった
      • ミドルウェアあたりはサクサクいく、サーバサイドのコードに手を入れようとしたときに何かと遅れる。
      • 最近自分で手を動かすことが減っており、趣味においても技術系やそれ以外のこと含めインプットに比重が置かれている。多少は手を動かせる状態でありたい。

まとめ

こういうアドレナリンが出るイベント、たまにはいいなと思った。現場感覚持っておきたい。そろそろ決勝に行くのもきつくなってきた最近だけど、もう一回くらい行きたいな。

はてなで一緒に働きませんか?