Railsの実行モデルと前提

Railsの実行モデルと前提

Railsの実行モデルと、実務で事故を防ぐための前提条件を詳しく解説します。

実行モデルとリソースの物理的制約

コンピュータ資源は有限であり、性能ではなく制約を前提に設計することが基本です。

主な物理的制約

CPU・メモリよりも先に枯渇するリソース:

1. DB・外部APIのコネクション数

   • 接続プールの上限（例: pool: 5）
   • 接続リークは数時間後にシステム全体を停止させる

2. スレッドプール

   • Pumaのスレッド数制限（threads 5, 5）
   • スレッド枯渇により、すべてのリクエストが処理できなくなる

3. ファイル記述子

   • OSレベルの制限（通常1024〜65536）
   • ファイルやソケットを適切にクローズしないと枯渇

4. メモリリーク

   • オブジェクトの参照が保持される
   • グローバル変数やクラス変数の不適切な使用

実際の事故例:

10:00:00 - アプリケーション起動（接続プール: 5/5）
10:00:01 - リクエスト1受信（接続取得: 6/5 → 待機）
10:00:02 - リクエスト2受信（接続取得: 7/5 → 待機）
...
10:30:00 - 接続が解放されず、すべてのリクエストが待機状態
10:30:01 - タイムアウトエラーが大量発生
10:30:02 - システム全体が応答不能

Railsの実行モデル

Rubyの実行モデル

実行モデル:

Rubyコード (.rb)
    ↓ インタープリタで実行
ネイティブコード（実行時）

重要な特徴:

1. 動的型付け: 実行時に型が決定される
2. ガベージコレクション: 自動メモリ管理（ただし、参照が保持されている場合は動作しない）
3. シングルスレッド: GIL（Global Interpreter Lock）により、同時に1つのスレッドのみが実行される（マルチプロセスで並行処理）
4. メタプログラミング: 実行時にコードを生成・変更可能

トランザクション境界

Railsのトランザクション管理:

# ActiveRecordでのトランザクション管理
class OrderService
  def create_order(order_data)
    Order.transaction do
      # トランザクション内の処理
      order = Order.create!(order_data)
      order.items.each do |item|
        Inventory.find_by!(product_id: item.product_id).decrement!(:stock, item.quantity)
      end
      # すべて成功するか、すべてロールバック
      order
    end
  end
end

特徴:

• 明示的なトランザクション境界: transactionブロックで明示
• 自動ロールバック: エラー時に自動的にロールバック
• after_commitコールバック: トランザクションコミット後に処理を実行可能

他言語との比較:

// Java: 宣言的トランザクション管理
@Transactional
public Order createOrder(OrderData orderData) {
    Order order = orderRepository.save(new Order(orderData));
    return order;
}

非同期処理

Railsの非同期処理:

# Active Jobを使用
class OrderProcessingJob < ApplicationJob
  def perform(order_id)
    # 非同期処理
    order = Order.find(order_id)
    payment_service.charge_payment(order.id, order.amount)
  end
end

# ジョブをエンキュー
OrderProcessingJob.perform_later(order.id)

特徴:

• 信頼できる非同期: Active Jobによる制御
• エラーハンドリング: rescue_fromでエラーを処理
• 再実行: retry_onで自動リトライ

他言語との比較:

// Node.js: Promise/async-await
async function processOrder(orderId: number) {
  await paymentService.chargePayment(orderId);
}

実行環境による特性

環境	特徴	主なリスク
Serverless (Lambda/Vercel)	短寿命・自動スケール	コールドスタート、接続バースト、DBパンク、実行時間制限（Lambda: 15分、Vercel: 300秒）
常駐プロセス (Puma)	長寿命・安定動作	メモリリーク、プール断片化、デッドロック、接続リーク

Serverless環境での実行

制約:

# ❌ 悪い例: Serverless環境で問題のあるコード
class OrdersController < ApplicationController
  def create
    # 問題: 長時間実行される可能性がある
    # 問題: トランザクションが長時間保持される
    # 問題: 接続プールが適切に管理されない
    @order = OrderService.new.create_order(order_params)
    render json: @order
  end
end

問題点:

• 実行時間の制限: Lambdaは最大15分、Vercelは最大300秒
• コールドスタート: Rubyの起動に時間がかかる（500ms-2s）
• メモリ制限: メモリ使用量に制限がある（Lambda: 128MB〜10GB）
• 接続バースト: スケールアウト時に接続プールが急増し、DBがパンクする可能性

解決策:

# ✅ 良い例: Serverless環境に適したコード
class OrdersController < ApplicationController
  def create
    # 1. バリデーション（短時間）
    validate_order_data(order_params)

    # 2. 注文を作成（短時間）
    @order = Order.create!(order_params)

    # 3. 非同期処理をキューに投入
    OrderProcessingJob.perform_later(@order.id)

    # 4. 即座にレスポンスを返す
    render json: { order_id: @order.id, status: 'PROCESSING' }, status: :accepted
  end
end

常駐プロセス環境での実行

Pumaアプリケーションサーバー

特徴:

config/puma.rb

workers 4
threads 8, 16

# 常駐プロセス環境での実行

メリット:

• 長時間実行可能: 実行時間の制限がない
• 接続プール: データベース接続プールを保持
• キャッシュ: メモリキャッシュを保持
• バックグラウンド処理: Active Jobによる処理

実装例:

# ✅ 良い例: 常駐プロセス環境に適したコード
class OrderService
  def create_order(order_data)
    Order.transaction do
      order = Order.create!(order_data)

      # トランザクションコミット後に外部APIを呼ぶ
      order.after_commit do
        PaymentService.new.charge_payment(order.id, order_data[:amount])
      end

      order
    end
  end
end

まとめ

Railsの実行モデルと前提のポイント：

• リソースの物理的制約: CPU・メモリよりも先に枯渇するのは、DB接続数・スレッドプール・ファイル記述子・メモリリーク
• Ruby: 動的型付け、ガベージコレクション、GIL、メタプログラミング
• トランザクション境界: transactionブロックで明示、after_commitコールバック
• 非同期処理: Active Jobによる制御、エラーハンドリング、自動リトライ
• Serverless環境: 実行時間制限、コールドスタート、メモリ制限、接続バースト
• 常駐プロセス環境: 長時間実行可能、接続プール、キャッシュ、Active Job（メモリリーク・接続リークに注意）

重要な原則: 性能ではなく制約を前提に設計する。リソースの垂れ流しは数時間後にシステム全体を停止させる。