2017ISUCON7予選に出場してきました(インフラ編)こんにちは。サーバエンジニアの@toritori0318です。しisucon7に出場しました。自分からはインフラ視点でなにをやったかを振り返ってみようと思います。してAWS上に過去isuconのアプリ/ベンチマーク環境を構築しメンバーに提供しました。前週末にpixiv-private-isuconを用い、本番想定をしたリハーサル(10:00-18:00)を行いました。メンバー間の役割や手順を確認しながら「どのようにボトルネックに向き合っていくか」を実践さながらにシミュレーションできたのはチームの底上げとしてはかなり効果があったと思っています。methaneさんのisucon攻略をみんなで眺めたり基本リラックスモード。最終確認として読みふけっておりました。開始直後にsshログインできないというアクシデントが発生していたため、その間みんなでレギュレーションを熟読。/fetchが得点にならないこと、/messagesのメッセージ数が得点になること、304はあまり得点にならないことなどを確認。ログインしたあとは自分が各サーバのコア数/メモリ/MySQLのスキーマ毎のデータサイズなど一通り確認。DBサイズもそんなに大きくないのである程度メモリにはのりそうだし最終的には画像配信周りをどうにかするかんじだろなーという予想。「インデックス貼ってないわー」など明らかに駄目なとこは最優先に改善依頼。各サーバにgoバイナリ配るスクリプト書くalias配るミドルウェア/パフォーマンスツール周りセットアップと足回り整えたあと、一旦みんなで全体構成の整理。1という構成で行くことに決定。進め方として「まずはapp1台+db1台でボトルネック潰しつつキリキリにチューニングして行きましょう」という方針を決定しました。Appのボトルネック潰したらあとは複数台で適当にキャッシュかまして画像配信すればコンテンツ配信は問題ないだろーと考えてましたが、この考えがそもそもダメだったことに競技終了後気付くことに...。「/iconsをnginxで1台に集約できたりします?」と依頼されてて「もちろん出来るのですがもろもろ対応後に手が空いたらやりますねー」という感じで後回しにしたまま結局最後まで着手できませんでした。これ今となって考えるとおそらく最終スコアに影響ありそうなとこだったんですよね...(この時点では当然気づかず)そして改善着手へ。ベンチマーク回すプロファイリングアプリ側/ミドルウェア側の改善のサイクルを繰り返しある程度基本的な改善が進んだ段階でdstat眺めていると明らかに帯域がサチってる感じになっていました。(@wankoが記念スクショ取っていたwんじゃーこの辺りでNginxにgzipとかexpire入れとくかー、ってなって入れたんですが、多少スコアが上がるもののベンチマークからは「静的コンテンツおせーよ」的な感じで怒られ続けててなんでー?ってなってました(おそらく他チームもみんな通った道)どうやらicons周りのキャッシュが効いておらずぐぬぬ。開始3時間が過ぎたあたりからスコアがなかなか上がらず停滞期。アプリやインフラいろいろ弄ったりするもベンチ通らなかったり逆に下がったりと苦しい時間帯...自分の方はというと相変わらず帯域がなかなか下がらないのと格闘していました。ここ突き抜けないと上位に行けない感があったのでだいぶプレッシャー感じてました。versionに戻しました。WAITがゴッソリ現れるいつものやつが出てきたので「はっはっはっ、またお前か。:(他にもこのあたりの時間帯、よくわからない現象でOpenRestyが動作しなかったりと、おそらく1時間以上無駄な作業で大きなタイムロスをしてしまいました。ここはだいぶ痛かった。終盤60000超え程度で停滞していた頃、上位チームは10万超えもゾロゾロ出てきていてさすがに焦りモードに。publicにたどり着き11万超え!この時点でtop8に食い込めました。いう構成で、app2が遊んでいる状態だったので「これでapp1とapp2をwebappにしてベンチかければ倍push行けるのでは!!!???」とメンバーの期待も高まりました。😵うーん、理由はわからないけど他のボトルネックにぶつかったんだろうか?とパニクってすぐに諦めてしまいました。いう構成にしよう、と決定しました。判断の迅速さ攻めの足りなさ1.に関しては、特に今回は総合的な理解力が求められる問題だったと思います。今回のチームカリスマの場合、メンバー全員が業務的にメインがAPIサーバ担当のため、サーバアプリケーションの改善については全く心配しておりませんでした。全員静的コンテンツ配信は得意分野ではなく、チームとしての得意分野が偏っていたのは否めなかったと思っています。publicやif-modified-sinceの挙動にすぐ気付くことができませんでした。この辺りもう少し自分が補填出来ればよかったのですがここは完全に自分の力不足でした。今じっくり本を読み直しております。いった時にチーム内の複数メンバーがインフラ/アプリ含めてカバーできるチームが本戦に出場できるチームなのではないかと思います。2.に関しては自分も含めメンバーもハマってウンウン唸る時間帯が多かったので、5分くらいやって解決しなければ捨てて戻して別のことをやる、くらいのスピード感があってもよかったかなとおもいました。3.に関しては最後の11万超え辺りの判断です。この時点でtop10圏内にいたし残り時間も多くはないし、よくわからない原因でスコア落ちちゃったし、ここは攻めずにリスクを取らない方向に行こう、と心理的に考えてしまったような気がします。Redisを別サーバに置いても全くスコアアップしなかったのは明白ですし、この時点ですぐにサーバ増やしてもスコアが上がらない原因を探るべきでした。落ち着いてNginxのログを確認すれば原因に気づけたはずです。ここに関してはあとからだいぶ後悔しました...ただ、実際あの状況で落ち着いて対応できたかというと自信がないですね。ありがとうございました。このような大規模なインフラ環境を構築していただいたさくらインターネット様ありがとうございました。本当この規模のプロビジョニングは大変だったと思います。素晴らしい予選問題を作成/運用していただいたisucon運営のみなさまありがとうございました。まとめ足りなかったことなどつらつら書いたのですが、チームとしてはやれることはやれましたし、最終的に上位に食い込めたのもこのメンバーあってのものでした。ありがとうございました!総じてとっっっても楽しかったのですが、とっっっても悔しいので来年も開催されることがありましたら絶対に5本の指(カリスマ)に入って本戦行けるように今から精進します!!!お約束HAROiDではTV、あるいはTVとWebを使った何かを支えるエンジニアを募集中です。↩これ結局原因わからず。↩ここに関しては複数サーバで違うif-modified-sinceを返してしまっていたことが原因かと思われます。