rails | さゆフィクション http://it.kensan.net aws wordpress などなどゆるーく書いてます Fri, 02 Jan 2026 22:17:40 +0000 ja hourly 1 https://wordpress.org/?v=6.9 https://it.kensan.net/wp-content/uploads/2023/03/cropped-icon-32x32.png rails | さゆフィクション http://it.kensan.net 32 32 Fargate上のRailsアプリを高速でオートスケールさせる https://it.kensan.net/high-speed-fargate-auto-scale.html Fri, 02 Jan 2026 22:17:40 +0000 https://it.kensan.net/?p=2284 Fargate上のRailsアプリを高速でオートスケールさせてみます。

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

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

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

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

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

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

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

  1. コンテナからカスタムメトリクスの空きスレッド数をCloudWatchへ送る
  2. Fargateのタスク定義・クラスター・サービスを作成
  3. CloudWatchアラームで高解像度の監視をする
  4. アラームに応じて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が3より小さい

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

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

  1. スケーリングポリシーを作成
  2. ステップスケーリングを指定
  3. カスタムオプションを指定
  4. スケールアウトを指定
  5. 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のような比較的大きなイメージ(数百
]]>
Railsのassetsファイルをサーバで配信した場合の負荷を検証してみる https://it.kensan.net/rails%e3%81%aeassets%e3%83%95%e3%82%a1%e3%82%a4%e3%83%ab%e3%82%92%e3%82%b5%e3%83%bc%e3%83%90%e3%81%a7%e9%85%8d%e4%bf%a1%e3%81%97%e3%81%9f%e5%a0%b4%e5%90%88%e3%81%ae%e8%b2%a0%e8%8d%b7%e3%82%92%e6%a4%9c.html Sat, 27 Dec 2025 08:41:28 +0000 https://it.kensan.net/?p=2249 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 モードで簡単にコンテナアプリケーションをデプロイしてみる
AWS ECS-Fagate-Express モードで簡単にコンテナアプリケーションをデプロイしてみます! ECS-Fagate-Express モードでは以下のような設定が簡単に行えます。 ACM ALB ECS オートスケール設定 以下

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 モードで簡単にコンテナアプリケーションをデプロイしてみる https://it.kensan.net/aws-ecs-fagate-express-mode-rails.html Sat, 27 Dec 2025 06:27:56 +0000 https://it.kensan.net/?p=2243 AWS ECS-Fagate-Express モードで簡単にコンテナアプリケーションをデプロイしてみます!

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

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

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

Amazon ECS Express Mode を使用して、インフラストラクチャを複雑化することなく、本番環境に対応したアプリケーションを構築 | Amazon Web Services
コンテナ化されたアプリケーションを本番環境にデプロイするには、ロードバランサー、自動スケーリングポリシー、ネッ

ざっくり以下のような感じで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が起動できました!

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

素晴らしいー

]]>
Rails 7.2をインストールして起動してみる https://it.kensan.net/rails7-2-install.html Sat, 01 Jun 2024 01:32:38 +0000 http://52.192.132.163/it/?p=1983 この記事では、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.

 

]]>
Rails7.1をfargateで動かしてみる https://it.kensan.net/rails7-1-fargate.html Sat, 18 May 2024 06:53:21 +0000 http://43.206.130.170/it/?p=1931 Rails7.1をECS(Amazon Elastic Container Service)-Fagateにデプロイします!!!

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

]]>
Rails7.1をローカル環境で動かしてみる https://it.kensan.net/rails7-1-local.html Sat, 18 May 2024 06:39:28 +0000 http://43.206.130.170/it/?p=1928 Rails7.1をローカル環境で動かしてみます!

PC上で直接動かし、その後にDockerコンテナ上で動かしてみます。

コンテナでは、rails newで作成された公式のDockerfileを使用していきます。

Ruby・Railsのインストールから始めていきます!

Ruby/Railsのインストール

Rubyインストール

  • rbenvをインストールする
brew install rbenv
  • rbenvからインストールできるRubyのバージョンを確認する
rbenv install -l
  • リスト内から最新バージョンを確認して,Rubyをインストールする(ここでは3.3.1をインストールします)
rbenv install 3.3.1
rbenv global 3.3.1
  • rbenvのRubyに切り替えます
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
source ~/.zprofile

Railsインストール

  • Railsをインストールします
sudo gem install rails

