rails | さゆフィクション

Fargate上のRailsアプリを高速でオートスケールさせる

sayu — Fri, 02 Jan 2026 22:17:40 +0000

Fargate上のRailsアプリを高速でオートスケールさせてみます。

FargateをCPUやメモリなどの標準メトリクスでオートスケールさせると、CloudWatchにメトリクスが送られるまで1~2分程度の遅延が発生すると思います。

さらにCloudWatchアラームでの評価に1分程度かかり

さらにコンテナ起動まで（オートスケール完了まで）1~2分程度かかります。

そのため、オートスケールを設定していてもスケールまで5分程度かかります。

このままですと急なアクセス増に対応できないため、オートスケールの時間を減らしたいと思います！！

どのようにオートスケールを早くするか

以下のような感じで対応していきます。

コンテナからカスタムメトリクスの空きスレッド数をCloudWatchへ送る
Fargateのタスク定義・クラスター・サービスを作成
CloudWatchアラームで高解像度の監視をする
アラームに応じてFargateのオートスケールをする

これで、1~3分程度でスケール可能となります。（起動の時間がアプリケーションによって異なると思いますが、大体この範囲に収まると思います！）

やってみる！

RailsコンテナからカスタムメトリクスをCloudWatchへ送る

Gemfileの修正

以下を追記します。

gem 'aws-sdk-cloudwatch'

cloudwatch_metrics.rbの作成

「config/initializers/cloudwatch_metrics.rb」を以下の内容で作成します。


# config/initializers/cloudwatch_puma_metrics.rb
require 'aws-sdk-cloudwatch'
require 'net/http'
require 'json'

CLOUDWATCH = Aws::CloudWatch::Client.new(region: 'ap-northeast-1')


Thread.new do
  loop do
    begin
      sleep 10
      Rails.logger.info("Sending Puma metrics to CloudWatch")
      uri = URI('http://127.0.0.1:9293/stats')
      res = Net::HTTP.start(uri.host, uri.port, open_timeout: 1, read_timeout: 1) do |http|
        http.get(uri.request_uri)
      end

      stats = JSON.parse(res.body)
      Rails.logger.info(stats.inspect)
      capacity = stats['pool_capacity']

      CLOUDWATCH.put_metric_data(
        namespace: 'Custom/Puma',
        metric_data: [
          {
            metric_name: 'ThreadPoolCapacity',
            value: capacity,
            unit: 'Count',
            storage_resolution: 1,
            dimensions: [
              { name: 'Cluster', value: ENV['ECS_CLUSTER'] || 'default' },
              { name: 'Service', value: ENV['ECS_SERVICE_NAME'] || 'rails' }
            ]
          }
        ]
      )
     
    rescue => e
      Rails.logger.error("CloudWatch Puma metric error: #{e.class}: #{e.message}")
    end
  end
end

lib/request_counter.rbの作成

lib/request_counter.rbを以下の内容で作成します。


class RequestCounter
  def initialize(app)
    @app = app
  end

  def call(env)
    REQUEST_COUNTER.increment
    @app.call(env)
  end
end

config/puma.rbの編集

config/puma.rbに以下を追記します。

activate_control_app 'tcp://127.0.0.1:9293', { no_token: true }

Railsのコンテナイメージを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

Fargateのタスク定義・クラスター・サービスの作成

タスク定義

以下の設定でタスク定義を作成します。

イメージ URIにECRのURI
コンテナポートを3000

クラスター

以下の設定でクラスターを作成します。

コンピューティングキャパシティの取得方法を選択でfargateのみを選択

サービス

以下の設定でサービスを作成します。

タスク定義ファミリーで作成したタスク定義を指定
ロードバランシング – オプション
- ロードバランシングを使用にチェック
- 新しいロードバランサーの作成にチェック
- 新しいリスナーを作成にチェック
- 新しいターゲットグループの作成にチェック
  - ポートは3000に設定

CloudWatchアラームで高解像度の監視をする

アラームの作成を以下の設定で作成します

メトリクス：ThreadPoolCapacity
統計：最小
期間：10秒
条件
- ThreadPoolCapacityが３より小さい

