はじめに

プロジェクトが成長し、テストコードが増えるにつれてCIの実行時間は肥大化します。私のプロジェクトでは現在約5,500件のテストが存在しますが、様々な最適化を組み合わせることで、CircleCI上で約4分という実行環境を実現しています。

今回は、実際に効果があった最適化手法をまとめました。

DBマイグレーションを5倍速くする「tmpfs」マウント

CIにおいて最大のボトルネックになりやすいのがデータベース（MySQL）のI/Oです。
CircleCIのMachine Executorを利用し、MySQLのデータディレクトリを tmpfs（メモリ上の仮想ファイルシステム） にマウントすることで、ディスクI/Oを排除しました。

- run:
    name: Mount tmpfs for MySQL data
    command: |
        mkdir -p docker/volumes/mysql
        sudo mount -t tmpfs -o size=2G tmpfs docker/volumes/mysql

効果: スキーマ作成やダンプのインポートといった処理が、通常のファイルシステムと比較して約5倍高速化されました

Xdebugの排除

デバッグやカバレッジ計測に便利なXdebugですが、有効なだけでPHPの実行速度は大幅に低下します。CI環境ではデバッグ機能は不要なため、コンテナ起動時に設定ファイルからExtensionを削除しています。

効果: テスト実行時間が約2倍速くなりました

ParaTest × CPU数に応じた並列DB生成

並列テスト実行ライブラリ ParaTest を使用していますが、マシンのスペックをフルに活かすため、CPU数（nproc）を動的に取得し、その数だけ専用のテスト用DBを並列でセットアップします。

CPU_COUNT=$(nproc)
while (( CPU_COUNT > 0)); do
  # CPUの数だけ並列でDB作成や権限付与を実行
  docker compose exec -T db mysql -u root -p"${DATABASE_PASSWORD}" -e "grant all on \`test_db"${CPU_COUNT}"\`.* to 'user';" &
  pids[CPU_COUNT]=$!
  CPU_COUNT=$((CPU_COUNT - 1))
done
wait "${pids[@]}"

リソースの競合を避けつつ、ハードウェアの限界まで並列度を高めることが可能です。また、実行時間に応じて柔軟に resource_class を変更できるようになります。

外部通信をiptablesで「即時拒否」する

テスト中に意図せず外部APIへリクエストが飛ぶと、タイムアウト待ちによる数秒〜数十秒のロスが発生します。これを防ぐため、iptables でコンテナからの外部ネットワーク通信を遮断しています。

# DOCKER-USERチェインのデフォルトRETURNを削除し、外部通信をブロックする
sudo iptables -D DOCKER-USER -j RETURN
# コンテナ間通信（プライベートネットワーク）は許可
sudo iptables -A DOCKER-USER -d 172.16.0.0/12 -j RETURN
sudo iptables -A DOCKER-USER -d 10.0.0.0/8 -j RETURN
sudo iptables -A DOCKER-USER -d 192.168.0.0/16 -j RETURN
# TCP接続はRSTで即座に拒否。cURLなどが即エラーを返す
sudo iptables -A DOCKER-USER -p tcp -j REJECT --reject-with tcp-reset
# それ以外のプロトコルはICMPで拒否
sudo iptables -A DOCKER-USER -j REJECT --reject-with icmp-port-unreachable

単にドロップするのではなく tcp-reset を返すことで、クライアントがタイムアウトを待たずに即座にエラーを検知できるため、無駄な待ち時間がゼロになります。

DB接続の再確立を抑える StaticDriver の活用

dama/doctrine-test-bundle の StaticDriver を導入しています。
通常、Symfonyのテストでは bootKernel() ごとにDB接続が再確立されますが、これを静的に保持することで接続コストを削減しています。

効果: テスト実行時間を約40%短縮できました。

初期スキーマの導入に `schema:update` を使わず「SQLダンプ」をインポートする

