はじめに

前編では単一EC2でのWebサーバー運用における課題と、その解決策であるECS Fargate移行のメリットを解説しました。
Fargateはサーバー管理不要や自動スケーリング、環境標準化といった魅力的な特徴を持っています。

後編の本記事では前編で挙げたFargateの主要メリットが本当に享受できるのかを確認するため、実際に環境を構築して検証していきます。

【前編】そのEC2運用、限界かも？ Fargate移行がもたらす圧倒的なメリットとは:徹底比較編

検証環境の概要

今回の検証ではよくあるシンプルなWebサイトを想定し、以下のAWSサービスを利用して環境を構築しました。

  • コンピューティング: AWS Fargate (ECS on Fargate)
  • コンテナレジストリ: Amazon ECR
  • ロードバランサー: Application Load Balancer (ALB)

以下、今回の検証環境の構成図です。

検証項目と手順

前編で挙げたFargateの主なメリットについて、実際の動作を確認します。

メリット1：サーバー管理不要 (OSパッチ適用や障害対応など)

検証はありませんが、ECSでは、Fargateを利用する場合、ECSタスク定義ではコンテナイメージやCPU、メモリなどを指定し、OS自体を選択・インストール・管理する必要はありません。
基盤となるインフラストラクチャはAWSによって管理、運用されます。セキュリティパッチの適用やOSのメンテナンスも、AWSが自動的に実施します。
タスク定義で、AWS Fargateを選択します。↓

メリット2：自動スケーリングによるリソース・コスト最適化

検証目的:
設定したメトリクス、例えばCPU使用率に基づいてFargateタスク（コンテナ）の数が自動で増減することを確認します。

手順と確認:

  1. ECSサービスでService Auto Scalingを設定します。今回はCPU使用率が70%を超えたらタスク数を増やし、30%を下回ったら減らすように設定しました。
  2. 負荷テストツール、例えばApacheBench（ab）を用いてALBエンドポイントへ意図的に高い負荷をかけます。
  3. CloudWatchメトリクスを監視し、CPU使用率の上昇に伴ってECSサービスのタスク数が自動的に増加することを確認します。


    負荷に応じてタスク数が自動的に増加することが確認できました。

    スケーリングイベントからも確認できます。
  4. 負荷テストを停止し、しばらく待機します。
  5. CPU使用率の低下に伴い、タスク数が自動的に減少（スケールイン）することを確認します。


    負荷減少に伴い、タスク数が自動的に減少することを確認できました。

考察:
この自動スケーリング機能によりアクセスが少ない時はリソースを節約し、アクセスが増加した時だけ自動的にリソースを追加できます。これにより常に最適なリソース量でサービスを提供でき、コスト効率が大幅に向上します！

メリット3：Dockerfile による環境標準化と設定変更プロセス

検証目的:
前編で解説した「環境標準化 (Dockerfile)」のメリット、特に設定ファイル (httpd.conf など) を含めた環境全体をコードで管理し、安全かつ簡単に更新できるという点が本当に実現できるのか、実際のプロセスを通して検証します。

検証シナリオ:
Apache の設定ファイル (httpd.conf) を少し変更し、その変更を反映した新しいコンテナイメージを作成し、ECS サービスを更新して変更が適用されるまでの一連の流れを確認します。

手順と確認:

  1. (準備) 前回の検証で使用した、PHP が動作する状態の Dockerfile と、Apache の設定ファイル httpd.conf (mpm_prefork 有効化、PHP 設定追記済みのもの) をローカルに用意します。この httpd.conf を COPY するように Dockerfile も修正されている状態です。 
    # ベースイメージとして httpd (Apache) の Alpine 版を指定
FROM httpd:2.4

# パッケージリスト更新 と PHP および Apache 用 PHP モジュール (libapache2-mod-php) をインストール
# Debian/Ubuntu ベースのイメージでは apt-get を使用
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        php \
        libapache2-mod-php && \
