おいぬま日報: 10月 2013

2013年10月20日日曜日

標準出力・標準エラー出力をキャプチャするPythonのライブラリを作った

https://pypi.python.org/pypi/iocapture

PerlでいうCapture::Tiny みたいなやつのPython版が欲しかったので作ってみた。Python3にも対応させた(つもり)。

ここ3ヶ月で取り組んだ技術とか

去年から新規のソーシャルゲームの立ち上げのヘルプをしていて、つい最近も1つリリースした。リリースも何とか無事に終わりデスマも落ちついたので、ここ3ヶ月ぐらい主に仕事で使ってきた技術をここらでまとめておこうと思う。

Java

うちの会社はサーバサイドの言語はJavaかNode.js(JavaScript)が多い。自分がたずさわっているプロジェクトはJava。正直Javaなんて面倒なんでやめたいんだけど、これ使えばけっこう開発が楽になる、っていう技術が2つ。

JRebel

いわゆるホットリローディングを実現してくれるソフトウェア。IDEに組み込んで使う。該当クラスのソースを編集すると自動的にクラスを再ロードしてくれる。有償製品だけどJRebel Socialなんていう謎なライセンスで無料で使うことができる。

Lombok

会社のブログに概要を書いたので見てくらはい。

NewRelic

パフォーマンス解析ツール。負荷テストをしながらNewRelicを使ってどこがボトルネックかを調査した。任意のURL(に対する処理)を一定時間プロファイリングするX-Rayっていう機能が便利だった。ただNewRelicの全機能の10%も使ってないと思われる。

Vagrant

うちの会社はChefでサーバ構築するようになってきていて、自分もやっと真面目にChefに取り組んでみた。VagrantはChefのレシピをテストするのに使っていた。

$ vagrant up
$ vagrant provision

で cookbooks がゲストOSに転送されてchef-soloが実行される。すごいシームレスに統合されていてすごいなぁと思う。ドキュメントもしっかりしていて特に躓くこともなかった。

Fabric

Python版のCapistranoみたいなやつ。最初はShellScriptでディプロイスクリプトを書いていたんだけど、複雑な処理をやらせるにはちょっと役不足だったので、代わりにこれを使った。@parallel っていうデコレータつけるだけでタスクが並列で実行されるのがよい。

Grunt

最近流行っているnode.js製のJavaScript関連のタスクランナー。JavaScriptのminifyとかconcatするのに使った。

ChatWork

Skypeの代わりにこれを使っていた。ただ正直Skypeの方が好きだ。HipChatはいつか試したい。

IntelliJ IDEA

JavaのコードはEclipseで書いてたんだけど、PythonやRubyのコードはIntelliJで書いてる。ちょっと設定するだけで補完が利くようになるのがいい。

2013年10月7日月曜日

#isucon の予選に出場して惨敗してきた( ｰ`дｰ´)ｷﾘｯ

@la_luna_azul さんと@oranie さんとでISUCON1日目に参戦してきた。結果から言うとトップと約8倍差がついて惨敗10位ぐらいには入れるかなーと思ったけど考えが甘かったし、準備も実力も足りなかった。

準備

bitbucketにプライベートリポジトリ作って、そこのWikiに事前にやったほうがいいことなどをまとめたりした。
必要そうなRPMを事前に作ってもらった

やったこと

言語はPythonを選択
- Python 3.3.2が使われていたのが予想外だった
ソースはすべてbitbucketのプライベートリポジトリに突っ込み、簡単にディプロイするようにした
最初の方はset global general_log =ONにしたり、mysqldumpslowやapachetopで傾向を把握
memcachedが11212で立ち上がっていたので、アプリからmemcachedへの向き先のポートを変えた
my.cnfのチューニング
- クエリキャッシュ多め
- あとは一般的なチューニング
SELECT username FROM users WHERE id = ? みたいなクエリが多かったのと、userのレコード数が400だったので、usernameをアプリ起動時に全件取得してmemcachedに全て突っ込むようにした
- Flaskには @before_first_request なんていう便利なデコレータがあることをこの時初めて知る
memosのuser, created_atにインデックスが貼ってなかったのではった
- 複合インデックスより個別にインデックスを貼ったほうがなぜか速かった
- ただしbenchコマンドを実行するとテーブルが初期化されることに14時ぐらいまで気付かなかったorz
静的ファイルをApacheで返すようにした
- 最後にはnginxに変更。ただしスコア的には変わらず
SELECT count(id) AS c FROM memos WHERE is_private=0 みたいなカウントをmemcachedに突っ込んだ
自家製のスクリプトを使って下記のようにどのURLが全体として遅いのかを把握
MarkdownをHTMLに変換する処理がbin/markdownコマンドをサブプロセス起動で行っていたので、これをPythonのMarkdownモジュールを使って変換するようにした。結局、これが一番スコアに効いた
SELECT COUNT(*) しているところを SELECT COUNT(id)に変えた
SELECT * FROM users WHERE id=? をキャッシュするようにした
NewRelicのインストールを試みるもうまくいかず頓挫
SELECT * FROM memos WHERE is_private=0 ORDER BY created_at DESC, id DESC LIMIT 100 みたいなクエリがあったので、created_atとidをASCでソートできるように逆順カラムを作った。ただしこれは最後のほうにbenchmarkコマンドでFAILしたので諦めた
geventをインストールしようとするも頓挫
gunicornのworker数の調整

反省点

事前の打ち合わせで @la_luna_azul = フロント回り、@oranie = データベース回り、@oinume = アプリ回りと役割を分担してしまっていたため、「その時の最大のボトルネック」を直すことより各々で担当領域のことをやってしまっていた。ボトルネックを全員で全力で解決するアプローチのほうがこういうケースだと良かったのでは？と反省会で話していた。
EC2のインスタンスを3人分作ってやっていたので、おのおのが行ったサーバの設定変更などを反映させるのに無駄に時間がかかってしまった。本番環境とテスト環境、の2つぐらいで良かったのでは？と思う。
「このURLが遅いしアクセス数も多い」みたいなことまでしか把握せずに、アプリケーションのどこがボトルネックかを正確に追ってなかったので、効果が高いチューニングをあまり行えなかったような気がする
Markdownのサブプロセス問題に気付いたのが14:00ぐらいだった。最初からソースを全部読んでいればもっと早くここは直せたように思う。
NewRelicインストールできなかった

感想

自分の力のなさがわかっただけでも参加した甲斐があった
コードの修正は意外と早くできたので、もっと怪しい箇所のあたりをつけるのを的確にできるようになりたい(ので修行します)
正攻法では突き抜けたスコアは出ないだろうなぁと思ったけど意外とそうでもなさそうだった(1, 2位の人たち以外)
あの問題やベンチマークツールを作るの大変だっただろうなぁ。運営の皆さまお疲れさまでした！

おいぬま日報