Doctrineを使用していると doctrine:schema:update --force でDBスキーマを構築したくなりますが、これはCI環境では非常に低速です。
本プロジェクトでは、あらかじめ書き出しておいた db_dump.sql を直接 MySQL に流し込む手法を採用しています。

# 1つずつマイグレーションを走らせるより、ダンプを流し込む方が圧倒的に速い
docker compose exec -T db mysql -u root -p"${DATABASE_PASSWORD}" app-test"${CPU_COUNT}" < db_dump.sql &

Dockerのボリュームをそのままキャッシュ（バックアップ）して使い回す方法も検討しましたが、環境依存による不安定さやキャッシュの肥大化、リストアにかかる時間といった課題があるため 「クリーンな状態からのSQLインポート」 という、速度と安定性のバランスが最も良い着地点を選びました。

なぜ「DBセットアップ」の高速化にこだわるのか？

PHPUnit（ParaTest）によるテスト実行部分は、CPUコア数を増やせば増やすほど線形に速度が向上します（レバレッジが効く）。
しかし、DBの初期化やマイグレーションといった「前準備」の時間は、並列度を上げても短縮できません。

並列度を上げるほど、セットアップ時間がCI全体のボトルネック（支配的）になる
前準備を1分縮めることは、テスト実行部分を1分縮めることよりも価値が高い

そのため、前述の tmpfsマウント や SQLインポート によって「逐次実行される前準備」を極限まで削ぎ落とすことが、ハイスペックなCIマシンの性能をフルに引き出す鍵となります。

「AI時代の高速道路」を守る、独自のスローテスト検知

CIを一度高速化しても、日々の開発で「遅いテスト」が紛れ込めば、すぐに元の木阿弥です。特にAIによるコード生成が標準的になった現代では、人間が書くよりも遥かに容易に、 「意図せず大量のエンティティを生成するテスト」 や 「重いクエリを連発するテスト」 が爆速で量産されるリスクがあります。

こうした「AI時代の副作用」からCIの速度を守るため、独自の SlowTestFailListener を導入しています。

なぜ独自Listenerが必要なのか？

PHPUnit自体にも遅いテストを検知して Risky 判定にする仕組みはありますが、ParaTestを導入している環境では、少なくとも今利用しているバージョンでは、Risky判定になってもCIが正常終了（Pass）してしまうという問題があります。

そのため、独自Listenerで制限時間を超えたテストを強制的に Failure （失敗）として扱うようにしています。

// SlowTestFailListener.php のエッセンス
public function endTest(Test $test, float $time): void
{
    // CI環境以外（xdebug使用時など）はスキップ
    if (!getenv('CI')) return;

    // サイズごとの制限時間
    $limit = self::TIME_LIMITS[$test->getSize()] ?? self::DEFAULT_TIME_LIMIT;

    if ($time > $limit) {
        $test->getTestResultObject()->addFailure(
            $test,
            new AssertionFailedError("テストが {$time}秒かかりました（制限: {$limit}秒）。..."),
            $time
        );
    }
}

「AI時代のための高速道路」の整備

開発者がAIを使いこなし、凄まじいスピードで開発を進めるためには、CIという「高速道路」が常に舗装されている必要があります。

早期検知: 実行時間が伸びた瞬間にCIを落とし、開発者にフィードバックする
アノテーションによる意図の明示: 本当に重いテストが必要な場合は @medium や @large を付けるよう促す

このように「速く走れる仕組み」だけでなく、「遅くなる原因を自動で弾く仕組み」をセットで用意することが、AI時代のCI/CD戦略には不可欠です。

高速なCIは「最強の開発ツール」

CIを短時間で終わらせることは、単にサーバーコストを抑えることではありません。開発者が「このコードをプッシュしても大丈夫か？」と不安になる時間を最小化し、 試行錯誤のサイクルを高速化させるための、最も投資対効果の高いエンジニアリング です。

PHPUnitの実行時間が課題になっているプロジェクトにとって、これらの手法のどれか一つでも解決のヒントになれば幸いです。