主力事業のインフラをEC2基盤からECS/Fargate基盤に完全移行した話

スマートキャンプ、エンジニアの入山です。

弊社のBOXILは、AWSを基盤としたRailsベースのアプリケーションです。
以前のブログでもECS移行におけるTipsを紹介しましたが、2020年10月頃よりEC2基盤からECS/Fargate基盤へのインフラ移行に取り組んでおり、2021年5月に新しい基盤が無事本番稼働を迎えました。

今回は、弊社BOXILのインフラ移行について、概要を紹介したいと思います。

BOXILのインフラについて

BOXILは、弊社創業から程なくして誕生し、弊社と共に成長してきた主力プロダクトで、リリースから6年以上が経過しています。そんなBOXILのインフラは、プロダクト発足時からAWSのEC2基盤で構築・運用されてきました。

創業期から存在するプロダクトということもあり、初期のインフラはいわゆるアンチパターンにあたる要素を含む構成で、インフラ起因の障害も起きていたと聞いています。その後、事業やエンジニア組織の拡大に合わせて、インフラ構成やCI/CDなど様々な面で改善を繰り返し、直近ではインフラ起因の障害もなく安定稼働できる状態になっていました。

EC2基盤の課題と移行の背景

前述の通り、BOXILはインフラ構成やCI/CDなどの改善を何度か実施しています。 これらの改善によって、安定稼働に加えてCI/CDや運用面も適度に自動化されていたため、致命的な不便さや欠陥はありませんでした。 しかし、長年運用してきたEC2基盤では、やはり簡単には改修へ踏み切れない部分もあり、致命的ではないものの以下のような課題や技術的負債を抱えていました。

• 構成管理
  • OpsWorksでの煩雑な構成管理
  • スケーリングに手動対応が必要（最大+2台）
  • 環境変数が適切に管理できてない
  • サーバー障害時は手動対応が必要
• CI/CD
  • デプロイ時間が長い
    • 約45分 / staging~productionまでの1リリース
  • 自動ロールバックができない（要再デプロイ）
  • デプロイ環境依存のエラー
  • Jenkinsサーバーがたまに落ちる

これらは、今までも少なからず開発効率やDX向上の妨げとなっていましたが、基本的に対応頻度の少ない事象だったこともあり、暗黙的に対応しない（できない）ものとして扱われていました。しかし、今後更に速いスピードで事業や組織の拡大を達成していく上で、将来的により大きな負債となる懸念があったため、今回のタイミングでインフラ移行を実施することにしました。

尚、今回の移行プロジェクトは、脱EC2を始めとする前述の負債解消を主目的とし、最小工数・最低限でECS/Fargateへ置き換えることを目標にしていました。

EC2基盤のアーキテクチャ

BOXILはいわゆる一般的な構成のWebアプリケーションで、Web/APサーバーを中心にRDSやElastiCache、S3、ログ管理サーバーなどで構成されています。

移行前のEC2基盤のアーキテクチャは、各サーバーがEC2で構築された以下のような構成となっていました。 尚、デプロイについては、基本的に全てJenkinsのWorkflowで管理しており、デプロイサーバーから各サーバーに対して実施していました。

ECS/Fargate基盤のアーキテクチャ

移行後のECS/Fargate基盤のアーキテクチャは、移行前にEC2で構成されていた各サーバーをECS/Fargateによるコンテナ（タスク）に置き換えた構成となっています。 また、デプロイについては、デプロイサーバー（Jenkins）を廃止し、CircleCIによるDockerイメージビルドとCodeDeployによるECS/Fargateへのデプロイを組み合わせた構成となっています。

移行による効果

ECS/Fargate基盤への移行作業は、技術検証・環境構築・テスト・移行までの全工程を、私と当時内定者インターンの二人で計約半年ほどの工数で実施しました。社内にECSの前例がなく技術キャッチアップや技術検証も含んでいたため、最小工数・最低限での移行でも安全に稼働させるためにはそれなりのコストが掛かりましたが、掛かったコスト以上の効果はあったと感じています。

弊社における具体的な移行の効果としては、以下のようなものが挙げられます。

Pros

• 構成管理
  • コンテナ化&Fargate化による環境管理コスト減
    • サーバー管理不要
    • DockerによるImmutableな環境
    • 脱OpsWorks
  • オートスケールが容易&速い
  • 障害時の自動復旧
  • パラメタストア + コンテナ定義による環境変数管理の柔軟性向上
• CI/CD
  • デプロイ時間短縮（約15分短縮）
    • 約30分 / staging~productionまでの1リリース
  • CodeDeployによるBlue/Greenデプロイ
    • 即時自動ロールバックが可能
    • カナリアリリースなど柔軟に選択可能
    • 脱Jenkins
  • SlackでのChatOps
    • （参考記事）SlackでChatOps！CodeDeployのBlue/Greenデプロイを操作する方法
• コスト
  • サーバー費用削減（約12万 / 月）
    • コンテナ化による割当スペック最適化
    • オートスケールによるコスト最適化

Cons

• Fargate特有の制約がある
  • カーネルパラメタ制限
  • CPU選択不可
  • コンテナログインに一工夫が必要
    • （参考記事）待望！Amazon ECSのコンテナにログインできるAmazon ECS Execを試してみた
    • （参考記事）AWS Fargateで動いているコンテナにログインしたくて Systems Manager の Session Manager を使ってみた話
• 技術キャッチアップが必要
  • EC2とECS/Fargateでは設計や運用面が大きく異なる
  • 各メンバーへの教育も必要
• ECS/Fargateに関する情報が少ない

基本的には、技術的に新しく進歩した基盤への運用効率や利便性向上を目的とした移行だったため、Prosが多くかなりの効果が得られました。

Consに関しては、Fargateでサーバー管理が不要になった代わりの制約や根本的に利用する技術の変化に起因するもので、移行する上ではある程度は避けられない部分といった印象です。Fargateに関する制約については、Fargateのバージョンアップに伴って柔軟性が向上してきているので、今後に期待です。

まとめ

今回は、弊社BOXILのインフラをEC2からECS/Fargateへ移行した話の概要をご紹介しました！

インフラは、移行コストやリスクの観点からなかなか手がつけにくい部分ではありますが、刷新することで中長期的な開発効率向上が期待できます。 近年の流れとして、コンテナ技術やサーバーレスアーキテクチャの発展によって、低レイヤな基盤部分をエンジニアが意識しなくてよくなってきています。

こういった流れも含めてインフラを見直すことで、様々なメリットを得られる機会に繋がるのではないでしょうか。インフラ移行の一例として、少しでも参考になれば幸いです！