以下の順で進めていきます。今回はとりあえずFargate上で動くことをゴールにしますので、MySQLは使いません。

1. ローカルでRails7.1を立ち上げる
2. ECR(Amazon Elastic Container Registry)にRailsイメージをpushする
3. ECRのイメージを使って、ECS(Amazon Elastic Container Service)-Fagateにデプロイ

まずは、ローカルでRails7.1を起動していきます。

ローカルでRialsを動かしてみる

アプリケーションの作成

以下のコマンドでアプリケーションを作成して、作成したアプリケーションのフォルダに移動します。

rails new test_app

cd test_app/

まずはDockerfileを修正します。

Dockerfileの修正

Rails newで作成されたDockerfileを修正します。

vi Dockerfile

以下の2点変更します。

<変更①>「ENV RAILS_ENV="production"」をコメントアウトして、「ENV RAILS_ENV=$ENVIROMENTS」を追記します。
#ENV RAILS_ENV="production" \
ENV RAILS_ENV=$ENVIROMENTS \
<変更②>
5行目のFORMの後に以下を追加
ARG ENVIROMENTS

上記変更を加えることで、Railsを以下の指定をして、起動できるようになります。

• production
• development
• tesst

コンテナを立ち上げて動作確認

以下のコマンドでビルドします。

docker build . -t test_app --build-arg ENVIROMENTS='development'

以下のコマンドでコンテナを起動します。

docker run -it -p 3000:3000 --env RAILS_MASTER_KEY=`cat config/master.key` test_app bin/rails server -b 0.0.0.0

http://localhost:3000/にアクセスし、以下の画面が表示されれば、動作確認OKー

ECR(Amazon Elastic Container Registry)にRailsイメージをpush

以下のコマンドで、AWSの接続設定をしておきます。

aws configure

次にECRログインします。

aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com

以下のコマンドでリポジトリを作成します。

aws ecr create-repository \
        --repository-name rails \
        --image-scanning-configuration scanOnPush=true \
        --region ap-northeast-1 

Railsアプリのタグ作成します

