我选择将Heroku迁移到AWS的原因和方法

3 年 ago

逸, 科

1 minute

总结

我們在Heroku上運營了一年多，現在決定在年底轉移到AWS上。在回顧這一年後，我將寫下關於Heroku和AWS的優點和缺點，以及我們決定轉移到AWS時將採取的運營方式。

有三个主要的部分。

私達が取り組んでいるのが、画像を多く取り扱うサービスだということもあります。特にサムネイル作成については苦渋を飲まされました。以下の記事に知見を纏めています。

RailsとHeroku、AWSでAwesomeな画像アップロードからのサムネイル作成
RailsとHeroku、AWSで画像アップロードからのサムネイル作成（実践編）

ただこの知見はHeroku特有のものも多く、AWSであれば容易に解決できた部分もあります。それが今回移行する理由の一つです。

リージョンによる遅延

1つめのようにどうにかこうにか対策できる部分もあるのですが、リージョンの問題（HerokuはUSとEUにしかリージョンが無い）ことです。Tokyoリージョンが使えないのは、多くのリクエスト、大きい転送量が上下ともに発生する画像系のサービスでは大きな損失です。（ベンチを取ると分かりやすかったです）

無料範囲で済まなくなると、結構お高く付く

逆而令我高兴的事有以下两个方面。

1 dynoまで無料

ぽんぽんステージング環境を立てて確認できる（最近はforkコマンドが出来て非常に楽になりました）のは高速開発にはとても便利です

pushするだけでデプロイ

何も考えずpushするだけでデプロイできるのは、環境構築のコストが抑えられて非常に便利です
また最近はGitHub-Syncという機能が出来て、指定したGitHubのmasterに入るだけでデプロイを走らせられるようになりました

アドオンがたくさんある

MongoもMemcacheもNew Relicもボタン一つ、コンソール1コマンドですぐに使うことが出来て非常に楽です

何も考えなくて良い

デプロイもそうですが運用もほぼ何も考えずに、負荷が増えたらdynoを増やしたり、DBもスケールアップしたり、金を詰めば何も考えずとも動かし続けられます

我打算将服务从Heroku迁移到AWS，但在选择使用哪个服务进行运营方面有些犹豫。最终的结论是，由于在Heroku上仅运营了一些小型服务，所以用EC2来进行耐心地操作已经足够了。

另外，服务的构成如下所述，包括EC2和客户端访问的S3，以及客户端和S3之间的CloudFront。

客户 <-> 负载均衡器 <-> EC2 <-> RDS

以下是我們考慮過但最終決定不使用的服務。

外見は一番Herokuっぽいのですが、インスタンス単位で立ち上がるのでお金がたくさんかかったり、立ち上がるのに非常に時間がかかります
ダウンタイム無しのローリングアップデートをしようとしたけれど、設定の調整が面倒

AWSの挙動を確かめながら設定するのが非常に面倒でした

DevOps

レシピを追加するのに時間がかかる
元々のレシピの挙動を確認しながら修正を加えるのが面倒

CloudFormation

そもそも必要なかった

我正在努力自行搭建环境，并使用EC2和Chef进行配置，然后使用Capistrano进行部署。