UbuntuでLaravelのパフォーマンスを改善する方法

作成日 2026.03.31
その他

UbuntuでLaravelを運用していると、最初は軽く動いていても、データ量やアクセスが増えるにつれて「一覧が遅い」「初回表示が重い」「デプロイ後だけ不安定」「CPU使用率が高い」といった問題が出やすくなる。Laravelの速度改善は、1つの魔法の設定で終わるものではなく、PHP実行環境、Laravelのキャッシュ、DBアクセス、キュー化、静的ファイル配信、監視の組み合わせで積み上げるのが基本になる。この記事では、Ubuntu環境でLaravelを現実的に速くするための順番と考え方をまとめる。

1. 最初に整理するべきこと
2. まず効くのはLaravelの設定キャッシュ
3. ルートキャッシュでルーティング負荷を下げる
4. ビューキャッシュも本番では有効
5. まとめて最適化するコマンドを使う
6. PHP OPcacheを有効にする
7. OPcacheの設定を本番向けに見直す
8. DBクエリのN+1を潰す
9. 必要なカラムだけ取得する
10. Laravelのキャッシュを使って重い処理を減らす
11. 同一リクエスト内の繰り返し取得にはmemoも使える
12. 重い処理はキューに逃がす
13. 静的ファイルはWebサーバーに任せる
14. ログを見て遅い場所を特定する
15. Ubuntu側で確認しておきたいポイント
16. デプロイ時に毎回やることを固定する
17. まとめ

最初に整理するべきこと

パフォーマンス改善では、まず「何が遅いのか」を分けて考える必要がある。主な原因は次の4つに分かれやすい。
・PHPの実行自体が遅い
・Laravelが毎回同じ設定やルートを読み直している
・DBクエリが多い、または重い
・画像やCSS、JSなどの配信が非効率
この分類をせずに、いきなりキャッシュだけ入れても、根本原因がDBなら体感はほとんど変わらないことがある。

まず効くのはLaravelの設定キャッシュ

Laravel公式では、本番環境で config:cache を実行し、設定ファイルを1つのキャッシュ済みファイルにまとめることで、設定読込のファイルアクセスを減らせると案内されている。Ubuntu上でも、まずここを整えるだけで初期化コストを削りやすい。 :contentReference[oaicite:1]{index=1}

php artisan config:cache

発生しやすい注意点は、.env を変更したのに古い設定のまま動いてしまうこと。設定変更後は一度クリアしてから再生成する方が安全。

php artisan config:clear
php artisan config:cache

ルートキャッシュでルーティング負荷を下げる

Laravelではルート定義が増えるほど、毎回の読込コストも増える。公式ドキュメントでも route:cache が本番向けの最適化手段として用意されている。ルートが多い管理画面やAPIでは特に効果が出やすい。 :contentReference[oaicite:2]{index=2}

php artisan route:cache

ただし、クロージャベースのルートが含まれているとキャッシュに向かない構成になりやすい。ルートキャッシュを前提にするなら、コントローラベースへ寄せた方が運用しやすい。

ビューキャッシュも本番では有効

Bladeテンプレートは通常コンパイルされるが、本番ではあらかじめキャッシュしておくことで、初回アクセス時の負荷を減らせる。Laravelの最適化コマンド群に含まれるため、設定やルートとあわせて実行しておくとまとまりが良い。 :contentReference[oaicite:3]{index=3}

php artisan view:cache

デプロイ時にテンプレートを更新したのに反映されない場合は、クリアも必要になる。

php artisan view:clear

まとめて最適化するコマンドを使う

Laravelでは optimize と optimize:clear によって、設定・イベント・ルート・ビューなどのキャッシュをまとめて扱える。デプロイ手順の中でこれを固定しておくと、毎回の作業がぶれにくい。 :contentReference[oaicite:4]{index=4}

php artisan optimize

問題が起きたときは次で一括クリアできる。

php artisan optimize:clear

発生しやすい問題は、.env を直したのに設定キャッシュが残っていて遅いまま、または挙動が古いままになるケース。

PHP OPcacheを有効にする

PHP公式によると、OPcache はプリコンパイル済みのPHPバイトコードを共有メモリに保持し、毎回のロードとパースを減らす仕組み。LaravelのようにPHPファイル数が多いアプリでは、Ubuntuサーバーでここを有効にしておく価値が大きい。 :contentReference[oaicite:5]{index=5}

まず、現在のPHPでOPcacheが有効かを確認する。

php -m | grep -i opcache

有効なら Zend OPcache が表示されることが多い。
設定ファイル例は次のようになる。

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2

設定反映後はWebサーバーやPHP-FPMを再起動する。
発生しやすい問題は、CLIでは見えているのにFPM側設定が別でWebには効いていないケース。

OPcacheの設定を本番向けに見直す

PHP公式マニュアルでは、opcache.enable、opcache.memory_consumption、opcache.enable_cli などが主要項目として説明されている。UbuntuでLaravelを本番運用するなら、少なくともメモリ不足でキャッシュが溢れていないかは意識したい。 :contentReference[oaicite:6]{index=6}

