メディアエンジン、HerokuとAWS混在の管理煩雑化とレイテンシ課題を解消。2名2週間でECS・Amplify・RDSへ全面移行しパフォーマンス4倍に

メディアエンジンは初期に構築したシステムのバックエンドにRuby on RailsとPostgreSQLを採用しており、スムーズに開発できることを理由にHerokuで運用していた。一方、近年開発したシステムはAWSのECSを利用しており、AWSを使うシステムとHerokuを使うシステムが混在することで運用管理が煩雑化していた。さらにHerokuは国内にサーバを設置できないため、AWSと比較してレイテンシが大きくなるという問題も抱えていた。これらの課題を解消するため、HerokuからAWSへのインフラ全面移行を決断した。

移行は著者と社内のインフラに詳しいメンバーの2名体制で、調査・実作業を含めておよそ2週間かけて実施された。

• APIサーバ: Heroku Container RuntimeからECSへ。既存のDockerfileをそのまま利用できたため比較的スムーズに移行できた
• フロントエンド: HerokuからAmplifyへ。従来@nuxtjs/proxyモジュールでRailsサーバと通信していた構成を廃止し、フロントエンドから直接APIサーバへ通信する構成に変更、Rails側にrack-corsを導入してCORSを設定
• スケジューラ: Heroku SchedulerからECSへ
• データベース: Heroku PostgreSQLの管理ページから手動バックアップを作成し、pg_restoreでRDSへデータ移行。特に課題なくスムーズに実施できた
• キャッシュ: Heroku RedisからElastiCacheへ
• ログ: PapertrailからCloudWatchへ
• 監視: RollbarとScout APMからSentryへ統合

全体的にシステムのパフォーマンスが4倍前後まで向上した。インフラをAWSへ一元化したことでメンテナンスがしやすくなり、インフラの大部分をTerraformで管理できるようになった。一方で監視面では、Scout APMが持っていたN+1問題検出機能をSentryは持たないため、著者は「一概にSentryの方が上回っているとも言い切れない」と振り返っている。