AWS SOCI (Seekable OCI) は、Fargateのコンテナ起動時間を短縮するための技術です。

Railsのような比較的大きなイメージ（数百MB〜1GB）を使う場合、従来は「イメージの全ダウンロード完了」を待ってから起動していましたが、Seekable OCIを使うと「必要な部分だけ先にダウンロードして即起動（Lazy Loading）」が可能になります。

今回は「ECRにプッシュしたら勝手にインデックスを作ってくれる仕組み（Lambda）」 を用意して、実際にコンテナを立ち上げてみます。

Seekable OCIを使ってみる

「ECRにプッシュしたら勝手にインデックスを作ってくれる仕組み（Lambda）」 は、AWS SOCI Index BuilderというAWS公式のCloudFomaritonテンプレートが用意されています。

これを使って「ECRにプッシュしたら勝手にインデックスを作ってくれる仕組み（Lambda）」 を構築します。

「ECRにプッシュしたら勝手にインデックスを作ってくれる仕組み（Lambda）」の構築

以下のCloudFormationファイルを使用します。

https://aws-quickstart.s3.us-east-1.amazonaws.com/cfn-ecr-aws-soci-index-builder/templates/SociIndexBuilder.yml

aws-quickstart.s3.us-east-1.amazonaws.com

以下のようにスタック作成してリソースを作成します。（パラメータは必要に応じて変更）

今回はRails8.1のコンテナイメージをPushしてみます。

Railsコンテナイメージの作成

ローカルにRailsインストールして、Railsアプリを作成してみます。

以下のコマンドでRailsインストール

sudo gem install rails

以下のコマンドでRailsアプリ作成して、作成したディレクトリに移動

rails new my-app
cd my-app

バージョン確認

rails -v
Rails 8.1.1

Dockerfileも作成されているので「vi Dockerfile」で確認できます。

今回はテスト用なので、Dockerfileを以下のように変更します。

「ENV RAILS_ENV="production"」をコメントアウトして、「ENV RAILS_ENV=development」を追記します。
#ENV RAILS_ENV="production" \
ENV RAILS_ENV=development\

以下のようにENTRYPOINTをコメントアウト
#ENTRYPOINT ["/rails/bin/docker-entrypoint"]

以下のようにEXPOSEとCMDを変更
#EXPOSE 80
#CMD ["./bin/thrust", "./bin/rails", "server"]

EXPOSE 3000
CMD ["bundle", "exec", "puma", "-C", "config/puma.rb"]

config/environments/development.rbに以下を追記します。これがないとFargateで確認時にエラーになります。

config.hosts.clear

コンテナイメージの動作確認

まずはビルドします。

docker build -t rails-demo .

次にコンテナ起動です。

docker run -d -p 3000:3000 \
  -e RAILS_MASTER_KEY=$(cat config/master.key) \
  --name my-app \
  rails-demo

http://localhost:3000/にアクセスして以下のwelcome画面が出ればokです。

Rails8.1のコンテナイメージをECRに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 rails-demo: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

Push結果

Pushしてしばらくすると、以下のようにECRにSoci Indexが追加されます。

このSoci Indexがコンテナ立ち上げを高速化してくれます。

ECS-Fargateでコンテナを立ち上げてみる

ECS-Fargateの設定は以下をご参照ください

Rails7.1をfargateで動かしてみる

Rails7.1をECS(Amazon Elastic Container Service)-Fagateにデプロイします！！！ 以下の順で進めていきます。今回はとりあえずFargate上で動くことをゴールにしますので、MySQLは使いませ

it.kensan.net

コンテナのパブリックIPにアクセスして以下のように表示されればOKです。

起動時間を見てみる

Seekable OCIの場合

以下のコマンドで確認します。

aws ecs describe-tasks \
  --cluster <クラスター名> \
  --tasks <タスクID> \
  --query "tasks[0].{CreatedAt:createdAt, PullStarted:pullStartedAt, PullStopped:pullStoppedAt, StartedAt:startedAt}"

以下の結果が返ってきました。

{
    "CreatedAt": "2025-12-28T10:39:06.054000+09:00",
    "PullStarted": "2025-12-28T10:39:17.362000+09:00",
    "PullStopped": "2025-12-28T10:39:27.310000+09:00",
    "StartedAt": "2025-12-28T10:39:28.900000+09:00"
}

作成からスタートまで21秒程度です。

Seekable OCIなしの場合

Seekable OCIなしの場合は以下の結果でした。

{
    "CreatedAt": "2025-12-28T10:35:07.750000+09:00",
    "PullStarted": "2025-12-28T10:35:22.546000+09:00",
    "PullStopped": "2025-12-28T10:35:34.311000+09:00",
    "StartedAt": "2025-12-28T10:35:37.096000+09:00"
}

作成からスタートまで30秒です。

まとめ

Seekable OCIでコンテナ起動の高速化をやってみました。

実際の本番運用するRailsアプリでどのくらい高速化するかやってみたいと思います！

