Laravel Newsの報道によると、KubernetesプローブとPrometheusメトリクスに対応する監視パッケージ「Health for Laravel」が公開された。Laravel標準では用意されていないコンテナ運用を前提としたヘルスチェックとメトリクス公開を、単一のパッケージで統合する実装である。Kubernetes上にLaravelアプリケーションをデプロイする個人開発者にとって、監視スタックの自前実装コストを削減する一手となる。
3種プローブと依存関係の分離
パッケージが提供するKubernetesプローブはLiveness、Readiness、Startupの3種である。各プローブの判定基準は明確に分かれている。Livenessはプロセス稼働、ReadinessはDB・Redisなど依存先の応答可否、Startupは初期化完了を判定する。PHP-FPMとNginxを前面に置く構成では、コンテナがリクエストを受け付けないタイミングをKubernetesへ正確に伝えられる。
Readinessが失敗の間、Serviceのルーティング対象から該当Podは除外される。挙動を正しく理解しておく必要がある。DBマイグレーション中やRedis未起動の初期フェーズで、503を返しながらクラスタ全体のヘルスチェックを落とさずに済む。逆にLivenessとStartupの閾値設計を誤ると、起動直後のPodが再起動ループに陥る。3種プローブの責務分離は、Kubernetes運用の基本原則として省略しないほうが安全である。
Startupプローブは比較的新しい仕組みで、initContainerや重いマイグレーションを含むLaravelアプリでは特に有効である。Livenessプローブのタイムアウトで初期化フェーズを誤判定する事故は、個人開発の小規模クラスタでも発生する。
Prometheus対応とcgroup考慮の計測値
/metricsエンドポイントはPrometheusのテキスト形式でカウンタとゲージを返す。注目すべき実装は、cgroupリソース制限下でのCPU使用率とメモリ使用量を計測する点である。/proc/statから直接読む方式ではホスト全体の値を集計してしまう。コンテナ単位の正確な値が取れることは、複数コンテナを同一ホストで動かす構成でのボトルネック特定の精度向上に直結する。
テキスト形式のメトリクスは、Grafanaダッシュボードへの接続も容易である。Laravelで個別にメトリクス公開を実装する場合、artisanコマンドでPrometheus形式を出力するケースが多い。HTTPエンドポイントとして標準化されることで、Prometheusのscrape設定側の汎用性が増し、サイドカーや別コンテナにExporterを立てる構成も避けられる。1プロセス1エンドポイントのシンプルな構造は、個人開発のコンテナ数を抑える方向と一致する。
導入時に確認する4項目
本番投入の前に、次の項目を順に検証する。
- パッケージ要件：サポートされるPHPバージョンとLaravelバージョンを、composer require実行前に確認する。READMEおよびcomposer.jsonのrequire節を必ず確認する
- プローブ閾値：StartupプローブのfailureThresholdと、コンテナ初期化処理時間の整合を実測する。タイムアウトが短すぎる場合、起動完了前に再起動と判断される
- メトリクス量：/metricsのレスポンスサイズとPrometheusのscrape_intervalをベンチマークする。リクエストURIやユーザーIDをラベルに含めるとカーディナリティが爆発し、Prometheus側のストレージを圧迫する
- 認証境界：/metricsが外部公開されないよう、NetworkPolicy・Ingress・Laravelルーティングのいずれかでアクセス境界を設ける。認証なしで内部情報が漏れるリスクは、開発環境でも除外すべきでない
個人開発の小規模クラスタでは過剰とも感じる項目群である。Health for Laravelを採用するか、artisanコマンドベースの自前実装を維持するかは、この4項目にかかる工数と、既存監視スタックとの依存関係の整理で決まる。PrometheusもGrafanaも運用していない環境であれば、Health for Laravel導入の優先度は自前実装と同等であり、過剰な依存関係の追加は避けるべきである。