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位の人たち以外)
  • あの問題やベンチマークツールを作るの大変だっただろうなぁ。運営の皆さまお疲れさまでした!