ISUCON6の予選にでて惨敗だった #isucon

今年も、ISUCONに挑戦した。チームは、社内のバックエンドチームの新卒2年目の二人とチームを組んで、予選に挑んだ。チーム名はファッションモンスター。
ざっくり、やることの分担としては、自分がしたまわりをやって、二人がアプリを改善していくということで進めていった。

予選の内容としては、マイクロサービス化されたwikiシステムで、はてなスター的なスター機能をもつものと、投稿のSPAM判定を行うブラックボックスなものの3つを上手く最適化させる必要があるものだった。

rubyの初期スコアが0点で、本当にゼロからのスタートで進めた。
方針としては、キャッシュできるところをキャッシュしまくっていこうということで、もろもろredisに乗せていったが、
結果的には、BESTでも6200点ぐらいしかでず、惨敗だった。
途中、gitがconflictしてしまって、雑にディレクトリごと切り替えてしまったせいで、サーバでgit pullしてるのに、意図しないエラーがでてるという状況に陥ってしまった*1
それを、切り戻すなどして時間をくってしまったり、unicornのログを最初出していないせいで、バグ取りが全くはかどらなかったりと、落ち着けばなんでもないことが、時間に焦ってしまってうまくできないなどあった。

敗因としては、本当の意味でのボトルネックを見つけきることができず、手持ちでやれることをミクロでやってしまったのが敗因だった。
手持ちの武器がcacheすればいいんでしょという感じで進めてしまったのも良くなかった。
twitterでの感想をよんでるかぎり、教養が足りず、そもそも戦えてなかったという感じだった..

あと、10時になって、さあスタートというタイミングで、業務のバッチがエラーはいたalertが飛んで、一瞬あせったということもあったりした。

ともあれ、今年も参加できて悔しい思いができたので、参加して良かったです。

出題、運営の皆様ありがとうございました!
また来年挑戦したいです。

isucon.net

*1:違うディレクトリにpullしてた

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 sdkssh接続するときの挙動が謎すぎて何が起きているんだという感じもあるけれど。。

ともあれ、運営のみなさま、出題者のみなさま、ありがとうございました!

isucon.net

*1:/etc/mysql/mysql.conf.d/mysqld.cnf が読み込まれていた

WordPress を nginx + hhvm + mariadb 環境で構築した

TL;DR

妻のバンドのサイトWordPressが重すぎてつらいということだったので、サーバを移行するついでにもろもろ詰め込んでみた

既存環境
  • heteml サーバ
  • MySQL5.0.8
  • PHP5.4
新環境
構築
  • さくらのVPSのカスタムOS インストールでUbuntu 14.04 をインストール
  • もろもろ必要なミドルウェアを apt-getでいれる
  • 旧環境のMySQLのengineがMyISAMだったのでdumpしたsqlファイルを書き換えてInnoDBに変更
  • テンプレートファイルや画像ファイルなどは旧サーバからまるっと移行


ubuntu nginx mariadb hhvm

高速化
nginx conf
  • proxy-cacheの設定を追加


gist1a3453c11f667eca32a1

  • proxy-cacheの設定を追加


gist7bdc8e2e240e05ac6da0

  • hhvm.conf はデフォルトのまま


gist9c5af01c27dbb59e4e37


f:id:tknzk:20150208162511j:plain

所感
  • WordPressつらいので、他の静的なhtmlを書き出すツールへの移行も考えたが、更新のしやすさと慣れの面と既存データの問題でWordPressのままいくことにした
  • Ubuntuほぼはじめてで、コマンドが慣れなかったけど、さくっと構築出来たのでよかった
  • hhvmがCPUを食いつくす現象が構築時にあったけどrestartしたらおさまった*1
  • 旧環境はMyISAMだったのでそこで刺さってたようす

*1:原因は不明のまま

Yosemiteにupdateしてhttpdとvagrantが上がらくなって肝を冷やしたはなし

Yosemiteがリリースされたのでカジュアルにアップデートしたらhttpdvagrantが上がらなくなった。

  • vagrantはvirtual boxの最新版をインストールして解決
  • httpdbrewhttpdをインストールして解決 *1



gist4a262686e3bd3b2f996e


gist386bc90923b3bea56827



*1:httpdbrew tap homebrew/apache してから入れなおし

ISUCON4の予選に出た #isucon

ISUCON4 の予選に出た。

今回は、去年のチームメンバーのid:urapico とフロントエンドエンジニアのnkns の3名体制で臨んだ。

セットアップ
  • テーブルを移動して、テレビをセカンドディスプレイとして使うセッティング


  • AWSクーポンを投入 *1
集合
  • 9:30 idobataに集合
開始
  • 10:00 スタート
  • 公開されたAMI でEC2インスタンスを起動
  • 各自ssh でログインしてもらう
  • id:urapico がソースをbitbucketにpush
  • PHPに切り替える
  • 502 BadGateway
  • 時間がもったいないということでRubyでいく宣言
  • ざっくりソースを読む
  • DBへのアクセスをどう減らすかだねっていう話をする
作戦会議
  • 役割分担を決める
  • インフラを自分がみる
  • アプリ側をurapicoとnknsに担当してもらう
PHPに変更
  • 運営のヘルプスレッドをみていたら、PHPの話がでていたので、それを参考に再度PHPで動かしてみることに
  • supervisor.conf を書き換えて、instance reboot
  • 動いた!
  • foremanが起動していて、初期実装のRubyが8080に居座っていたのが原因だった orz
改修内容
  • 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ツールのバグ等もありながら、運営の皆様お疲れ様です。ありがとうございます!!
  • 着実に負荷部分の実装をがりっと書き換えるもしくは飛び道具を持つということができないと厳しいなあ
  • ともあれ、チームで参加できたし、勉強になったのでよかった!

運営の皆様、ありがとうござました!

http://isucon.net/

*1:AWS様ありがとうございます!

iTunesのランキングをつぶやく

妻のバンドがiTunesで曲をリリースして、そのランキングを追いたいという要望を受けて、簡単な実装をしてみた。

iTunesのランキングは、RSSappleが配信しているので、それをパースして、tweetする仕組みになっている。当て込みで作ってるので、だいぶアレな実装になってるけど、これをherokuにdeployして、heroku scheduler で叩くと、つぶやいてくれる。

$ bundle exec ruby iTunes-ranking-tweet.rb


gist413e1c104c7f6a98c792

rakurai

rakurai

  • YAPANI!
  • Jazz
  • ¥200

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