いこーよ を Amazon Web Service (AWS) に移行しました。 御蔭様でいこーよのアクセス数は伸びてきており、これで3回目の引越しです。
移行に際して一番悩んだのがオートスケールを前提としたデプロイ、監視でした。 オートスケールの設定をしている場合、インスタンスは負荷に応じて起動したり削除されたりします。 当然 IP アドレスも都度変っていきます。
- cap production deploy:migrations する時に生きているサーバはどれ?
- オートスケールでインスタンスが起動した時、ちゃんと最新のソースで起動するにはどうする?
- munin でリソース監視したいけど、監視対象サーバはどれ?
といったところが、全くわかりませんでした。 世のオートスケール利用者の方々はどうされているんでしょうか。
いろいろ試行錯誤し、結局のところ次のようにしました。
- unicorn を passenger に変更
- unicorn に問題があったわけではありません。
- cap は DB サーバにのみ行う。
- passenger が動くアプリサーバは DB サーバのデプロイディレクトリを nfs マウント。
これでデプロイは DB サーバに対してだけ行えばよく、アプリの再起動も DB サーバで touch tmp/restart.txt を行えば、それを nfs マウントしているアプ リサーバの passenger がみんな再起動する、という仕組みです。
munin の方はうまい方法を思い付かなかったのでシェルスクリプトを書きました。 DB サーバは Elastic IP を使っているのでホスト名が固定です。 ec2-describe-instances の出力から DB サーバを除いて起動しているホスト名を取得し、 /etc/munin/munin.conf を都度生成します。
#!/bin/sh export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-i386 export EC2_HOME=/opt/ec2-api-tools export PATH=$EC2_HOME/bin:$PATH export EC2_PRIVATE_KEY=/foo/pk-KKKKKKKKKKKK.pem export EC2_CERT=/foo/cert-XXXXXXXXXXXXXXX.pem export EC2_URL=https://ec2.ap-northeast-1.amazonaws.com ec2-describe-instances --show-empty-fields | \ sed -n '/^INSTANCE.*running/p' | \ sed -n '/54-248-122-232/!p' | \ awk '{ print $4, $5; }' | \ sed -e '=' | \ sed -e 'N;s/\(.*\)\n\(.*\) \(.*\)/[iko-yo.net;ap\1]\n address \2\n use_node_name yes\n/' > /tmp/aws-munin.conf.tmp sed -e '/KOKO/r /tmp/aws-munin.conf.tmp' -e '/KOKO/d' /etc/munin/munin.conf.template > /etc/munin/munin.conf
/etc/munin/munin.conf.template はこんな感じ。
...前略... # DB サーバ [iko-yo.net;db.iko-yo.net] address db.iko-yo.net # アプリサーバ KOKO ...後略...
さて DB サーバ m1.large x 1, アプリサーバ c1.medium x 1 で本番投入してみたのですが、DB サーバが重い。 その夜急遽 DB サーバを c1.xlarge に変更。 c1.xlarge にしたらリソースが余ったで、アプリも DB サーバで動かして c1.medium のアプリサーバ停止。 という構成になりました。
きっと GW か夏休みのピークにはオートスケールの出番が来るかと思います。
ちなみに最近のピーク時のアクセスは nginx のリクエスト数でいうと 90 request/second で New Relic の Throughput でいうと 770 rpm くらいです。 はやく DB の全件 like 検索しているのをなんとかしたいところです。
最後に、弊社ではシステムエンジニア、プログラマ、インフラエンジニアなどを募集しています。 お気軽るにお問い合わせください。