たとえばCLIでArtisanコマンドも頻繁に叩くなら、必要に応じてCLI側も有効化対象になる。

opcache.enable_cli=1

ただし、開発中はコード更新の反映タイミングとの兼ね合いがあるため、本番とローカルで設定を分けた方が扱いやすい。

DBクエリのN+1を潰す

Laravelの体感速度を悪くする原因として、EloquentのN+1問題は非常に大きい。記事一覧で投稿ごとに著者を1件ずつ取りに行くようなコードは、データ件数に比例してSQLが増える。
改善の基本は with() を使ったEager Loading。

$posts = Post::with(‘user’)->latest()->paginate(20);

件数だけ欲しいなら withCount() を使う。

$posts = Post::withCount(‘comments’)->latest()->paginate(20);

これはLaravelの機能そのものだが、Ubuntu環境で「CPUはそこまで高くないのにページが遅い」場合、まず疑うべきポイントの1つになる。

必要なカラムだけ取得する

N+1を解消しても、関連モデルを全部 select * で持ってくると転送量とメモリ使用量が増える。表示に必要なカラムだけに絞ると、一覧系ではかなり差が出ることがある。

$posts = Post::select([‘id’, ‘user_id’, ‘title’, ‘created_at’])
->with([‘user:id,name’])
->latest()
->paginate(20);

特に管理画面やAPIレスポンスで不要なフィールドが多い場合は、この見直しだけで軽くなることがある。

Laravelのキャッシュを使って重い処理を減らす

Laravelには統一されたキャッシュAPIがあり、RedisやMemcachedなどの高速キャッシュストアを使う前提で、重い集計や外部API結果を再利用できる。公式ドキュメントでも、Laravelは分散キャッシュに強い構成を前提にしている。 :contentReference[oaicite:7]{index=7}

基本の形は次のようになる。

use Illuminate\Support\Facades\Cache;

$data = Cache::remember(‘dashboard:stats:v1’, now()->addMinutes(5), function () {
return [
‘users’ => \App\Models\User::count(),
‘orders’ => \App\Models\Order::count(),
];
});

Ubuntu上でDB負荷が高いときは、アプリ側で毎回同じ集計をしていないかも見るべき。

同一リクエスト内の繰り返し取得にはmemoも使える

Laravelのキャッシュドキュメントでは、memo キャッシュドライバにより、同一リクエストまたは同一ジョブ内で解決済みの値を一時的にメモリ保持できると説明されている。何度も同じキャッシュキーを引く処理では、細かな最適化として効く。 :contentReference[oaicite:8]{index=8}

use Illuminate\Support\Facades\Cache;

$value = Cache::memo()->get(‘settings:site’);

大規模改善の主役ではないが、同一処理の中で同じ設定を何度も読んでいるような箇所では意味がある。

重い処理はキューに逃がす

メール送信、CSV生成、画像変換、外部API同期などをHTTPリクエスト内で実行すると、Ubuntu上のPHPワーカーを長く占有してしまう。Laravelのキューに逃がすと、画面表示やAPI応答を速くしやすい。
さらに、ユニークジョブやロック機構を使う場合は、Laravel公式でもロック対応のキャッシュドライバが前提になる。 :contentReference[oaicite:9]{index=9}

dispatch(new SendInvoiceMailJob($invoiceId));

HTTP応答に不要な処理を全部同期でやっていないかは、速度改善でかなり重要な観点になる。

静的ファイルはWebサーバーに任せる

画像、CSS、JavaScriptはLaravelアプリを通さず、NginxやApacheから直接返す方が効率が良い。Laravelの public 配下に適切に配置し、Webサーバー側でキャッシュヘッダも付けられるようにすると、PHPを通る回数そのものを減らせる。
Ubuntu上で「CPUが高いのにアプリのコードはそれほど重くない」場合、静的ファイルまでPHP経由になっていないかを見る価値がある。

ログを見て遅い場所を特定する

速度改善は、推測だけで進めると外しやすい。
Laravel Telescope や Query Log、Nginx/Apache のアクセスログ、PHP-FPM の状態などを見て、
・遅いのはPHPか
・遅いのはSQLか
・遅いのは外部APIか
を分ける必要がある。
特にSQL回数と1リクエストの実行時間が見えるだけで、改善ポイントはかなり絞りやすい。

Ubuntu側で確認しておきたいポイント

Laravelコードだけでなく、Ubuntu側の状態も速度に直結する。
見るべき点は次の通り。
・PHP-FPMやApache/Nginxが正常稼働しているか
・メモリ不足でスワップしていないか
・ディスクI/Oが詰まっていないか
・ログ肥大化でストレージが圧迫されていないか
・OPcacheが有効か
Laravelだけを見ていても、OS側が詰まっていれば速くならない。

デプロイ時に毎回やることを固定する

本番環境では、毎回のデプロイで最適化コマンドを順序よく実行するだけでも差が出る。Laravel公式の最適化コマンド群を使うと、設定・ルート・ビューの読込コストを安定して下げやすい。 :contentReference[oaicite:10]{index=10}

php artisan optimize
php artisan config:cache
php artisan route:cache
php artisan view:cache

問題が起きたら次で戻す。