EightがECS on EC2 からECS on Fargateに移行した背景と移行時に気をつけたこと

導入背景

EightではWebアプリケーションのAPIをECS on EC2上（Amazon Elastic Compute Cloud上でAmazon Elastic Container Serviceがコンテナを動かすことを意味しています）で動かしていました。この構成では、有事の際のトラブルシューティングやスクリプト実行のために、EC2インスタンスへSSHでアクセスできる状態になっていました。これにはセキュリティ上のリスクがあります。具体的には、EC2にアタッチされているIAMロールの権限内でAWSリソースが操作されるリスクや、機密情報が含まれた本番環境のデータベースにアクセスされることでデータを操作されるリスクがあります。

合わせて、OSレイヤー、EC2インスタンスそのものの運用管理コストも発生していました。運用管理の中にはアラート対応も含まれます。例えば、EC2上で動かす以上ディスクフルのアラートや特定のインスタンスでレスポンスが遅くなる、といったことが時折ありました。また、管理する箇所が増えると、設定ミスなどのヒューマンエラーも起こりやすくなります。そのため、インスタンスそのものを意識する必要がなく、よりアプリケーションに集中できるAWS Fargateの移行検討を開始しました。

なお、スケーリング管理についてはEC2の時からEC2含めて自動でスケーリングするようになっていたため、その面での運用管理はほとんど発生していませんでした。

改善したかった課題はどれくらい解決されたか

• インスタンスへのSSHができなくなり、かつ本番環境ではECS Execを無効化していることで任意のコマンドが実行できないため、よりセキュアになった
• EC2のアラート対応が無くなった
  • ログ肥大化によってログローテーションが間に合わずディスクフルになる
  • 特定インスタンスだけレスポンスが遅くなる　etc.
• 定期的にAWS側で基盤に対してパッチ適用がされるため、アプリケーションのリリース作業をするだけでパッチ適用後の基盤でコンテナが実行されるようになった

導入時というよりは移行時の文脈となってしまうため、かつFargate特有の話ではない点もありますが、気をつけた点と移行時に発生した課題についていくつか記載します。

気をつけた点

1. システムのダウンタイムを設けずに平日の日中帯に移行した

ユーザー影響なく、ダウンタイムなしに移行することを目指していました。目的達成のために、新規にApplication Load Balancer (ALB) を作りDNSレイヤーでの荷重制御による切り替え方法やAWS CodeDeployのカナリアリリースを使う方法、ALBの荷重ターゲットグループを活用する方法など複数方法を検討しました。最終的には技術的に可能、かつ移行後も既存のTerraformコードとの整合性もとれるALBの荷重ターゲットグループを活用する方法を採用しました。マネージドサービスを活用していたことで、AWSサービスの機能内でダウンタイムなしに移行を成功させることができました。

2. リリースパイプラインやそのほか内部向け運用周りの変更

ECSタスクが動くデータプレーンをEC2からFargateに移行する以外にも、既存の運用もFargateに合わせて移行する必要がありました。具体的にはリリースパイプラインで指定しているECSサービスの変更やEC2を事前に増強させる仕組みの削除、また、ChatOpsでECSサービスを増強させることができる仕組みなどです。移行時に限らず新規導入時も既存の運用で変更する箇所が出てくる可能性はあるので、Fargate検討時にはその移行影響や工数も加味しても良いかもしれません。

移行時に発生した課題

• Fluent Bitがデフォルトで付与するメタデータとログで保持するフィールドと被ってしまっていたことで、メタデータの値で上書きされてしまう

Fargateを採用するにあたって、コンテナが出力するアプリケーションログがファイル出力の場合は、標準出力への移行が必要になります。アプリケーションログを標準出力に変更した上で、FireLens(Fluent Bit)に移行しました。FireLensを使用して Fluent Bitに届いたログは、その時点でメタデータが追加されるようになっています。その追加されたメタデータがアプリケーションが出力するログのフィールドと一部被っていたことで、アプリケーションが出力するログが意図せず上書きされてしまうという問題が起こりました。検証の結果、Fluent Bitの設定を変更することでこの問題は解消されました。このように、環境によってはログ出力と送信の仕組みの変更が必要なので、現在のログ送信の仕組みとFargate採用時の移行方法も把握されておくと良いと思います。

2025年10月にECSのデータプレーンとしてマネージドインスタンスが発表されました。今まではEC2かFargateの2つしか選択肢がなかったところ、EC2インスタンスそのものの運用管理コストを下げつつインスタンスタイプを柔軟に選択できるマネージドインスタンスといった選択肢が増えました。ワークロードの要件によっては、インスタンスを柔軟に選択したいが運用管理コストは下げたい、というケースもあるかと思います。Fargateを検討されている場合はマネージドインスタンスも含めて検討していただくと良いかもしれません。

現在、コストを最適化する取り組みをしています。

移行時は安定性を優先し、オンデマンドなFargateのみを使うように移行しました。移行前のECS on EC2ではスポットインスタンスを活用していたため、オンデマンドなFargateのみを使い続けると単純にコストが増えてしまいます。そこで、Fargate Spotを活用することで、コストを最適化していきたいと考えています。Fargate SpotはAWSの空きキャパシティを活用してタスクを実行する仕組みのため、オンデマンドなFargateと比較して最大で70％の割引を受けられます。

しかし、Fargate Spotを活用する上での課題もあります。通常、Fargate Spotを使う場合はキャパシティープロバイダー戦略という機能でオンデマンドなFargateとFargate Spotの重みを決めていきますが、Fargate Spotの空きキャパシティがないケースでも自動でオンデマンドに置き換えることはないのでシステムの安定性に欠けてしまいます。そのあたりの特性を理解しつつシステムの信頼性を落とさずにコストを最適化するために検証を重ねている最中です。