インフラをHerokuからAWSへ移行した話
はじめに
はじめまして。メディアエンジン株式会社の田中と申します。
この度、弊社ではZennでテックブログを開設することになりました。
これから開発などに関する様々な情報を発信していきたいと思います。
早速ですが、弊社で運用しているシステムのインフラをHerokuからAWSへ移行しました。
この記事では、移行に当たって実施したことなどについて解説させていただきます。
移行の経緯について
弊社にて初期から開発しているシステムの中にはHerokuで動作しているものがありました。
バックエンドにRailsとPostgreSQLを採用していることもあり、スムーズに開発などができることがHerokuの採用理由でした。
しかし、ここ数年で新しく開発したシステムはバックエンドをECSで動作させているものがほとんどであり、以下のような課題を感じるようになってきました。
- 国内にサーバを置けないため、HerokuはAWSと比較してレイテンシが大きくなってしまう
- AWSを使っているシステムとHerokuを使っているシステムが混在しており、管理が煩雑化している...
そこで、インフラをHerokuからAWSへ移行することにしました。
システム構成
移行後及び移行前のシステム構成は下記のようになっています。
| 移行後 | 移行前 | 備考 |
|---|---|---|
| ECS | Heroku Container Runtime | Railsで実装されたAPIサーバ |
| Amplify | Node.js on Heroku | Nuxt.jsサーバ |
| ECS | Heroku Scheduler | |
| RDS | Heroku Postgres | |
| ElastiCache | Heroku Redis | |
| CloudWatch | Papertrail | |
| Sentry | Rollbar | |
| Sentry | Scout APM |
移行体制
私と社内のインフラに詳しいメンバの2名で実施しました。
私があまりインフラに詳しくないこともあり、もう一人のメンバに色々とサポートしてもらいながら進めていきました。
移行にかかった期間としては、調査と実作業を含めておよそ2週間程かかりました。
移行にあたってやったこと
APIサーバをHerokuのContainer RuntimeからECSへ移行
元々、Railsで実装したAPIサーバをHerokuのContainer Runtimeで動かしていました。
Dockerfileを再利用できることと、他のシステムですでに運用実績があったこともあり、APIサーバはECSへ移行することにしました。
Dockerfileには一切変更は入れずそのまま利用できたこともあり、この移行作業は比較的スムーズに行えました。
フロントエンドをHerokuからAmplifyへ移行
フロントエンドもAPIサーバと同様にHerokuで動かしていました。
そのため、フロントエンドもAWSへ移行することにしました。
移行先としては、他のシステムで運用実績のあったAmplifyを利用することにしました。
この移行にあたっては、いくつか追加で作業が必要になりました。
- Node.jsへの依存をなくす
- APIサーバでCORSを有効化する
元々、フロントエンドからRailsサーバへのやり取りには@nuxtjs/proxyモジュールを利用していました。
そのため、フロントエンドを動作させるためにはNode.jsが必須であり、そのことがAmplifyへ移行する上で課題になりました。
そこで、@nuxtjs/proxyを廃止し、フロントエンドから直接APIサーバと通信をさせるようにシステムを修正しました。
また、この修正に伴ってRailsアプリ側にrack-corsを導入し、CORSの設定を実施しました。
Heroku PostgreSQLからRDSへの移行
データベースには元々Heroku PostgresSQLを利用していましたが、素直にRDSへ移行することにしました。
Heroku PostgreSQLの管理ページから手動でバックアップを作成し、それをpg_restoreを使用してデータ移行を実施しました。
データベースの移行については特に課題なども発生せずスムーズに実施できました。
RollbarおよびScout APMからSentryへの移行
エラー監視にはRollbar、パフォーマンスモニタリングにはScout APMを利用していました。
これらのサービスを採用していた理由としては、どちらもHeroku Add-onが提供されており、Herokuとの相性が良かったためです。
今回のAWS移行にあたっては、これらのサービスからSentryへ移行することにしました。
Sentryを採用した理由としては、以下の通りです。
- Sentryはエラー監視に加えて、ある程度パフォーマンスモニタリングの用途でも使用できる
- パフォーマンスモニタリングはECSのメトリクスなどでもある程度調べられる
今回はSentryを採用しましたが、Scout APMにはN+1問題を検出してくれる機能などもあり、一概にSentryの方が上回っているとも言い切れないため、一長一短ではないかと感じています。
移行してみてよかったこと
- 元々、HerokuのContainer Runtimeで使っていたDockerfileをそのまま利用できたこともあり、バックエンドについてはスムーズに移行ができました。
- 移行した結果、全体的にシステムのパフォーマンスが4倍前後まで向上しました。
- インフラをAWSへ一元化することで、メンテナンスがしやすくなりました。
- インフラの大部分をTerraformで管理できるようになりました。
おわりに
以上、システムをHerokuからAWSへ移管した話でした。
少しでも参考になりましたら幸いです。
最後に、弊社ではエンジニアやデザイナーなどの職種で積極的に採用中です！
Wantedlyでも情報発信していますので、もし興味がありましたらぜひご覧いただければと思います！
Discussion