アラームに応じてFargateのオートスケールをする

Fargateのサービスの画面からサービスの自動スケーリングの設定をします。以下のような流れで設定します。

スケーリングポリシーを作成
ステップスケーリングを指定
カスタムオプションを指定
スケールアウトを指定
CloudWatch アラームで作成したアラームを指定
1. 「調整」でスケールするタスク数などを指定

動作確認

JmeterでロードバランサのエンドポイントにHTTPリクエストを送りアラーム状態にすると、90秒程度でコンテナ起動する（ロードバランサのターゲットに登録されるところまで90秒程度）ことが確認できました。

通常5分程度かかるスケーリングが90秒程度でできたので効果ありと思っています。

なお、本検証は以下のSOCI対策を入れた状態で行いました！

AWS ECS-FagateをSeekable OCIを使って高速起動してみる

AWS ECS-FagateをSeekable OCIを使って高速起動してみます。 AWS SOCI (Seekable OCI) は、Fargateのコンテナ起動時間を短縮するための技術です。 Railsのような比較的大きなイメージ（数百

AWS ECS-FagateをSeekable OCIを使って高速起動してみる

sayu — Sun, 28 Dec 2025 01:45:52 +0000

AWS ECS-FagateをSeekable OCIを使って高速起動してみます。

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

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

今回は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は使いませ

コンテナのパブリック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アプリでどのくらい高速化するかやってみたいと思います！

Railsのassetsファイルをサーバで配信した場合の負荷を検証してみる

sayu — Sat, 27 Dec 2025 08:41:28 +0000

Railsのassetsファイルなどの静的ファイルをサーバで配信した場合の負荷を検証してみます。

私は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 オートスケール設定以下

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

準備

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

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

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

以下の設定で3000アクセスに設定します。1分で3000アクセスなので、秒間50アクセスです。

Constant Throughput Timer
 Target throughput:3000

以下の設定で画像にアクセスするようにします。

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

確認結果

秒間50アクセスを5分間継続したところ、CPU使用率は14%程度になりました。

サーバはECS Fargateで、1vCPU/2GBです。

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

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

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

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

sayu — Sat, 27 Dec 2025 06:27:56 +0000

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

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

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

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

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

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

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

テスト用のコンテナイメージをECRにPush
1. 試しにRails8.1のコンテナイメージをPushします
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モードを選択して、設定してみる

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

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

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

動作確認

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

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

素晴らしいー

Rails 7.2をインストールして起動してみる

sayu — Sat, 01 Jun 2024 01:32:38 +0000

この記事では、Rails 7.2をインストールし、起動するまでの手順を説明します。

具体的には以下のブランチのRails7.2を起動する方法を記載していきます。

GitHub - rails/rails at 7-2-stable

Ruby on Rails. Contribute to rails/rails development by creating an account on GitHub.

Railsプロジェクト作成

まず、以下のコマンドで新しいRailsプロジェクトを作成し、そのプロジェクトディレクトリに移動します。

rails new test_app

cd test_app/

次に、Railsのバージョンを確認します。

rails -v

Rails 7.1.3.3

この時点では、Rails 7.1系がインストールされているはずです。

Rails7.2へアップデート

Rails 7.2にアップデートするために、Gemファイルを修正します。

vi Gemfile

以下の内容でGemfileを修正します。

#gem "rails", "~> 7.1.3", ">= 7.1.3.3"     #コメントアウト

gem "rails", github: "rails/rails", branch: "7-2-stable"     #これを追加

次に、以下のコマンドでRails 7.2にアップデートします。

bundle install

動作確認

最後に、以下のコマンドでサーバを立ち上げます。

rails server

ブラウザでhttp://localhost:3000/にアクセスし、「Rails version: 7.2.0」と表示されていれば成功です。

以上で、Rails 7.2のインストールと起動が完了です。

まとめ

以下のブランチを指定して、Rails7.2を起動する方法を記載しました！

GitHub - rails/rails at 7-2-stable

Ruby on Rails. Contribute to rails/rails development by creating an account on GitHub.