Elastic Beanstalk から Amazon ECS（Fargate）へインフラ移行

ツール導入前の課題

弊社で管理するメインサービスのAPIサーバは、サービスイン当初からElasticBeanstalkで運用しておりました。サービスが成長するにつれて、ElasticBeanstalkで運用する上で、いくつかの課題が浮かび上がってきました。主に、以下のような課題がありました。

1. プラットフォームの更新が手間

• 新しいバージョンのプラットフォーム、ランタイムを利用する際、基本的に0からの新規構築が必要で、簡単にバージョンアップができない。

2. ランタイムに関するバージョン更新の遅延

• ElasticBeanstalkはプラットフォームの更新が遅く最新のPHPランタイムなどが利用できない。

3. デプロイの遅延

• ElasticBeanstalkはデプロイ時にEC2インスタンスを新たに立ち上げ、古いインスタンスを削除するため、デプロイに時間がかかる。

4. スケーリングの遅延

• ElasticBeanstalkはスケーリング時にEC2インスタンスを新たに立ち上げるため、スケーリングに時間がかかる。

5. スケーリングの粒度

• ElasticBeanstalkはスケーリングの粒度がEC2インスタンス単位であるため、スケーリングの際に無駄なリソースを立ち上げることがある。

どのような状態を目指していたか

弊社、開発チームメンバのスキルセットとしては、アプリケーション開発がメインであるため、以下を念頭に選定しました。

• シンプルなインフラ構成であること
• インフラの運用コストを抑えること

• Amazon ECS（EC2）
• Amazon EKS（Elastic Kubernetes Service）

• Amazon ECS（EC2）との比較

Amazon ECS（EC2） は、ECSを使用してコンテナを管理し、EC2インスタンス上でコンテナを実行するサービスです。そのため、EC2インスタンスの管理が必要となります。一方、Fargateを使用する場合、EC2 インスタンスの管理は不要です。このことから、Fargateの方が運用コストが低いと考え、Fargateを採用しました。

• Amazon EKS（Elastic Kubernetes Service）との比較

AWS Fargate 同様、EKSもコンテナオーケストレーションサービスですが、EKSはKubernetesをベースとしているため、EKS の運用にはKubernetesの知識が必要です。弊社の開発チームメンバのスキルセットとしては、Kubernetesの知識が浅いため、EKSの導入は避けることとしました。

以上のことから、ECS + Fargate を採用することにしました。

ECSに移行したことでプラットフォームの更新が容易になり、PHPやLaravelのバージョンアップも負荷なく行えるようになりました。また、デプロイ速度の向上によりリリース時間を短縮でき、開発チームの生産性向上に寄与しています。

ECSが標準でBlue/Green デプロイメントに対応したため、CodeDeployを利用せずとも安全なリリース戦略を実現できるようになりました。今後はこの機能を試していきたいと考えています。