PHP-FPM卒業のタイミング？FrankenPHPで実現する10倍速のワーカーモード

PHPアプリケーションのパフォーマンス改善を考えたとき、あなたはどんな選択肢を検討しますか？

最近、PHP界隈で注目を集めているのがFrankenPHPです。
これは新しいランタイムで、従来のPHP-FPMとは根本的に異なるアプローチを採用しています。
そして、パフォーマンスの大幅な向上を実現しているのです。

本記事では、両者の違いと適切な選択基準について解説します。
実践的な視点から、どちらを選ぶべきか考えていきましょう。

PHP-FPMの仕組みと特徴

PHP-FPMは長年にわたってPHPの標準的な実行環境でした。
その動作原理はシンプルです。

まず、PHP-FPMはプロセスプールを管理します。
そして、リクエストが来るたびに待機中のプロセスを割り当てます。
処理が終わると、そのプロセスは次のリクエストに備えて待機状態に戻るのです。

この「shared nothing」というアーキテクチャには大きな利点があります。
各リクエストが完全に独立しているからです。

つまり、前のリクエストの状態が次のリクエストに影響を与えません。
結果として、メモリリークや状態の不整合といった問題から解放されるわけです。

// PHP-FPMでは毎回新しい状態から開始
class UserService {
    private $database;

    public function __construct() {
        // 毎回データベース接続を確立
        $this->database = new DatabaseConnection();
    }

    public function getUser($id) {
        // 処理...
    }
}

FrankenPHPが変えるゲームのルール

FrankenPHPは革新的なアプローチを採用しています。
Caddyウェブサーバーに直接PHPランタイムを組み込んでいるのです。

特に注目すべきは「workerモード」です。
このモードでは、アプリケーションを一度起動したら、そのまま複数のリクエストを処理し続けます。

つまり、フレームワークの初期化やデータベース接続といった処理を最初の一回だけ実行すればよいのです。

// FrankenPHPのworkerモードでの実装例
class Application {
    private static $instance;
    private $database;

    public static function getInstance() {
        if (!self::$instance) {
            self::$instance = new self();
            // 一度だけ初期化
            self::$instance->database = new DatabaseConnection();
        }
        return self::$instance;
    }

    public function handleRequest($request) {
        // データベース接続は既に確立されている
        // 直接処理を開始できる
    }
}

この違いを料理に例えてみましょう。

PHP-FPMは、お客様の注文ごとに新しいシェフを雇います。
そして、レシピを覚えさせてから料理を作らせます。

一方、FrankenPHPのworkerモードは違います。
同じシェフがキッチンに常駐し、次々と料理を作り続けるのです。

パフォーマンスの実際

「FrankenPHPは速い」という話をよく聞きます。
しかし、実際のところはどうでしょうか。

ベンチマークでは確かに印象的な数字が出ています。
ただし、現実のアプリケーションでの効果は、いくつかの要因に左右されるのです。

まず重要なのは、アプリケーションの初期化時間です。
大規模なフレームワークを使っている場合、この初期化コストは無視できません。
例えば、Symfonyのような重量級フレームワークでは、初期化に数十ミリ秒かかることもあります。

次に考慮すべきは、データベースとの通信コストです。
実は多くのアプリケーションで、データベースI/Oがボトルネックになっています。

PHPの実行速度を改善しても、データベースが遅ければ意味がありません。
全体のパフォーマンスは向上しないのです。

// パフォーマンス測定の例
$start = microtime(true);

// フレームワーク初期化（PHP-FPMでは毎回実行）
$app = new Application();
$container = $app->buildContainer();
$router = $app->setupRouting();

$initTime = microtime(true) - $start;
echo "初期化時間: {$initTime}秒\n";

// 実際のリクエスト処理
$requestStart = microtime(true);
$response = $app->handle($request);
$requestTime = microtime(true) - $requestStart;
echo "処理時間: {$requestTime}秒\n";

導入時の注意点

FrankenPHPのworkerモードを採用する場合、コードの書き方を見直す必要があります。

最も重要な課題はメモリ管理です。
PHP-FPMでは各リクエスト終了時にメモリがクリアされます。

しかし、workerモードではメモリが蓄積されていくのです。
そのため、静的変数やシングルトンパターンの使用には特に注意が必要になります。

// メモリリークを防ぐための実装例
class RequestHandler {
    private $temporaryData = [];

    public function handle($request) {
        try {
            // リクエスト処理
            $this->temporaryData[] = $request->getData();
            // 処理...
        } finally {
            // 必ずクリーンアップ
            $this->cleanup();
        }
    }

    private function cleanup() {
        $this->temporaryData = [];
        // その他のクリーンアップ処理
    }
}

また、非同期処理への対応も必須です。

なぜなら、workerモードでは複数のリクエストが同じプロセスで処理されるからです。
ブロッキング処理があると、全体のパフォーマンスに悪影響を与えてしまいます。

適切な選択基準

では、どんな場合にFrankenPHPを選ぶべきでしょうか。

FrankenPHPが適しているケース：

高トラフィックのAPIサーバー
レスポンスタイムの最小化が必要
マイクロサービスアーキテクチャ
初期化コストが大きいアプリケーション

一方、PHP-FPMのままで問題ないケース：

WordPressなどの既存CMS
メモリが限られた環境
複雑な状態管理を避けたい場合
チームがworkerモードに不慣れな場合

実際のプロジェクトでは、部分的な導入から始めるのが賢明です。

例えば、特定のAPIエンドポイントだけFrankenPHPで処理できます。
そして、他の部分は従来通りPHP-FPMで動かすという構成も可能なのです。

デプロイメントの実践

FrankenPHPには、デプロイメント面でも大きな利点があります。

まず、Caddyサーバーと統合されているため、SSL証明書の自動管理が可能です。
これは運用面で大きなメリットになります。

さらに、アプリケーション全体を単一のバイナリとしてパッケージ化できます。
つまり、Goアプリケーションのようなシンプルなデプロイが実現できるのです。

# FrankenPHP用のDockerfile例
FROM dunglas/frankenphp

COPY . /app

ENV FRANKENPHP_CONFIG="
    worker /app/public/index.php
"

EXPOSE 443
CMD ["frankenphp", "run"]