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

さかめも

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

Rails アプリのインフラを AWS から heroku に移行した話

heroku Ruby on Rails

f:id:sakagami5:20150503232052p:plain

先日、自分の携わっている Rails アプリのインフラを AWS から heroku に移行しました。

移行時にハマった点や、その後 使い始めてみて便利だった点を列挙。

移行した主な理由としては、開発が少人数体制のためインフラは気にせずコードを書くことにのみ集中して、限られたリソースを有効活用させるため。

また、移行するにあたり以下のスライドも参考になりました。

移行時の手順・ハマったところ

基本的な手順

基本的な手順は簡単。

Heroku Toolbelt をインストールして、

heroku login

でログイン、

heroku create

で heroku 上に新しいアプリケーションを作成した後、

git push heroku master

で デプロイ。

heroku open

とやると、ブラウザが立ち上がり、ページが見られる。

データベース

データベースは heroku 標準の Heroku Postgres を利用。

既存では MySQL を使っていたため、今回は SQL を出力するバッチを組んで、 生成した SQL を新しいDBに流し込み。

Heroku Postgres の Hobby Dev というプランで、1万レコードまで無料なのでそこで検証できる(1万行を超えても 1週間後に書き込みが制限されるだけらしい)。

うまく流し込みができたら、有料プランで新しい production 用のDBを申し込んで検証DBから production用DBへデータコピーするといったこともコマンド一発で可能。

ルートドメインとSSLの設定

heroku のアプリケーションに独自ドメインの設定をする際、www のようなサブドメインがついたURLを設定するのが一般的。

ネームサーバーの設定だけで比較的簡単に設定することができる。

しかし、サブドメインがつかない形であるルートドメインを設定する場合は、ネームサーバーの提供するリダイレクト機能で、ルートドメインからサブドメインがついたURLにリダイレクトさせる方法か、ALIAS や ANAME といった CNAME 風にルートドメインを扱うことのできるレコードをサポートをしているDNSを使う必要がある。

前者のほうが比較的簡単だが、SSLを使う場合はうまくいかないため、 今回は後者の方法で行った。

(参考)Custom Domain Names for Apps | Heroku Dev Center

ちなみに公式では DNSimpleDNS Made Easy を推奨。

国内のサービスでは DozensGehirn DNS で設定できることが確認できた。

ただし、 Dozens は12レコードまで無料で、ルートドメインで CNAME を設定することで heroku のアプリケーションに対してドメイン設定できることが確認できたが、ルートドメイン で CNAME を設定することは RFC で認めておらず 推奨されている使い方ではないもよう。

Gehirn DNS は CNAMEに似せて指定された参照先の情報を自動的にコピーする「Apex Alias」を使うことで ルートドメインの設定を実現可能。

ちなみに従来の Gehirn DNS は、来年の2月末日でサービスが終了となる予定で、 新しい Gehirn DNS がパブリックプレビューで利用できる。

ファイルアップロード

画像ファイルなど、アプリケーションからアップロードされたファイルは dyno 再起動時に消えてしまうため、 永続化させるためには外部のストレージ(AWS S3 など)に保存する必要がある。

(参考)Direct to S3 Image Uploads in Rails | Heroku Dev Center

heroku の便利なところ

DBのバックアップが簡単

heroku 標準の Heroku Postgres なら、定期的にバックアップをとる設定や、バックアップデータから新しいデータベースにリストアすることもコマンド一発で可能。

staging 環境用にもうひとつDBを立ち上げてデータをコピーしたいというニーズも瞬時に対応できる。

ステージング環境の構築が簡単で安い

最小限の手間で同じアプリをいくつも作れて、無料枠の範囲内で使えばコストもかからず簡単にstaging環境が実現できる。

デプロイが簡単

基本的には git の設定さえしていれば

git push heroku master

といったコマンドでデプロイ可能。

heroku のダッシューボードでデプロイ可能な人の heroku アカウントが設定でき、誰がいつデプロイしたかも見られる。

また、ダッシュボードで GitHub との連携も可能で、それを行うことで、特定のブランチに push したらそのブランチの内容で自動的にデプロイするという設定や、ベータ版だが、Pull request を作成したら 自動的にその Pull request の変更内容で新たにアプリケーションを作成するという設定も可能らしい。

アドオンが便利

サーバー監視、ログ管理、DB管理、エラー通知などのツールはアドオンで瞬時に導入したり外したりできる。

Heroku Postgres

heroku 標準のDB。

Heroku Postgres - Add-ons - Heroku Elements

New Relic APM

サーバー、アプリケーションのパフォーマンス監視ツール。

New Relic APM - Add-ons - Heroku Elements

SSL

SSLの設定を行うアドオン。

SSL - Add-ons - Heroku Elements

Deploy Hooks

デプロイ通知を実現するアドオン。

デプロイが終わったら slack に通知させている。

Deploy Hooks - Add-ons - Heroku Elements

Papertrail

最新のログを確認したり、検索できるツール。

Papertrail - Add-ons - Heroku Elements

Logentries

こちらも最新のログを確認したり、検索できるツール。

エラーを通知する機能も。

Logentries - Add-ons - Heroku Elements

heroku を導入してみて

heroku は噂どおり便利だったのと、この移行作業でいろいろと調べながら進めたので、自分自身のスキルアップにも繋がりました。

必要な時に dyno を増やせたり、無料枠があったりなど、サービス立ち上げ時のコストが抑えられるだけでなく、 いろいろと調べる手間が省けるので、開発リソースの削減にも繋がると感じました。

また、インフラまわりの気になることは全て丸投げできるので、開発に集中でき、精神的な負担からも少し解放されるので毎日が楽しくなります。

開発をするうえでかかるコスト面と精神的な部分を担保してくれるのが heroku だと実感しました。

また、ネットに情報がたくさんありますが、古い情報や新しい情報が混在しているので以下の文献を参考にするのが一番 確実で近道でしたのでご参考までにどうぞ。