真・Amazon Web Service (AWS) でサービスをデプロイしてみた
先般、長らく放置気味だった勤務先の技術 blog で「Amazon Web Service (AWS) でサービスをデプロイしてみた」を書いた。ただ、実際に嵌ったりしたものの、諸般の事情で FFTT では書けなかったこともあるので、こちらで書いておきたい。
Table of Contents
インストール時や初回設定時の問題
RightScale の CentOS 6 AMI は割と(ry
そもそもデフォルトの状態では EBS だと t1.micro でしか起動せず、m1.small 以上にすると PyGRUB で止まってしまう。どうやら仮想ディスク内でパーティションを 3 つ以上切るとダメのようで、別インスタンスでスワップパーティションを潰してしまえば m1.small で起動するようになる。
自前の AMI を作りたい
本当に必要? 他の AMI を流用するより速い?
EBS でルートパーティションを増やしたい
ルートパーティションを増やす場合は、Xen や KVM でやるのとほぼ同じ手順でやればよい。
- 別途大容量の EBS を作成する。
- 別のインスタンスに新規作成した EBS と拡張したい EBS の双方をアタッチする。
- ddでまるっとコピーする。
dd -if=/dev/xvdf -of=/dev/xvdg
- fdisk で末尾のパーティションを削除し、そのまま最大容量でパーティションを切り直す。
- resize2fs する。
fsck.ext4 -f /dev/xvdf2
resize2fs /dev/xvdf2 - 元のインスタンスにアタッチしなおす。
- 起動して問題ないことを確認。
NAT インスタンス + ELB の場合の ELB の設定
NAT インスタンスと ELB を併用しており、かつ NAT インスタンスとバックエンドが違うサブネットにある場合は NAT インスタンスのあるサブネット上に ELB を配置する必要がある。バックエンドと同じサブネットにしていると ELB がタイムアウトする。
t1.micro を VPC に入れたい
不可能。
EC2 を後から VPC に入れたい
そのままでは不可能。一旦 AMI に落とした上で、再度インスタンスを作りなおす。
ELB で SSL 運用は可能?
可能。ELB 側とバックエンドの双方に SSL 証明書を適用すればよい。
運用上
ELB の死活監視パラメータ
ELB の死活監視を L7 レベルで実施する場合、特定の URL を定期的に取りに行って指定の回数以上タイムアウトしたりすると対象のバックエンドを切り離す。この取得間隔は最短で 6 秒、タイムアウトは 2 秒、2 回以上連続失敗だが、全て最短にすると若干問題になるケースがある。具体的には capistrano などで全ての Web サーバやアプリケーションサーバを再起動した場合などの場合、m1.small だったりするとアプリケーションサーバの初回起動で20秒以上かかったりする (m1.small で nginx + Passenger 3 + ruby 1.9.3 + Rails 3 の場合) ので、全てのバックエンドが切り離される悲劇が発生する。1 台ずつ再起動するなりする必要がある。
インスタンスごとにデーモンの監視したい
CloudWatch に食わせるスクリプトを書くか、素直に ZABBIX なり Nagios なりを入れるといい。
RDS で複数のデータベースを運用したい
MySQL の CREATE DATABASE
的な話であれば可能。新規作成時に入力する DB 名、ユーザ名はあくまで初期に生成されるというだけなので、後から CREATE/GRANT
すればよい。
RDS だけど別途バックアップは必要?
データの運用ポリシー次第。
強制的に https にリダイレクトしたい
ELB ではできないのでバックエンドで。
その他
社内で Gentoo Linux の布教に失敗している
だがしかし、検証環境をホストしている KVM 機およびデザインチェック用のインスタンスには Gentoo Linux を採用した。
社内で検証環境を作りたいけど ELB は?
nginx でも Apache でも何でも好きなリバースプロクシを使えばよい。弊社は nginx で ELB を模擬している。