#ISUCON 5に参加して普通に予選敗退しましたが楽しかったです

チーム名「恵比寿ローラーコラボ」でISUCON5に参加しました。

ISUCONは全員が初めてで、GCPも全員が初めてだったので、はっきり言ってどうなるかわからない、すごく情けない結果で終わるのではないか、ということで、記念受験のつもりで気楽にいこう、という意識と、お昼は半額のドミノピザにしようという２つのコンセンサスだけ得た上で臨みました。

結果としてはベストスコア 8387 、最終スコア 7806でベスト20入れず…でした。
しかしもともと1000未満くらいのスコアで終わってしまうのではと思っていたので、打ち上げでHUBで飲んでいた時には、「思ったよりスコア取れてよかったよね」とか、「次はランク20以内とかに入りたいね」なんていうかなり前向きな言葉が出てきて気持ち良くビールをいただくことができました。

こんな楽しいイベントを企画していただき、実装していただいた運営者の皆様には深くお礼申し上げます。とても楽しかったし、勉強になりました。ありがとうございました。

スコア遷移


score 状況
546 初期状態で起動されてるrubyのアプリがベンチマークに通る
702 Goのアプリに変えてベンチマーク
983 ググりながらDBにインデックスを貼る。この時点ではみなさん初回ベンチマーク通過に苦戦しておりなんと暫定４位！W
1042 MySQLにバッファプールの設定などを追加して再起動。この時点で12時すぎ。みんなでドミノピザを食べる。このときたしがギリギリ19位。
1030 プログラム方面の解析でまだ具体的な変更を出せないのでMySQL周りを引き続きいじるも結果でず
1008 同上。
1041 同上。
1031 同上。この辺りから（たいしてスキルもないのに）ミドルのチューニングじゃもう稼げないかななどと思い始める。
0 インデックス貼り直し中にベンチマークしてしまいCPUが耐えられずfail
7 アプリの改修がうまくいっておらずfail
7 思いついた案がことごとくfail
7 つらい
1114 そんなさなかNginxの設定を見直してハイスコア更新。希望の光がほんのり戻る。15時くらい。このころはもう20位が7000とか取ってて自分たちはTOP20からあっさり消え失せる。
1064 SQLがネックなはずという方向性でアプリを修正するも
1070 うまく結果が出ず
1046 迷走
1378 SQLのSELECT分で * を指定しているところは個別にカラムを指定したほうがいいのでは？という発想からSQLを修正する。
1917 relationsテーブルに関するSQLでORを使っているところがあったが冗長だからいらなくね？という発想からSQLを修正する。この時点でラスト１時間くらい。
3373 引き続きrelations関連のSQLのORを消す
8387 LIMIT 1000してるところは1000行もいらなくね？& isFriend関数通す必要なくね？という発想からSQLとGoをちょこっと修正したら効果絶大。
7806 最後にベンチしたらなんか下がった。


よかったこと


  • apt-getでアップデートして死んだりとかしてるチームもいたので、そういうことはやらずに、最後まで最初のインスタンスでトラブルなくやれたこと
  • 午前中に例のタマキさんバグが出たけど、割とすぐ「ベンチマークをやり直せば回避できるバグだ」ということを発見し、チームに対処不要の通達ができたこと
  • すごく遅くなったけどスロークエリのログを出して一番時間がかかっているSQLを特定できたこと（インデックス追加した後だったのでどれも１秒未満だったけど…）
  • ぐぐりながらだけどNginxやMySQLの設定を追加してスコアアップに貢献できたこと。
  • Nginxのgzip圧縮を試して、それがベンチマークアプリ的にダメだとわかって、切り戻してfail回避して作業継続できたこと。
  • Githubのプライベートリポジトリでソースコード管理して慎重に改善できた


改善点


  • スロークエリを特定してアプリ担当にフィードバックするまでを午前中にできたらもっと違ってた。ソッコーでやるべきだった。
  • ３人中Goがわかる人が一人だけだった。みんなのGo基礎力が高かったらもっと違ってたかも
  • Redisの経験がなくてRDSのデータ載せ替えとか全然やれなかった。練習しとくべきだった
  • GCPも全然練習できなかった。
  • DBのAnalyzeとかExplainとか全然できなかった
  • GCPのインスタンスとローカルでファイルをやりとりする、デプロイするところが思ったより苦戦した。Ansibleでサクッと自前ユーザを追加したりすればよかった。

私はインフラ担当として参加しましたが、わたしのインフラスキルが総じて低く、プログラマがより成果を出せる開発基盤を提供することがうまくできなかったことがやっぱりチームのネックの一員だったのかなと思います。
ただ、実際に時間内でのパフォーマンスチューニングを行ってみたり、他の好スコアのチームのブログなどを読んで、「もっとこうすればよかったんだ！」というところが所々見えてきたような気がするので、前向きにスキルアップに臨みたいというモチベーションが上がっています。
そういう点も含めて、ISUCONに出て非常によかったと思います。
改めて、運営のみなさん、非常に有意義なイベントをご提供いただきまして、ありがとうございました！