私はassetsファイルなどの静的ファイルをサーバで配信することが多いのですが、本当はS3において、さらにCloudFrontなどのCDNでキャッシュした方が良いよなと思っていました。

が、、ちょっと面倒で後回しになっていたので、実際にサーバ負荷を確認して、静的ファイルをS3に移動させる労力に見合う結果が得られそうか確認したいと思います。

今回の検証では、サーバはECS Fargateで、1vCPU/2GBを使います。

ECS Fargateは以下の記事のようにたてられます。

AWS ECS-Fagate-Express モードで簡単にコンテナアプリケーションをデプロイしてみる

AWS ECS-Fagate-Express モードで簡単にコンテナアプリケーションをデプロイしてみます！ ECS-Fagate-Express モードでは以下のような設定が簡単に行えます。 ACM ALB ECS オートスケール設定 以下

it.kensan.net

assets/images配下に、100KBの画像を格納して、その画像ファイルにjmeterで大量アクセスした際の負荷を検証してみます。

準備

以下のようにFargateコンテナを立ち上げます。

AWS ECS-Fagate-Express モードで簡単にコンテナアプリケーションをデプロイしてみる

AWS ECS-Fagate-Express モードで簡単にコンテナアプリケーションをデプロイしてみます！ ECS-Fagate-Express モードでは以下のような設定が簡単に行えます。 ACM ALB ECS オートスケール設定 以下

it.kensan.net

assets/images配下に100KBの画像を格納します。

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

docker build -t rails-demo .

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

docker run -d -p 3000:3000 \
  -e RAILS_MASTER_KEY=$(cat config/master.key) \
  --name my-app \
  rails-demo

100KBの画像のパスを取得するため、コンテナにbashで入ります

＜コンテナID確認＞
docker ps -a
＜コンテナにbashではいる＞
docker exec -it {コンテナID} /bin/bash

以下のコマンドでパスを取得できます。

bundle exec rails c
helper.asset_url("100KB.png")

jmeter準備

macの場合以下のコマンドでインストールできます

brew install jmeter

インストールしたら

jmeter

とターミナルに打ち込むとjmeterが起動します。

jmeter設定

以下の設定で1分間かけて50スレッド立ち上がるようにします。そのあとは4分間継続して負荷を描けます

Thread Group
  Number of Threads:50
  Ramp-up:60
  Duration:300

Constant Throughput Timer
 Target throughput:3000

HTTP Request
  protocol:https
  Server Name or ip:ECSのドメイン
  Path:{helper.asset_url("100KB.png")の結果}

14%とそれほど高いとも言えず、何とも言えない結果ですが、利用者数が増えるほど無視できない負荷になることも考えられると思います。

そのため、以下のような対応が必要と思われます…!

• CloudFrontなどのCDNでのキャッシュ
• そもそもassetsファイルはS3などにおき、サーバにリクエストが来ないようにする
  • S3に置いたうえで、CDNでキャッシュもした方が良さそう

ECS-Fagate-Express モードでは以下のような設定が簡単に行えます。

• ACM
• ALB
• ECS
• オートスケール設定

以下の記事を試してみる感じです。

Amazon ECS Express Mode を使用して、インフラストラクチャを複雑化することなく、本番環境に対応したアプリケーションを構築 | Amazon Web Services

コンテナ化されたアプリケーションを本番環境にデプロイするには、ロードバランサー、自動スケーリングポリシー、ネッ

aws.amazon.com

ざっくり以下のような感じでECS-Fagate-Express モードを試してみます！

1. テスト用のコンテナイメージをECRにPush
   1. 試しにRails8.1のコンテナイメージをPushします
2. ECSコンソールに移動して、Expressモードを選択して、設定してみる

テスト用のコンテナイメージをECRにPush

テスト用のコンテナイメージをECRにPushします。

今回はRails8.1のコンテナイメージをPushします。

Railsコンテナイメージの作成

ローカルにRailsインストールして、Railsアプリを作成してみます。

以下のコマンドでRailsインストール

sudo gem install rails

以下のコマンドでRailsアプリ作成して、作成したディレクトリに移動

rails new my-app
cd my-app

バージョン確認

rails -v
Rails 8.1.1

Dockerfileも作成されているので「vi Dockerfile」で確認します。

以下のようになっていると思います。

# syntax=docker/dockerfile:1
# check=error=true

# This Dockerfile is designed for production, not development. Use with Kamal or build'n'run by hand:
# docker build -t my_app .
# docker run -d -p 80:80 -e RAILS_MASTER_KEY= --name my_app my_app

# For a containerized dev environment, see Dev Containers: https://guides.rubyonrails.org/getting_started_with_devcontainer.html

# Make sure RUBY_VERSION matches the Ruby version in .ruby-version
ARG RUBY_VERSION=3.4.2
FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base

# Rails app lives here
WORKDIR /rails

# Install base packages
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y curl libjemalloc2 libvips sqlite3 && \
    ln -s /usr/lib/$(uname -m)-linux-gnu/libjemalloc.so.2 /usr/local/lib/libjemalloc.so && \
    rm -rf /var/lib/apt/lists /var/cache/apt/archives

