Laravelの実行モデルと前提

Laravelの実行モデルと前提

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

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

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

主な物理的制約

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

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

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

2. プロセス/スレッドプール

   • PHP-FPMのプロセス数制限（pm.max_children）
   • プロセス枯渇により、すべてのリクエストが処理できなくなる

3. ファイル記述子

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

4. メモリリーク

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

実際の事故例:

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

Laravelの実行モデル

PHPの実行モデル

実行モデル:

PHPコード (.php)
    ↓ インタープリタで実行
Zend Engine（実行時）

重要な特徴:

1. 動的型付け: 実行時に型が決定される（PHP 8.0以降は型宣言が強化）
2. ガベージコレクション: 自動メモリ管理（ただし、参照が保持されている場合は動作しない）
3. リクエストごとの実行: 各リクエストが独立したプロセス/スレッドで実行される
4. OPcache: バイトコードキャッシュによる高速化

トランザクション境界

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

// Laravelでのトランザクション管理
DB::transaction(function () {
    // トランザクション内の処理
    $order = Order::create($orderData);

    foreach ($orderData['items'] as $item) {
        $inventory = Inventory::where('product_id', $item['product_id'])->first();
        $inventory->decrement('stock', $item['quantity']);
    }

    // すべて成功するか、すべてロールバック
});

特徴:

• 明示的なトランザクション境界: DB::transaction()で明示
• 自動ロールバック: 例外時に自動的にロールバック
• ネストしたトランザクション: ネストしたトランザクションが可能

非同期処理

Laravelの非同期処理:

// Queueを使用
dispatch(new ProcessOrder($orderId));

// または、Jobクラスを使用
ProcessOrder::dispatch($orderId);

特徴:

• 信頼できる非同期: Queueによる制御
• エラーハンドリング: Queueのエラーハンドリング機能を使用
• 再実行: Queueのリトライ機能を使用

実行環境による特性

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

Serverless環境での実行

制約:

// ❌ 悪い例: Serverless環境で問題のあるコード
public function createOrder(Request $request)
{
    // 問題: 長時間実行される可能性がある
    // 問題: トランザクションが長時間保持される
    // 問題: 接続プールが適切に管理されない
    $order = Order::create($request->all());
    return response()->json(['id' => $order->id]);
}

問題点:

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

まとめ

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

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

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