# 不要なファイルを削除してイメージサイズを削減
apt-get clean && \
rm -rf /var/lib/apt/lists/*

#  Apache 設定ファイルをコピー
COPY httpd.conf /usr/local/apache2/conf/httpd.conf

# 表示する HTML ファイルと PHP スクリプトを Apache のドキュメントルートへコピー
COPY index.html /usr/local/apache2/htdocs/
COPY cpu_load.php /usr/local/apache2/htdocs/

# ポート 80 を公開
EXPOSE 80

# Apache をフォアグラウンドで起動
CMD ["httpd-foreground"]
  2. 設定ファイルのローカル編集:
    • ローカルにある httpd.conf を編集します。ここでは検証として分かりやすいように、レスポンスヘッダーに独自のヘッダーを追加する設定を追記してみましょう。 
      # httpd.conf の末尾あたりに追記
Header set X-App-Version "1.1"
    • (この変更を Git にコミットしておくと、変更履歴が追えてより良いでしょう)
  3. 新しいイメージのビルド＆プッシュ:
    • 設定変更を反映した新しいイメージを作成します。タグは :v8 のように変更します。 
      docker buildx build --platform linux/amd64 \
  -t .dkr.ecr..amazonaws.com/:v8 \
  --push .

  4. ECS タスク定義＆サービスの更新:
    • ECS タスク定義の新しいリビジョンを作成し、イメージ URI を :v8 に更新します。
    • ECS サービスを更新して、その最新リビジョンを使用するように指定し、デプロイを開始します。
    • デプロイが完了するのを待ちます 。

  5. 変更反映の確認:

    • デプロイ完了後、curl コマンドを使って、Web サーバーからのレスポンスヘッダーを確認します。 
      curl -I http:///index.html
    • レスポンスヘッダーの中に X-App-Version: 1.1 が含まれていれば、設定ファイルの変更が正しく反映されたことが確認できます。

      検証結果:
      この手順により、サーバーに直接ログインすることなく、ローカルでの設定ファイル編集、Git での変更管理、イメージの再ビルド、そして ECS サービスの更新という一連のプロセスで、安全かつ確実に設定変更を反映できることが確認できました。もし問題が発生した場合でも、ECS サービスで以前のタスク定義リビジョンを指定し直すだけで、容易にロールバックできることも大きな利点です。

考察:
前編で述べた通り、Dockerfile を活用することで、設定ファイルも含めた環境全体をコードとして管理し、バージョン管理やレビュー、安全なデプロイ・ロールバックといったソフトウェア開発のベストプラクティスをインフラ構成管理にも適用できることが、この検証を通じて具体的に確認できました。これにより、従来の手動での設定変更に伴うリスクや手間が大幅に削減され、より迅速かつ安全なインフラ運用が可能になります。

検証結果の考察

今回の検証を通じてFargateが前編で挙げたメリット、サーバー管理不要、自動スケーリング、環境標準化、AWSサービス連携を実際に提供できることが確認できました。

特にOSのパッチ適用やインフラの障害対応から解放される点は、大きな魅力です。
自動スケーリングは、リソース効率とコスト最適化に直結します。
そして、Dockerfileによる環境標準化は、単に環境の再現性を高めるだけでなく、今回の検証で確認したように、設定ファイルも含めてコードとして管理し、安全かつ効率的に更新するプロセスを実現します。

一方でFargate移行を成功させるには、コンテナ技術（Docker）やECSの概念に関する学習が必要です。
また既存アプリケーションをコンテナ化する際には、アプリケーションの特性に合わせた設計（ログ出力方法やステート管理など）が求められます。
コンテンツ更新フローも見直す必要があるかもしれません。
また、コンテナイメージ自体（ベースイメージや追加したライブラリ）に含まれる脆弱性は、ユーザーが責任を持って管理・対応しなければならない点にも注意が必要です。

これらの学習コストや初期の設計・移行コストはデメリットとして考慮する必要がありますが、それを乗り越えることで得られるメリットは非常に大きいと言えます。

まとめ（後編）

本記事（後編）ではFargate移行によるメリットを実際の環境で検証し、その有効性を確認しました。
サーバー管理の負担軽減や自動スケーリングによるコスト最適化、開発・デプロイプロセスの効率化と標準化など、Fargateは多くの利点を提供します。

初期の学習コストや移行作業は必要ですが長期的な視点で見れば、運用効率の大幅な向上やコスト削減、俊敏性の獲得といった計り知れないメリットを享受できるでしょう！

現在EC2でのサーバー運用に課題を感じているなら、Fargateへの移行はその課題を解決するための非常に有力な選択肢となるはずです。
参考になれば幸いです。

前編はこちら：そのEC2運用、限界かも？ Fargate移行がもたらす圧倒的なメリットとは:徹底比較編

参考ドキュメント

AWS Fargate
https://aws.amazon.com/jp/fargate/
Amazon ECS
https://aws.amazon.com/jp/ecs/
ECS における Auto Scaling
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-auto-scaling.html
AWS Fargate の料金
https://aws.amazon.com/jp/fargate/pricing/