rails --version

Rails 7.1.3.3

Rails7.1がインストールできました。

アプリケーションの作成

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

rails new test_app

cd test_app/

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

以下のコマンドでRailsサーバーを立ち上げます。

bin/rails server

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

PC上にdockerコンテナを立ち上げ、その上でRailsを動かす

dockerコンテナを立ち上げ、その上でRailsを動かします。

まずは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ー

docker composeを使ってみる

docker composeで以下の3つのコンテナを立ち上げてみます。

  •  DBコンテナ
    • MySQL8
  • appコンテナ
    • Rails7.1
  • phpmyadmin
    • 最新のphpmyadmin

Rails アプリの作成

以下のコマンドでRailsアプリを作成します。

rails new . --force --database=mysql

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-compose.ymlの作成

以下の通り作成します。

vi docker-compose.yml

<ファイルの中身>


version: "3"
services:
  app:
    container_name: app_rails
    build:
      args:
        ENVIROMENTS: development
        RAILS_MASTER_KEY: 'cat config/master.key'
    command: bin/rails server -b 0.0.0.0
    volumes:
      - .:/rails
    ports:
      - 80:3000
    tty: true
    stdin_open: true
    depends_on:
      - db
  db:
    image: mysql:8.0.28
    container_name: db
    environment: 
      MYSQL_ROOT_PASSWORD: password
    command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    volumes:  
      - ./docker/db/data:/var/lib/mysql
    ports:
      - 3306:3306
  phpmyadmin:
    container_name: test_phpmyadmin
    image: phpmyadmin
    environment:
    - PMA_USER=root
    - PMA_PASSWORD=password
    ports:
    - 8080:80
    depends_on:
      - db

DB設定ファイルの修正

vi config/database.yml

<ファイルの中身>

default: &default
  adapter: mysql2
  encoding: utf8mb4
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  username: root
  password: password
  host: db

development:
  <<: *default
  database: test4_development

動作確認

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

docker compose up

以下のコマンドでDB作成します。

docker-compose run app bin/rails db:create

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

アプリコンテナのOSを確認してみる

以下のコマンドでOSを確認してみました。

docker compose exec app bash

cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Debian12が使われているようです。

rails newで作成された公式のDockerfileでは、Debian12が使われているようです…!

]]>
Rails7.1へアップデート時に、簡単に、Ransack 4に対応させる方法(NoMethodError: undefined method `table_name’ forの対処法) https://it.kensan.net/rails7-1-ransack-4.html Sun, 05 May 2024 05:37:40 +0000 http://43.207.2.219/it/?p=1840 Rails7.1へアップデート時に、簡単に、Ransack 4に対応させる方法について書いていきます。

Rails7.1へアップデートする場合、Ransack はバージョン4にアップデートする必要があります。

Ransackが古い状態だと以下のエラーになります。

NoMethodError: undefined method `table_name' for

Ransack 4の更新内容

検索・ソートできるDB項目を制限する機能が追加されました。

そのため、Ransackをアップデートすると、検索・ソートできる項目を指定する必要があります。

検索・ソートできる項目を指定しないとエラーになりますが、項目を指定するのは、かなり手間です。

かなり手間なので、簡単な対応方法を記載します。

Ransack 4に簡単に対応する方法

ApplicationRecordクラスに以下のコードを記載するとエラーは消え、今まで通り使えます!


  def self.ransackable_attributes(auth_object = nil)
    # 全ての列を検索可能にする
    authorizable_ransackable_attributes
  end
  def self.ransackable_associations(auth_object = nil)
    # 全ての関連テーブルを検索可能にする
    authorizable_ransackable_associations
  end

本来であれば、検索・ソートできる項目を指定していくのが良いと思いますが、既存アプリのアップデートで時間がない場合など、簡単にRansack 4に対応させたい時は、上記の方法で、今まで通り使えるようになります。

]]>
Railsで非同期処理できるSidekiqの注意点 https://it.kensan.net/sidekiq_info.html Sun, 09 Apr 2023 01:44:44 +0000 http://3.113.9.194/it/?p=1166 Railsでアプリケーションを作っていると非同期処理でSidekiqを使用することが多いと思います。今回はSidekiqを使用する際の注意点について記載していきます。

具体的には

  • リトライ
  • サーバプロセスが落ちると、jobのデータは失われる
  • メモリ肥大化する問題
  • 並列実行数制御

