概要
Herokuで1年以上運用して、年内にAWSへ移行することとなりました。年末ですしそれを振り返って、HerokuとAWSの良い所・悪い所、AWSへ移行するにあたりどのような運用をすることに決めたか書きます。
HerokuからAWSへ移行を決めた理由
大きく3つあります。
- プロセスの実行に制限があったり、リソースに制限があるのが辛い。
- 私達が取り組んでいるのが、画像を多く取り扱うサービスだということもあります。特にサムネイル作成については苦渋を飲まされました。以下の記事に知見を纏めています。
- ただこの知見はHeroku特有のものも多く、AWSであれば容易に解決できた部分もあります。それが今回移行する理由の一つです。
- リージョンによる遅延
- 1つめのようにどうにかこうにか対策できる部分もあるのですが、リージョンの問題（HerokuはUSとEUにしかリージョンが無い）ことです。Tokyoリージョンが使えないのは、多くのリクエスト、大きい転送量が上下ともに発生する画像系のサービスでは大きな損失です。（ベンチを取ると分かりやすかったです）
- 無料範囲で済まなくなると、結構お高く付く
逆に嬉しかったことは大きく以下の2つです。
- 気軽に開発できる
- 1 dynoまで無料
- ぽんぽんステージング環境を立てて確認できる（最近はforkコマンドが出来て非常に楽になりました）のは高速開発にはとても便利です
- pushするだけでデプロイ
- 何も考えずpushするだけでデプロイできるのは、環境構築のコストが抑えられて非常に便利です
- また最近はGitHub-Syncという機能が出来て、指定したGitHubのmasterに入るだけでデプロイを走らせられるようになりました
- アドオンがたくさんある
- MongoもMemcacheもNew Relicもボタン一つ、コンソール1コマンドですぐに使うことが出来て非常に楽です
- 1 dynoまで無料
- 何も考えなくて良い
- デプロイもそうですが運用もほぼ何も考えずに、負荷が増えたらdynoを増やしたり、DBもスケールアップしたり、金を詰めば何も考えずとも動かし続けられます
AWSではどのサービスを使うのか
HerokuからAWSへ移行するのですが、どのサービスを使って運用するかで悩みました。結論としては、Herokuで小さく運用していたサービスだったので、EC2で地道にやるので十分でした。
なおサービスの構成は以下に追加で、EC2とClientからアクセスされるS3と、ClientとS3の間に入るCloudFrontがあります。
Client <-> ELB <-> EC2 <-> RDS
以下は検討したけれど、結局使わないこととなったサービスです。
- Elastic Beanstalk
- 外見は一番Herokuっぽいのですが、インスタンス単位で立ち上がるのでお金がたくさんかかったり、立ち上がるのに非常に時間がかかります
- ダウンタイム無しのローリングアップデートをしようとしたけれど、設定の調整が面倒
- AWSの挙動を確かめながら設定するのが非常に面倒でした
- DevOps
- レシピを追加するのに時間がかかる
- 元々のレシピの挙動を確認しながら修正を加えるのが面倒
- CloudFormation
- そもそも必要なかった
結局
地道に自分で組んでいって、EC2とChefで環境構築をし、Capistranoでデプロイしていくように組んでいっています