コメント

コメントを投稿

このブログの人気の投稿

一部のユーザだけ NET::ERR_CERT_REVOKED でサイトにアクセスできない

イメージ
一部のユーザから、HTTPSのURLにアクセスできなくなったという連絡を受けました。 なんでも攻撃される恐れのあるサイトですとかなんとか…。 ブラウザのスクリーンショットをもらってみたら、こんな表示が。 Google Chromeでも同じ感じのエラーメッセージが表示されていました。（サイト名が出るので省略…） Chromeの方のエラーメッセージをよく見ると、 NET::ERR_CERT_REVOKED と書かれています。ファッ！？証明書が失効している…！？ そんな馬鹿なと思い手元でアクセスしてみたら普通に繋がる…HTTPSできてるよ？なんで？何が起こってるんだろう…。 結論を言うと、 SSL証明書業者が手違いで中間CA証明書を失効させてしまった ことにより、私たちが購入して使っている証明書が一時的に利用不可能になり、そのネガティブキャッシュをユーザが参照している 、というお話でした。 解消のための新しい中間CA証明書が公開されていたので、そちらを使って更新してみると、問題は解消されました。 ただ、自社が買っていたのはクイックSSL証明書だとばかり思っていたので、更新に失敗しまくって時間がかかりました。違うやつだった…。 SSL証明書とかドメインの周りのメンテナンスは多くても年に数回とかっていう頻度なので、いろいろ思い出すのに苦労しますね。 ていうか、そういうことあるんですね、中間証明書間違って消しちゃった！とか。 レジストラのDNSサーバダウンと合わせて、「 うちのせいじゃないんだけどご迷惑をおかけしてごめんなさい案件 」って感じで覚えておきたい…。
続きを読む

[AWS] WAF を自分で組み立てるなら SAM でテンプレート書いた方が楽だよ

タイトルの通りです。 あ、 この記事は AWS初心者 Advent Calendar 2018 の7日目 として書いております。 最近会社でWAFとかLambdaとかSAMとかちょっとEC2やRDSといった基本のプロダクトとは違った要素について検証・導入を行なっているのですが、Lambdaをデプロイするために使ってみたSAMでWAFをデプロイすると楽ちんでした。 たとえばここに、HTTPリクエストのメソッドの種別を確認し、HEAD、CONNECT、TRACEを利用したアクセスをブロックするようなWAFを作成するためのSAMテンプレートがあります。 これが存在するディレクトリで以下のようにパッケージングのためのコマンドを実行します。 あ、念の為に雑多なディレクトリではなく、このテンプレートだけが存在する新しいディレクトリを作成してください。 aws --profile [プロファイル名] cloudformation package --template-file template.yml --s3-bucket [あらかじめ用意したS3バケット名] --output-template-file packaged-template.yml これを実行することで、SAMでのデプロイのためにパッケージング化された各種ファイルが指定したS3バケットに送られ、そこからデプロイするために書き換えられた packaged-template.yml が生成されます。 Lambda Functionのためのソースコードがあればここで併せてパッケージング化されるのですが、今回は無いのでtemplate.ymlだけですね。 そして以下のコマンドを実行するとデプロイされます。 aws --profile [プロファイル名] cloudformation deploy --template-file packaged-template.yml --stack-name otameshi-http-method-restriction-for-cloudfront --capabilities CAPABILITY_IAM --parameter-overrides yourApplicationeName=[任意の文字列] コマンド名に
続きを読む

[#CentOS][#Apache] CentOS6 でApacheが起動できない

CentOS 6 で httpd を起動させようとした時のこと $ sudo /etc/init.d/httpd start httpd を起動中: httpd: bad user name apache    [ 失敗 ] なんじゃこりゃ。 ■問題 Apacheが起動できない。問題はapacheユーザ ■原因 httpd.confには ユーザ：apache グループ：apache　でhttpdを起動するようになっている。 ユーザとグループを確認してみよう… $ cat /etc/passwd | grep apache $ ユーザが居ない… $ cat /etc/group | grep apache apache:x:48: グループはある。なんでこうなってんだ？ ■対処 ユーザ「apache」を作ってグループ「apache」に入れてあげよう。 # useradd -g apache apache useradd: /etc/passwd をロックできません。後でもう一度試してください。 は？(#ﾟДﾟ) # ll /etc/*.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/passwd.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/shadow.lock これを消すか # rm /etc/passwd.lock rm: remove 通常ファイル `/etc/passwd.lock'? y # rm /etc/shadow.lock rm: remove 通常ファイル `/etc/shadow.lock'? y これでもう一度apacheをuseraddして…あれ、もしかしてロックファイルがApahceをインストール剃る前からあって、もしかしてyumのインストールシーケンスの中でユーザ作成だけ失敗してたりしてるのかな？ ということでApacheをインストールし直す方向で。 # yum remove httpd $ sudo yum install httpd httpd-devel mod_wsgi Pythonの勉強したいからmod_wsgiも入れてます。 で、yum入りました。 Transaction Summary
続きを読む