について記載します。

Sidekiqを正しく理解して安全に使おう!という記事になります。

まずはSidekiqとは?について記載していきます。

Sidekiqとは

 Railsで非同期処理を行うためのgemです。複数の非同期処理を同時に実行することができ、サーバリソースを有効活用できます。

以下、処理イメージです。

  1. Rails WEBサーバがリクエストを受け付ける
  2. Rails WEBサーバは非同期でしたい処理をRedisにjobとして格納する
  3. Sidekiqが動いているサーバがRedisからjobを取得する
  4. Sidekiqはjobの内容にしたがって処理を実行する
Simple, efficient background jobs for Ruby
Sidekiq is a simple, efficient framework for background jobs in Ruby

AWS SQSと連携させて、非同期処理を行うShoryukenというgemもあります。

[注意点①]プログラムで例外発生時は、リトライされる

デフォルトのリトライの仕様は以下の通りとなります。約21日間リトライが行われます。

リトライ回数:25回

リトライの間隔:リトライ回数の4乗+15秒間隔くらい。正確な計算式は以下の通り

(retry_count ** 4) + 15 + (rand(10) * (retry_count + 1))

Error Handling
Simple, efficient background processing for Ruby. Contribute to sidekiq/sidekiq development by creating an account on GitHub.

リトライで解消する可能性がある場合は、リトライは有効かと思いますが、何度リトライしても失敗するようなエラーの場合はサーバ負荷をかけるだけなので、リトライさせないようにしておくと良さそうです。

リトライ回数をデフォルトから変更するなど、リトライ時の処理を設計して実装しておきましょ!

[注意点②]サーバプロセスが落ちると、jobのデータは失われる

サーバプロセスが落ちると、jobのデータは失われてしまいます。

Sidekiq Pro(Sidekiqの有料版)のsuper_fetchを使用すると、サーバプロセスが落ちてもjobデータが失われなくなりますので、Sidekiq Proを検討しましょ

Reliability
Simple, efficient background processing for Ruby. Contribute to sidekiq/sidekiq development by creating an account on GitHub.

または、Sidekiqをやめて、Shoryukenの検討をしましょ。

ShoryukenではSQSを使用しますが、サーバプロセスが落ちてもSQSのデータ失われないためです。

[注意点③]メモリ肥大化する問題

大量のメモリを消費する問題があります。

メモリの問題に関しては、以下の記事を参考に設定を変更して対応しましょ

Ruby: mallocでマルチスレッドプログラムのメモリが倍増する理由(翻訳)|TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Malloc Can Double Multi-t

[注意点④]並列実行数制御

大量に同時実行するとインフラ負荷がかかりすぎる場合、並列実行数制御をしましょ!

インフラ負荷とは以下のようなイメージでいます。

  • 大量に同時実行すると
    • Sidekiqが動いているサーバに負荷がかかる
    • DBに負荷がかかる

並列実行数制御にはsidekiq-limit_fetch というgemを使います。

sidekiq-limit_fetch | RubyGems.org | コミュニティのgemホスティングサービス

注意点として、Sidekiq Proを使用している場合、sidekiq-limit_fetchは正常に動作しないので要注意です。

GitHub - deanpcmad/sidekiq-limit_fetch: A Sidekiq plugin to support advanced queue control (limiting, pausing, blocking, querying)
A Sidekiq plugin to support advanced queue control (limiting, pausing, blocking, querying) - deanpcmad/sidekiq-limit_fetch

Sidekiq Proを使用している場合は

  • Sidekiq Enterpriseの導入を検討する
  • 自分で並列実行数を制御するプログラムを作成する
    • 以下のようなイメージです
      • 「Sidekiq::Workers.new」で実行中のjobを取得し、並列実行数をチェックする
        • 並列実行数をチェックした結果、処理実行して良い場合、そのまま処理実行
        • 並列実行数をチェックした結果、並列実行の上限を超えている場合、「perform_later」でjobをredisに戻し、処理を終了する

まとめ

Sidekiqを使用する際の注意点について記載しました。

まとめると

  • リトライ
    • リトライ回数を意識して設計しましょ
  • サーバプロセスが落ちると、jobのデータは失われる
    • Sidekiq Proを検討しましょ
  • メモリ肥大化する問題
    • メモリに関する設定を見直しましょ

ということです★

]]>