EightがECS on EC2 からECS on Fargateに移行した背景と移行時に気をつけたこと
Sansan株式会社 / Kazuhiro Fujiwara
チームリーダー / SRE / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名
| ツールの利用開始時期 | 事業形態 |
|---|---|
| 2025年8月 | B to B B to C |
| ツールの利用開始時期 | 2025年8月 |
|---|---|
| 事業形態 | B to B B to C |
アーキテクチャ
アーキテクチャの意図・工夫
Fargateに限らず、Eightでは運用負荷軽減のためにAWSのマネージドサービスを積極的に取り入れています。
また、EC2からの移行時はログルーターや監視エージェント、セキュリティソフトウェアに対してサイドカーパターンを採用し、一つのコンテナの単位を最小限に保つようにしています。
導入の背景・解決したかった問題
導入背景
導入背景
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特有の話ではない点もありますが、気をつけた点と移行時に発生した課題についていくつか記載します。
気をつけた点
- システムのダウンタイムを設けずに平日の日中帯に移行した
ユーザー影響なく、ダウンタイムなしに移行することを目指していました。目的達成のために、新規にApplication Load Balancer (ALB) を作りDNSレイヤーでの荷重制御による切り替え方法やAWS CodeDeployのカナリアリリースを使う方法、ALBの荷重ターゲットグループを活用する方法など複数方法を検討しました。最終的には技術的に可能、かつ移行後も既存のTerraformコードとの整合性もとれるALBの荷重ターゲットグループを活用する方法を採用しました。マネージドサービスを活用していたことで、AWSサービスの機能内でダウンタイムなしに移行を成功させることができました。
- リリースパイプラインやそのほか内部向け運用周りの変更
ECSタスクが動くデータプレーンをEC2からFargateに移行する以外にも、既存の運用もFargateに合わせて移行する必要がありました。具体的にはリリースパイプラインで指定しているECSサービスの変更やEC2を事前に増強させる仕組みの削除、また、ChatOpsでECSサービスを増強させることができる仕組みなどです。移行時に限らず新規導入時も既存の運用で変更する箇所が出てくる可能性はあるので、Fargate検討時にはその移行影響や工数も加味しても良いかもしれません。
移行時に発生した課題
- Fluent Bitがデフォルトで付与するメタデータとログで保持するフィールドと被ってしまっていたことで、メタデータの値で上書きされてしまう
Fargateを採用するにあたって、コンテナが出力するアプリケーションログがファイル出力の場合は、標準出力への移行が必要になります。アプリケーションログを標準出力に変更した上で、FireLens(Fluent Bit)に移行しました。FireLensを使用して Fluent Bitに届いたログは、その時点でメタデータが追加されるようになっています。その追加されたメタデータがアプリケーションが出力するログのフィールドと一部被っていたことで、アプリケーションが出力するログが意図せず上書きされてしまうという問題が起こりました。検証の結果、Fluent Bitの設定を変更することでこの問題は解消されました。このように、環境によってはログ出力と送信の仕組みの変更が必要なので、現在のログ送信の仕組みとFargate採用時の移行方法も把握されておくと良いと思います。
導入に向けた社内への説明
上長・チームへの説明
本記事で移行したWebアプリケーションに限らず、以前よりEC2を廃止していく取り組みを実施していたため特に不要でした。
活用方法
Web APIサーバーのコンテナが動作するデータプレーンとして利用しています。
よく使う機能
- スケジュールされたアクション
- 負荷に応じたスケーリング
- FireLensによるログ送信
- Blue / Green Deployment (ネイティブではなくCodeDeploy連携)
ツールの良い点
- メンテナンスレス
- 高いセキュリティ
- タスクごとにカーネルの分離がされている
- 基盤となるホストにはアクセスできない
ツールの課題点
- vCPUとメモリの組み合わせは決まっており、EC2ほどタスク定義内のリソース選択の柔軟性がない
- StopTimeout(SIGTERMを受け取ってからグレースフルシャットダウンの猶予期間)が最大で120sのため、一回の処理で長時間実行されるような非同期処理で採用する場合はStopTimeoutの考慮が必要になる
- 私たちのコンテナイメージのケースでは、EC2がすでに用意されている場合のECS on EC2と比較してタスクの起動までに時間がかかる
ツールを検討されている方へ
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の空きキャパシティがないケースでも自動でオンデマンドに置き換えることはないのでシステムの安定性に欠けてしまいます。そのあたりの特性を理解しつつシステムの信頼性を落とさずにコストを最適化するために検証を重ねている最中です。
Sansan株式会社 / Kazuhiro Fujiwara
チームリーダー / SRE / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名
よく見られているレビュー
Sansan株式会社 / Kazuhiro Fujiwara
チームリーダー / SRE / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