# Set production environment variables and enable jemalloc for reduced memory usage and latency.
ENV RAILS_ENV="production" \
    BUNDLE_DEPLOYMENT="1" \
    BUNDLE_PATH="/usr/local/bundle" \
    BUNDLE_WITHOUT="development" \
    LD_PRELOAD="/usr/local/lib/libjemalloc.so"

# Throw-away build stage to reduce size of final image
FROM base AS build

# Install packages needed to build gems
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y build-essential git libyaml-dev pkg-config && \
    rm -rf /var/lib/apt/lists /var/cache/apt/archives

# Install application gems
COPY Gemfile Gemfile.lock vendor ./

RUN bundle install && \
    rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git && \
    # -j 1 disable parallel compilation to avoid a QEMU bug: https://github.com/rails/bootsnap/issues/495
    bundle exec bootsnap precompile -j 1 --gemfile

# Copy application code
COPY . .

# Precompile bootsnap code for faster boot times.
# -j 1 disable parallel compilation to avoid a QEMU bug: https://github.com/rails/bootsnap/issues/495
RUN bundle exec bootsnap precompile -j 1 app/ lib/

# Precompiling assets for production without requiring secret RAILS_MASTER_KEY
RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile




# Final stage for app image
FROM base

# Run and own only the runtime files as a non-root user for security
RUN groupadd --system --gid 1000 rails && \
    useradd rails --uid 1000 --gid 1000 --create-home --shell /bin/bash
USER 1000:1000

# Copy built artifacts: gems, application
COPY --chown=rails:rails --from=build "${BUNDLE_PATH}" "${BUNDLE_PATH}"
COPY --chown=rails:rails --from=build /rails /rails

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start server via Thruster by default, this can be overwritten at runtime
EXPOSE 80
CMD ["./bin/thrust", "./bin/rails", "server"]

今回はテスト用なので、Dockerfileを以下のように変更します。

「ENV RAILS_ENV="production"」をコメントアウトして、「ENV RAILS_ENV=development」を追記します。
#ENV RAILS_ENV="production" \
ENV RAILS_ENV=development\

以下のようにENTRYPOINTをコメントアウト
#ENTRYPOINT ["/rails/bin/docker-entrypoint"]

以下のようにEXPOSEとCMDを変更
#EXPOSE 80
#CMD ["./bin/thrust", "./bin/rails", "server"]

EXPOSE 3000
CMD ["bundle", "exec", "puma", "-C", "config/puma.rb"]

config/environments/development.rbに以下を追記します。これがないとFargateで確認時にエラーになります。

config.hosts.clear

コンテナイメージの動作確認

まずはビルドします。

docker build -t rails-demo .

次にコンテナ起動です。

docker run -d -p 3000:3000 \
  -e RAILS_MASTER_KEY=$(cat config/master.key) \
  --name my-app \
  rails-demo

http://localhost:3000/にアクセスして以下のwelcome画面が出ればokです。

Rails8.1のコンテナイメージをECRに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 rails-demo: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

ECSコンソールに移動して、Expressモードを選択して、設定してみる

1. ECSコンソールに移動します
2. Expressモードを選択します
   1. イメージ URIでは先ほどpushしたECRのイメージを選択します
   2. その他の設定のコンテナポートは3000を指定します。
3. 作成ボタン押下

Expressモードで作成時はCPUアーキテクチャを設定できないようです。

ARMを使う場合は、作成後にタスク定義からCPUアーキテクチャを変更する必要あがあります。

動作確認

ECSコンソールのアプリケーション URLにアクセスすると以下のようにRailsが起動できました！

以下のようにオートスケールも自動的に設定されています。

素晴らしいー

以下の順で進めていきます。今回はとりあえず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です。

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

https://it.kensan.net/it/laravel11-log.html

localhost

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

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

AWS について

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)

  

  インスタンスタイプ

  

  aws.amazon.com

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

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

  

  インスタンスタイプ

  

  aws.amazon.com

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

調査方法

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

actions/lscpu - Docker Image

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のオートスケーリング関連の記事です↓

https://it.kensan.net/it/ecs-autoscaling.html

localhost

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

https://it.kensan.net/it/elastic-container-serviceecs-fargate-load.html

localhost

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

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

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

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

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

高負荷時の対策

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

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

CPU使用率が高いケース

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

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

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

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

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

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

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

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

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

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

・スケールアウト

・スケールアップ

・新しいデプロイの強制

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

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

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

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

スケールアウト

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

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

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

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

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

https://it.kensan.net/it/ecs-autoscaling.html

localhost

スケールアップ

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

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

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

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

新しいデプロイの強制

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

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

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

新しいデプロイの強制

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

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

Amazon ECS サービスを更新する - Amazon Elastic Container Service

Amazon ECS サービスを更新する方法について説明します。

docs.aws.amazon.com

まとめ

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

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