ISUCON6の予選にでて惨敗だった #isucon
今年も、ISUCONに挑戦した。チームは、社内のバックエンドチームの新卒2年目の二人とチームを組んで、予選に挑んだ。チーム名はファッションモンスター。
ざっくり、やることの分担としては、自分がしたまわりをやって、二人がアプリを改善していくということで進めていった。
予選の内容としては、マイクロサービス化されたwikiシステムで、はてなスター的なスター機能をもつものと、投稿のSPAM判定を行うブラックボックスなものの3つを上手く最適化させる必要があるものだった。
rubyの初期スコアが0点で、本当にゼロからのスタートで進めた。
方針としては、キャッシュできるところをキャッシュしまくっていこうということで、もろもろredisに乗せていったが、
結果的には、BESTでも6200点ぐらいしかでず、惨敗だった。
途中、gitがconflictしてしまって、雑にディレクトリごと切り替えてしまったせいで、サーバでgit pullしてるのに、意図しないエラーがでてるという状況に陥ってしまった*1
それを、切り戻すなどして時間をくってしまったり、unicornのログを最初出していないせいで、バグ取りが全くはかどらなかったりと、落ち着けばなんでもないことが、時間に焦ってしまってうまくできないなどあった。
敗因としては、本当の意味でのボトルネックを見つけきることができず、手持ちでやれることをミクロでやってしまったのが敗因だった。
手持ちの武器がcacheすればいいんでしょという感じで進めてしまったのも良くなかった。
twitterでの感想をよんでるかぎり、教養が足りず、そもそも戦えてなかったという感じだった..
あと、10時になって、さあスタートというタイミングで、業務のバッチがエラーはいたalertが飛んで、一瞬あせったということもあったりした。
ともあれ、今年も参加できて悔しい思いができたので、参加して良かったです。
出題、運営の皆様ありがとうございました!
また来年挑戦したいです。
ISUCON5の予選にでた #isucon
今年もISUCONに参加した。
転職したこともあり、去年までのメンバーではなく、社内で募集してチームを組むことができた。
フロントエンドエンジニア中心のチームとバックエンドエンジニア中心のチームの2チームで参加。自分以外は、初参加だった。
自分のチームは、バックエンドチーム(美女と野獣)でCTO、新卒女子、自分という構成で挑んだ。
当日やったこと
インフラレイヤーを主に担当して、
- nginx1.9.5への入れ替え
- css/js/fontをnginxで配信
- unix domain socketでのunicornとの接続
- LTSVファイルでログを出力 -> alp にくわせてざっくりアクセスされる箇所を洗い出し
- mysqld.confの調整
nginx でgzip をonにするとcssのlengthが0になってbenchmarkがfailするのになかなか気づかず、時間をくったり、おもむろにhttp2をhttpレイヤーで有効にしてしまって、ブラウザで確認するとつねにdownloadするモードになったりと、地味なつまづきがつらかった。
Ubuntuという指定はレギュレーションにあったものの、systemdに慣れていなさすぎて、どうやって再起動するんだとか、restartでやっていてbenchmarkとおっていたのに、stop &start したら↑のgzipとかhttp2とかがおきるようになってなにが悪いのか判断に時間がかかってしまったりしてしまった。
proxy-cacheを有効にして、stop&startしたら、downloadする件がでてしまって、それ消してるのに治らないとなって、proxy-cacheは関係ないのにパニックになって時間がかかったりもした。。。
あと、/etc/my.cnf でslow-query確認しましょうとなって、設定変更しても、何も出ず、そもそも/etc/my.cnfは読まれていなかったとかもあって*1、経験不足が出てしまった感じだった。
アプリレイヤーは、チームメンバーにまかせていたものの、initializeのあつかいで、とまどいがあったり、別のインスタンスで動かしつつgitで管理するみたいなことに、時間を取られたりしていて、ISUCON慣れみたいなもののあるなしが出てしまった感じだった。
18時過ぎぐらいまでで、ほぼほぼインフラレイヤーの変更のみがいきているような状態だったけど、アプリの改善を自分とCTOとでツーマンセルのような状態で進めていったらスコアが伸びていったので、完全なる作戦ミスだった。。
最終的に一番スコアがでたのでも4909だったので、初期スコアからは伸びたもの、トップとは5倍ぐらい差がでてしまっているので、悔しさしかない。
ベンチツールが公開されたら、もう一度チャレンジしたい。
GCPはbigqueryは普段からさわっているものの、GCEははじめてだったけど、さくっと使えるのはよさそうだった。gcloud sdkでssh接続するときの挙動が謎すぎて何が起きているんだという感じもあるけれど。。
ともあれ、運営のみなさま、出題者のみなさま、ありがとうございました!
WordPress を nginx + hhvm + mariadb 環境で構築した
TL;DR
妻のバンドのサイトのWordPressが重すぎてつらいということだったので、サーバを移行するついでにもろもろ詰め込んでみた
既存環境
- heteml サーバ
- MySQL5.0.8
- PHP5.4
構築
高速化
- nginx-proxy-cache設定してwordpress のfrontendをcache
- hhvmをいれたので、nginxからhhvm-fastcgiでbackendとする
- WordPressを最新バージョンへ
- nginx-proxy-cacheをpurgeしてくれるpluginを導入 https://wordpress.org/plugins/nginx-cache/
nginx conf
- proxy-cacheの設定を追加
- proxy-cacheの設定を追加
- hhvm.conf はデフォルトのまま
所感
*1:原因は不明のまま
Yosemiteにupdateしてhttpdとvagrantが上がらくなって肝を冷やしたはなし
Yosemiteがリリースされたのでカジュアルにアップデートしたらhttpdとvagrantが上がらなくなった。
Yosemiteにupdateしたらlocalのhttpd があがらなくなってあせった・・
— Takumi Kanzaki (@tknzk) 2014, 10月 19
あと、vagrant up できなくてしぬところだった
— Takumi Kanzaki (@tknzk) 2014, 10月 19
virtual boxの再インストールと brew tap homebrew/apache && brew install httpd22 で取り急ぎの解決はできたっぽい
— Takumi Kanzaki (@tknzk) 2014, 10月 19
ISUCON4の予選に出た #isucon
ISUCON4 の予選に出た。
今回は、去年のチームメンバーのid:urapico とフロントエンドエンジニアのnkns の3名体制で臨んだ。
セットアップ
- テーブルを移動して、テレビをセカンドディスプレイとして使うセッティング
本日のISUCON会場 #isucon pic.twitter.com/DWxOsEfEWH
— ルミエ (@lumie007) 2014, 9月 27
集合
- 9:30 idobataに集合
開始
- 10:00 スタート
- 公開されたAMI でEC2インスタンスを起動
- 各自ssh でログインしてもらう
- id:urapico がソースをbitbucketにpush
- PHPに切り替える
- 502 BadGateway
- 時間がもったいないということでRubyでいく宣言
- ざっくりソースを読む
- DBへのアクセスをどう減らすかだねっていう話をする
作戦会議
- 役割分担を決める
- インフラを自分がみる
- アプリ側をurapicoとnknsに担当してもらう
PHPに変更
改修内容
- my.cnf を改修
- mysql slowlog を確認
- index を追加
- users table にlast_logined_at, last_logined_ipを追加
- mypageで参照される 最終ログイン時間、最終ログインIPをlogin_log を見ないように改修
- redis, phpredis 導入
- banned_ip, blocked_user をredisにキャッシュ
- last_logined_ip の部分のチェックでエラーとなったため、チェックロジックを妄想
- 一つ前のlogined_ip を持ってる必要があるとふんで改修
- エラー除去
- passwordのhash 計算の部分にcacheを導入
結果
- デフォルトスコア 1300ぐらいから8000ぐらいにはアップできた
- 惨敗
感想
- 上位スコアには5~10倍の差を付けられていて大変厳しい現実・・
- benchmarkツールのバグ等もありながら、運営の皆様お疲れ様です。ありがとうございます!!
- 着実に負荷部分の実装をがりっと書き換えるもしくは飛び道具を持つということができないと厳しいなあ
- ともあれ、チームで参加できたし、勉強になったのでよかった!
運営の皆様、ありがとうござました!
heroku legacy-routingの対応をした
tknzk.com をheroku でホスティングしているわけですが、
そのDNSの設定を、herokuが持っているIPでAレコードをしていました。
そのIPで設定する方法は、今後停止する予定だから対応してというメールが来たので対応をした。
This is a reminder that Heroku is turning off the legacy routing path on September 22nd 2014. This is part of an effort to standardize on a single, fast, highly available and scalable routing stack for all customers.
herokuで利用しているサービスでこのlegacy-routingを使っているかどうかは、
https://legacy-routing.herokuapp.com/を参照すれば確認できる。
具体的には、もともとのherokuappのドメイン xxxx.herokuapp.comをCNAMEに割り当てればOKなのだけれど、利用していたムームードメインのムームーDNSがroot domainに対してCNAMEを設定できない仕様だった。いい機会だったので、AWS Route53にネームサーバを移行した。
Route53 もroot domainの CNAMEは未対応なのだけれど、AWS S3のWebHostingのRedirectをつかって処理した。
- tknzk.com -> S3 web-hosting 301 redirect
- tknzk.com Alias S3 web-hosting on Route53
- www.tknzk.com -> CNAME (xxxx.herokuapp.com)
AWSのWebConsole からポチポチ設定して、完了。
参考URL
Configuring Amazon Route 53 DNS for your Heroku App | Heroku Dev Center