docker tag test_app:latest {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/rails:latest

Railsアプリのpushです

docker push {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/rails:latest

 

次に、Fagateにデプロイします！

ECS(Amazon Elastic Container Service)-Fagateにデプロイ

クラスターの作成

以下の設定で作成します。指定箇所以外は任意の値で大丈夫です。

• インフラストラクチャ：AWS Fargate (サーバーレス)

タスク定義の作成

以下の設定で作成します。指定箇所以外は任意の値で大丈夫です。

• インフラストラクチャの要件
  • 起動タイプ：AWS Fargate
  • オペレーティングシステム/アーキテクチャ：自分のPCと一致するもの(基本はx86_64でOK、M1/M2 MacはARM64を選択)
    • この設定に誤りがあると「exec /usr/local/bin/start-container: exec format error」エラーになります。
  • タスクサイズ
    • CPU：.5 vCPU
    • メモリ：1GB
• コンテナ – 1
  • 名前：app
  • イメージURI：{AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/rails:latest
  • コンテナポート:3000
  • アプリケーションプロトコル:HTTP
  • 環境変数
    • キー：RAILS_MASTER_KEY
    • 値：「config/master.key」の値を直接入力
      • 「cat config/master.key」を入力すると「ArgumentError: key must be 16 bytes (ArgumentError)」エラーになる
  • Docker設定
    • コマンドに以下を設定
      • /rails/bin/rails,server,-b,0.0.0.0

タスク起動

作成したクラスターのタスクタブにある「新しいタスクの実行」を押下

• コンピューティング設定：起動タイプ
• デプロイ設定
  • ファミリー:先ほど作成したタスクを設定
  • リビジョン：最新
• ネットワーキング
  • セキュリティグループ：ポート3000の許可を追加

動作確認

作成したクラスターのタスクタブの任意のタスクの詳細を開きます。

パブリックIPが表示されるので、http://パブリックIP:3000でブラウザからアクセスします。

以下の画面が表示されればOKです。

以下の順で進めていきます。今回はとりあえずFargate上で動くことをゴールにしますので、MySQLは使いません。

1. ローカルでLaravel11を立ち上げる
2. ECR(Amazon Elastic Container Registry)にLaravelイメージをpushする
3. ECRのイメージを使って、ECS(Amazon Elastic Container Service)-Fagateにデプロイ

まずは、ローカルでLaravel11を起動していきます。

ローカルでLaravel11を起動する

まずは、完成系のディレクトリ構成から記載します。

ディレクトリ構成

以下のような構成となります。

├── docker
│   ├── nginx
│   │   ├── Dockerfile
│   │   └── default.conf
│   └── php
│       └── Dockerfile
└── docker-compose.yml

ディレクトリの作成

上記ディレクトリ構成を作成するためのディレクトリを作成します。

mkdir fargate_laravel
cd fargate_laravel/

準備はできましたので、ディレクトリ構成に記載のディレクトリとファイルを作成していきます。

docker-compose.ymlの作成

docker-compose.ymlを作成します。

vi docker-compose.yml

＜ファイルの中身＞

version: '3'
services:
  app:
    build:
      context: .
      dockerfile: ./docker/php/Dockerfile
    container_name: app_laravel
    volumes:
      - .:/var/www
  nginx:
    build:
      context: .
      dockerfile: ./docker/nginx/Dockerfile
    container_name: nginx_laravel
    ports:
      - 8000:80
    working_dir: /var/www
    depends_on:
      - app

nginxのdefault.confを作成

nginxのdefault.confを作成します。

mkdir -p docker/nginx

vi docker/nginx/default.conf

＜ファイルの中身＞

server {
  listen 80;
  root /var/www/laravel-project/public;
  index index.php;
  location / {
    try_files $uri $uri/ /index.php?$query_string;
  }
  location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;   # 正常に動作しない場合は、app:9000に書き換える
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  }
}

nginxのDockerfileの作成

nginxのDockerfileを作成します。

vi docker/nginx/Dockerfile

＜ファイルの中身＞

FROM nginx:1.25
COPY  docker/nginx/default.conf /etc/nginx/conf.d/

アプリコンテナのDockerfile作成

アプリコンテナのDockerfile作成を作成します。

mkdir docker/php

vi docker/php/Dockerfile

＜ファイルの中身＞

FROM php:8.3-fpm

RUN apt-get update \
  && apt-get install -y zlib1g-dev mariadb-client vim libzip-dev \
  && docker-php-ext-install zip pdo_mysql

#Composer install
RUN php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
RUN php composer-setup.php
RUN php -r "unlink('composer-setup.php');"
RUN mv composer.phar /usr/local/bin/composer

ENV COMPOSER_ALLOW_SUPERUSER 1

ENV COMPOSER_HOME /composer

ENV PATH $PATH:/composer/vendor/bin

COPY ./ /var/www/

RUN chmod -R 777 /var/www/

WORKDIR /var/www


RUN composer global require "laravel/installer"

必要なファイル作成が終わりましたので、コンテナ立ち上げてLaravel11をインストールしていきます。

コンテナ立ち上げ

以下のコマンドでコンテナを立ち上げます。

docker compose up -d

Laravel 11のインストール

アプリコンテナの中に入りLaravel11をインストールします。

# アプリコンテナに入るコマンド
docker compose exec app bash

# Laravel11インストールコマンド
composer create-project --prefer-dist laravel/laravel laravel-project "11.*"

ブラウザで「http://localhost:8000/」 へアクセスして以下の画面が表示されればOK！

 

次は、ECRにイメージをpushして行きます。

ECR(Amazon Elastic Container Registry)にLaravelイメージをpush

以下のコマンドで、AWSの接続設定をしておきます。

aws configure

次にECRログインします。

aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com

以下のコマンドでリポジトリを作成します。

aws ecr create-repository \
        --repository-name laravel.test \
        --image-scanning-configuration scanOnPush=true \
        --region ap-northeast-1 

aws ecr create-repository \
        --repository-name nginx \
        --image-scanning-configuration scanOnPush=true \
        --region ap-northeast-1 

以下のコマンドでビルドします。

docker compose up --build 

Laravelアプリのタグ作成します

docker tag fargate_laravel-app:latest {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/laravel.test:latest

Laravelアプリのpushです

docker push {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/laravel.test:latest

Nginxのタグ作成します

docker tag nginx:latest {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/nginx:latest

Nginxのpushです

docker push {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/nginx:latest

次に、Fagateにデプロイします！

ECS(Amazon Elastic Container Service)-Fagateにデプロイ

クラスターの作成

以下の設定で作成します。指定箇所以外は任意の値で大丈夫です。

• インフラストラクチャ：AWS Fargate (サーバーレス)

タスク定義の作成

以下の設定で作成します。指定箇所以外は任意の値で大丈夫です。

• インフラストラクチャの要件
  • 起動タイプ：AWS Fargate
  • オペレーティングシステム/アーキテクチャ：自分のPCと一致するもの(基本はx86_64でOK、M1/M2 MacはARM64を選択)
    • この設定に誤りがあると「exec /usr/local/bin/start-container: exec format error」エラーになります。
  • タスクサイズ
    • CPU：.5 vCPU
    • メモリ：1GB
• コンテナ – 1
  • 名前：app
  • イメージURI：{AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/laravel.test:latest
• コンテナ – 2
  • 名前：nginx
  • イメージURI：{AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/nginx:latest
  • コンテナポート:80
  • アプリケーションプロトコル:HTTP

タスク起動

作成したクラスターのタスクタブにある「新しいタスクの実行」を押下

• コンピューティング設定：起動タイプ
• デプロイ設定
  • ファミリー:先ほど作成したタスクを設定
  • リビジョン：最新
• ネットワーキング
  • セキュリティグループ：ポート80の許可を追加

動作確認

作成したクラスターのタスクタブの任意のタスクの詳細を開きます。

パブリックIPが表示されるので、パブリックIPでブラウザからアクセスします。

以下の画面が表示されればOKです。

コンテナ利用時のログ出力に関する記事もありますので、気になる方は以下をクリックくださーい

Laravelをコンテナで運用する際のログ出力は、JSON形式で標準出力した方が良い

Laravelをコンテナで運用する際のログ出力は、JSON形式で標準出力した方が良いということを書いていきます。 Laravelに限らず、コンテナでは、JSON形式で標準出力が良いと思いますが、Laravelでは簡単にログをJSON形式で標...

it.kensan.net

2024.06.02

AWSの記事に以下の記載がありますが、実際にどれくらい性能が違うの？という点について調査するために、Fargateにカウントアップさせて、1分間にいくつまで数えられるかやってみました！！

AWS Graviton2 プロセッサは、64 ビットの Arm Neoverse コアを使用してアマゾンウェブサービスがカスタムビルドしたもので、Graviton2 を搭載した Fargate は、同等のインテル x86 ベースの Fargate に比べて、最大 40% の料金性能向上と 20% の低コストを実現し、

AWS Graviton2 Processors を搭載した AWS Fargate for Amazon ECS を発表

aws.amazon.com

上記のAWSの記載をまとめると以下のようになると思います。

では、実際に、Linux/ARM64(Graviton2)とLinux/X86_64(インテルCPU)の比較検証をしていきます。

検証ではカウントアップするだけという簡単なプログラムを使用していきます！

検証条件

まずは、検証条件についてです。

プログラム言語

使用するプログラム言語：python

ECS Fargate タスク性能

CPU：1vCPU

メモリ：2 GB

使用したプログラム

import time
import timeout_decorator

# 60秒でタイムアウト
@timeout_decorator.timeout(60)
def test():
    cnt = 0
    while True:   # タイムアウトするまで、ひたすらカウントアップ
        if cnt % 10000 == 0:
            print(cnt)
        cnt += 1

if __name__ == '__main__':
    try:
        test()
    except:
        print ("test timed out ")

使用したDockerファイル

FROM python:3.12

RUN pip install timeout-decorator

# 検証用プログラムをコピー
COPY . .

# コンテナ起動時に検証用プログラムを実行
CMD ["python", "./test.py"]

検証結果

Linux/ARM64(Graviton2)

＜検証方法＞

1. ビルドし、ECRにイメージをpush
2. ECSタスク定義の「オペレーティングシステム/アーキテクチャ」でLinux/ARM64を指定
3. タスクを起動

＜検証結果＞

カウントアップできた数：702,420,000

Linux/X86_64(インテルCPU)

＜検証方法＞

1. ビルドし、ECRにイメージをpush
2. ECSタスク定義の「オペレーティングシステム/アーキテクチャ」でLinux/X86_64を指定
3. タスクを起動

＜検証結果＞

カウントアップできた数：558,450,000

検証結果比較

• Linux/ARM64(Graviton2)
  • カウントアップできた数：702,420,000
•  Linux/X86_64(インテルCPU)
  • カウントアップできた数：558,450,000
• Linux/ARM64(Graviton2)の方が、1.4億くらい多くカウントできました
  • Linux/ARM64(Graviton2)の方が、26%程度性能が良い結果です！！

まとめ

以下のAWS記事情報を前提に検証しました。今回やってみた簡単なカウントアップの検証では、性能はLinux/ARM64(Graviton2)の方が、26%程度高い結果となりました。コストが20%程度低いことから、料金性能は以下の「最大 40% の料金性能向上」とほぼ一致と思いますー

ArmのCPUはAWS Graviton2 が使われています。

AWS Fargate の AWS Graviton2 のサポートを発表 – サーバーレスコンテナのコストパフォーマンスが最大 40% 向上 | Amazon Web Services

AWS Graviton2 プロセッサは、64 ビットの Arm Neoverse コアを使用して AWS が

aws.amazon.com

しかし、IntelCPU(X86)の方はどのCPUを使用しているか明記されていないようですので、実験して調べました。

結果、以下のいづれかが使われていることがわかりました！

• Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz
  • • EC2 M6i インスタンス 相当(以下の公式サイトの記述よりM6iという認識)

  • 最大 3.5 GHz の第 3 世代インテル Xeon スケーラブルプロセッサ (Ice Lake 8375C)

  

  インスタンスタイプ - Amazon EC2 | AWS

  Amazon EC2 では、異なるユースケースに合わせて最適化されたさまざまなインスタンスタイプが用意されています。インスタンスタイプはさまざまな CPU、メモリ、ストレージ、ネットワークキャパシティーの組み合わせによって構成されているため、アプリケーションのリソースとして適切な組み合わせを柔軟に選択できます。

  

  aws.amazon.com

• Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz
  • • EC2 C5 インスタンス 相当(以下の公式サイトの記述よりC5という認識)

  • 第 2 世代カスタムインテル Xeon スケーラブルプロセッサ (Cascade Lake 8275CL) を搭載しています。

  

  インスタンスタイプ - Amazon EC2 | AWS

  Amazon EC2 では、異なるユースケースに合わせて最適化されたさまざまなインスタンスタイプが用意されています。インスタンスタイプはさまざまな CPU、メモリ、ストレージ、ネットワークキャパシティーの組み合わせによって構成されているため、アプリケーションのリソースとして適切な組み合わせを柔軟に選択できます。

  

  aws.amazon.com

結果を書いてしまいましたが、上記結果に至るまでの調査方法を書いていきます。

調査方法

以下のDockerイメージを使わせていただきました。

Docker

hub.docker.com

上記Dockerイメージでは、コンテナ起動時にログにCPU名が出力されるので、ログを見てCPUを確認するという調査方法です。

まずは、クラスターを作成します！

クラスター作成

AWSマネージメントコンソール画面のECSダッシュボードから「クラスターの作成」ボタンを押下し、以下の設定でクラスターを作成します。

• クラスター名：適切な名前
• 上記以外、デフォルトのまま

次はタスク定義を作成します！

タスク定義の作成

AWSマネージメントコンソール画面のECSダッシュボードからタスク定義を選択し、「新しいタスク定義の作成」ボタンを押下し、以下の設定でタスク定義を作成する

• タスク定義とコンテナの設定
  • タスク定義ファミリー：適切な名前
  • コンテナ – 1
    • 名前：適切な名前
    • イメージ URI：actions/lscpu:latest
    • 上記以外デフォルトのまま
  • 環境、ストレージ、モニタリング、タグの設定
    • 環境
      • CPU：.5VCPU
      • メモリ：1GB
  • 上記以外デフォルトのまま

次はタスクの作成(コンテナ立ち上げ)です！

タスクの作成

AWSマネージメントコンソール画面のECSダッシュボードで作成したクラスターを選択し、タスクタブ押下して、「新しいタスクの実行」ボタンを押下し、以下の設定で作成します。（このステップでコンテナを立ち上がります）

• デプロイ設定
  • ファミリー：作成したタスク定義を指定
  • 上記以外デフォルトのまま
• 必要なタスク：5

• 上記以外はデフォルトのまま

調査結果

上記でタスクを立ち上げ、ログを確認したところ、CPUは以下の通りでした。

Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz

Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz

Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz

Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz

Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz

まとめ

FargateでIntelCPU(X86)選択時に、どのCPUが使用されるかについて、明記されていなかったので、CPUにばらつきがある(起動タイミングによってCPUが変わる)のかなと思ったりしてました。

調査したところ、多少のばらつきはあり、EC2 M6iまたはC5 インスタンス相当のCPUが使われているという結果でした！

以下のような方向けです。

ECSでのコンテナ立ち上げは、以下の3ステップで簡単にできますので、まずはコンテナを立ち上げて、そこから理解を深めていきましょ！

なお、本記事では、Nginxのコンテナを立ち上げていきます。

 それでは早速コンテナを立ち上げていきます。

まずは、クラスターを作成します！

クラスター作成

AWSマネージメントコンソール画面のECSダッシュボードから「クラスターの作成」ボタンを押下し、以下の設定でクラスターを作成します。

• クラスター名：適切な名前
• 上記以外、デフォルトのまま

次はタスク定義を作成します！

タスク定義の作成

AWSマネージメントコンソール画面のECSダッシュボードからタスク定義を選択し、「新しいタスク定義の作成」ボタンを押下し、以下の設定でタスク定義を作成する

• タスク定義とコンテナの設定
  • タスク定義ファミリー：適切な名前
  • コンテナ – 1
    • 名前：適切な名前
    • イメージ URI：nginx:latest   
      • 本記事ではNginxを指定しています
        • 他のコンテナを立ち上げたい場合は、立ち上げたいコンテナイメージを指定します
          • docker hubのイメージであれば、docker pullするときのイメージ名で指定できます。

            docker pull {イメージ名}

    • 上記以外デフォルトのまま
  • 環境、ストレージ、モニタリング、タグの設定
    • 環境
      • CPU：.5VCPU
      • メモリ：1GB
  • 上記以外デフォルトのまま

次はタスクの作成(コンテナ立ち上げ)です！

タスクの作成

AWSマネージメントコンソール画面のECSダッシュボードで作成したクラスターを選択し、タスクタブ押下して、「新しいタスクの実行」ボタンを押下し、以下の設定で作成します。（このステップでコンテナを立ち上がります）

• デプロイ設定
  • ファミリー：作成したタスク定義を指定
  • 上記以外デフォルトのまま
• ネットワーキング
  • セキュリティグループ
    • ポート80を許可

Fargate-セキュリティグループの設定

• 上記以外はデフォルトのまま

動作確認

• タスクタブからタスクのリンクを押下する
• パブリック IPが表示されるのでパブリックIPでHTTPアクセスする

  • http://パブリックIP
    

以下の画面が表示されればOKです。

welcome-nginx

動作確認後はタスクを終了しておきましょー

まとめ

ECS-Fargeteでは

といったことをやれば、コンテナが立ち上げることがわかったと思います。

また、思ったより簡単にコンテナが立ち上げられたと思います。

実際の本番稼働には

• ロードバランサーなどのネットワーク周りの知識
• ECSにはサービスという概念もあるため、サービスという概念の知識
• ECSの各設定に対する深い知識

が必要になってきますが、まずは本記事のようにコンテナを立ち上げて、そこから理解を深めていくのがいいと考えています。

↓Fargateの公式記事です↓

AWS Fargate（サーバーやクラスターの管理が不要なコンテナの使用）| AWS

AWS Fargate は、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes (EKS) の両方で動作する、コンテナ向けのサーバーレスコンピューティングエンジンです。

aws.amazon.com

↓Fargateのオートスケーリング関連の記事です↓

Elastic Container Service(ECS) Fargateの2つのオートスケーリング設定

Elastic Container Service(ECS)のオートスケーリング設定は「リソースの負荷に応じたオートスケーリング設定」「時間に応じたオートスケーリング設定」が設定可能。 「リソースの負荷に応じたオートスケーリング」「時間に応じたオートスケーリング」を組み合わせ、メリットを活かし、注意点を補う設定が可能

it.kensan.net

2023.03.06

↓Fargateの負荷対策関連の記事です↓

Elastic Container Service(ECS) Fargate 高負荷時の対策ーメモリ使用率とCPU使用率

ECS Fargateの高負荷時の対策 「CPU使用率が高いケース」 「メモリ使用率が高いケース」 について記載します。 「スケールアウト：タスク数を増やす」 「スケールアップ：１タスクのCPUやメモリを大きくする」 「新しいデプロイの強制：タスクを全て入れ替える」 といった対策があります。

it.kensan.net

2023.03.11

高負荷時は、基本的には以下の対応となりますが、基本に通りに進める時間的余裕がないことが多いと思います。

本記事では、上記を実施する時間的余裕がない場合に、応急処置として、インフラ強化で対応できることを記載していきます。

高負荷状態を放置するとコンテナが落ちて、処理中のデータが失われてしまうこともあるので、緊急時はインフラ強化で対策しておきましょ！

上記のケースで、どのように対応すれば良いか記載していきます。

まず、上記の3つの高負荷時の対策について、具体的にどんな対策となるか、対策の中身を記載していきます。

高負荷時の対策

高負荷時の対策について、具体的には以下のような対策となります。

次に、どんな時にどの対策を行えば良いか考えていきます。

CPU使用率が高いケース

CPU使用率が高い場合は以下の対応が基本となります。

アクセス数が増えて高負荷になっている場合、タスク数を増やすことで、多くのアクセスを捌けるようになるため、スケールアウトすれば良いという考えです。

重い処理が多くて捌き切れない場合、タスク数を増やしても、重い処理が１つのタスクに集中してしまうと捌けなくなってしまうため、スケールアップが効果的であるという考えです。

次は、メモリ使用率が高いケースについて考えていきます。

メモリ使用率が高いケース

メモリ使用率が高い場合は以下の対応が基本となります。

アクセス数が増えて高負荷になっている場合、タスク数を増やすことで、多くのアクセスを捌けるようになるため、スケールアウトすれば良いという考えです。

メモリ使用量が多い処理が多くて捌き切れない場合、タスク数を増やしても、重い処理が１つのタスクに集中してしまうと捌けなくなってしまうため、スケールアップが効果的であるという考えです。

メモリ断片化でメモリ使用率が上がり続ける場合、タスクの入れ替えをすれば、メモリ断片化されていないタスクのみに切り替わるため、新しいデプロイの強制が有効と考えています。

どのような対策をすべきかわかったところで、具体的に

・スケールアウト

・スケールアップ

・新しいデプロイの強制

の実施方法について記載していきます。

スケールアウト・スケールアップ・新しいデプロイの強制を実施する方法

具体的な手順について記載していきます。

まずはスケールアウトから

スケールアウト

AWSマネージメントコンソールのECS画面から、サービスの編集画面を開き、「必要なタスク」を増やして更新します。

「必要なタスク」は以下の画面の赤線の場所から編集できます！

ECS タスク数を増やして、スケールアウトする

上記のように、手動でタスク数を変更することも可能ですが、オートスケーリングを設定しておくのがスマートかと思います。

オートスケーリングの設定は以下の記事をご参照ください。

Elastic Container Service(ECS) Fargateの2つのオートスケーリング設定

Elastic Container Service(ECS)のオートスケーリング設定は「リソースの負荷に応じたオートスケーリング設定」「時間に応じたオートスケーリング設定」が設定可能。 「リソースの負荷に応じたオートスケーリング」「時間に応じたオートスケーリング」を組み合わせ、メリットを活かし、注意点を補う設定が可能

it.kensan.net

2023.03.06

スケールアップ

タスク定義からCPU・メモリの性能を更新し、サービスの「新しいデプロイの強制」をONにして更新します。

「CPU」「メモリ」の性能は以下の画面の赤線の場所から編集できます！

新しいデプロイの強制はこちらをご参照ください。

ECS タスクの性能を修正して、スケールアップする

新しいデプロイの強制

サービスの編集画面を開き、「新しいデプロイの強制」のONにして更新します。

「新しいデプロイの強制」は以下の画面の赤線の場所から編集できます！

ONにして更新すると、タスクの入れ替えが行われます。

新しいデプロイの強制

「新しいデプロイの強制」は、新しいコンテナを起動し、稼働中のコンテナを停止する挙動になりますが、停止するコンテナの挙動は以下の通りとなります。

更新中にサービススケジューラがタスクを置き換えるとき、サービスはまずロードバランサーからタスクを削除し (使用されている場合)、接続のドレインが完了するのを待ちます。その後、タスクで実行されているコンテナに docker stop と同等のコマンドが発行されます。この結果、SIGTERM 信号と 30 秒のタイムアウトが発生し、その後に SIGKILL が送信され、コンテナが強制的に停止されます。コンテナが SIGTERM 信号を正常に処理し、その受信時から 30 秒以内に終了する場合、SIGKILL 信号は送信されません。

コンソールを使用したサービスの更新 - Amazon Elastic Container Service

Amazon ECS コンソールを使用して、Amazon ECS サービスを更新する方法を説明します。

docs.aws.amazon.com

まとめ

以下の負荷のケースと対策について記載しました。

スケールアップ・スケールアウト・新しいデプロイの強制を適切に使って乗り越えていきましょー