読者です 読者をやめる 読者になる 読者になる

さかめも

株もやってるウェブエンジニア。月間80,000PV。田舎で生まれ、上京して7年。大手SIer→ウェブ系ベンチャー→フリーランス→スタートアップ創業期 を経験。お金持ちにならなくていいから好きなことをしたい。好きなことを続けるためにお金が欲しい。

なぜ AWS をやめて Heroku を選んだのか

f:id:sakagami5:20160724184953p:plain

仕事であるアプリケーション開発を担っているのですが、 当初 AWS を用いて1人で運用していたのが、現在は Heroku のプラットフォームに移行し、チームとして6人で開発を行っている状況になりました。そこに至るまでの経緯とその際の運用についてご紹介したいと思います。

もちろんそれぞれの開発の状況に応じて、判断は変わってくるかと思いますが参考になればと思います。

エンジニア 1人

f:id:sakagami5:20160724184441j:plain

もともと私が関わる以前のそこでの開発は外注していました。運用を引き受けることになったのですが、ある程度 形になっているアプリケーションを1人で運用するには不安が大きく、実装したい機能が日々 増えていく中で、インフラ面で時間をかけていて満足にコードを書けない状況は非常にわずらわしいものでした。小さなスタートアップという会社の中で、開発の施策が次々と進められない状況はまずいと感じ、Heroku の導入を検討しました。

実際に移行したことで感じたことは以下のとおりです。

初期コストが安い

Heroku は初期のコストが安く、Hobby プランなら $7 /month、Professional プランなら $25 /month 、DB はプランによって $9 /month、$50 /month 程度から使うことができます。

デプロイがお手軽

git push を行うだけで、デプロイ時に必要なプラグインのアップデート、コンパイルや圧縮など最低限必要なことは勝手に Heroku 側でやってくれます

外部ツールの導入がラク

New Relic や Papertrail などのツールがアドオンとして提供されているのでそちらを使っています。とりあえず試してみて、いらなかったらやっぱり消すということも最低限の手間で可能です。

f:id:sakagami5:20160724184501j:plain

エンジニア 3人

入社して数か月後、エンジニアが増えて1日のコミット数が増加し、優先度の高い施策は常時 改善が進められる状況になってきました。アプリケーションは日々大きくなり、SEOによる流入も増えてきました。

インフラ監視

アドオンで外部のツールを導入することも可能なのですが、あらかじめ使用メモリやレスポンスタイム、スループットなどがダッシュボードで確認できるようになっています。

※Dyno タイプが professional のときのみ

f:id:sakagami5:20160724184543j:plain

スケールアップが簡単

dyno を増やしたり、DBのスケールアップはダッシュボードやコマンドラインから行うことができ、例えばメディアに掲載されてアクセスが集中している1時間だけ dyno を100にして、また元に戻すことも瞬時に可能です。従量課金制なので請求額は使った時間分であり、無駄にコストがかかることはありません。

f:id:sakagami5:20160724184556j:plain

エンジニア 6人

エンジニア採用が進み、チームとして開発が回るようになってきました。いくつかのプロジェクトが並行して進むようになり、情報共有が活発に行われるようになりました。ナレッジが増え、経験豊富なメンバーがジョインすることにより、技術的なことについて誰かが知っていて相談したり、対応したりできる強いチームとなりつつあります。コミット数やリリース数が増加していく中で、作ることが先行していて質も維持していく必要性も出てきました。

ブランチ運用やテスト環境構築において、Heroku で提供している機能が非常に重宝しています。

Automatic deploys 機能

指定したブランチに変更が Push されると、自動的にデプロイされます。master ブランチにマージされると、ステージング環境に自動的にデプロイされるように設定しています。

f:id:sakagami5:20160724184619j:plain

Review apps 機能

Pull Request ごとにアプリケーションが展開されます。Pull Request を作成すると新しい環境が立ち上がり、Pull Request を閉じると自動的に消えます。各プロジェクトごとに動作確認環境を作成することができるため、たとえばデザイナーがデザイン修正を行って「こんな感じでいいですか?」と社内に共有するといった使い方もできます。

f:id:sakagami5:20160724184639j:plain

これらの機能を用いることで、以下の図のように Pull Request を立ち上げて、誰かにレビューを行ってもらい、デプロイするという GitHub Flow のブランチ運用ルールの中に、すっきりと開発環境を組み込むことができました。

f:id:sakagami5:20160724184653j:plain

最後に

実際にこれまで Heroku を用いて運用してきましたが、今のところ大きな不便はありません。しいて言うなら、サブティレクトリ以下に Word Press を設置したいという要望が実現できなかったというところでしょうか(サブドメインならできる)。少し外れたことをやろうと思ったら、他のソリューションを用いる必要性が出てくるかもしれませんが、普通にウェブサービスを運用していれば大抵のことは不自由なくできると感じています。

作ることが目的ではなく、ユーザーに価値を提供するうえで必要なときに必要に応じてプログラムを使いこなしていく段階の場合においては、Heroku のプラットフォームは手軽で、身動きがとりやすく早いです。もし不都合があれば Heroku から移行すれば良いだけなので、初期の段階では安価に手軽にウェブサービスをローンチできる Heroku という武器も検討してみるべきと感じました。

最後にイベントで登壇した際の資料も載せておきます。Heroku を検討している方の参考になれば幸いです。