Summary
この文書の要点
- アプリ、DB、アップロードファイルの責務を分ける。
- ファイルはS3へ逃がし、サーバーディスク依存を減らす。
- アプリ、DB、ファイル、バックアップ、ログの責務を最小限でも分ける。
- S3には公開アセットと非公開ファイルを混ぜず、Laravelのdisk設定で用途を分離する。
どこが設計の難所か
小規模アプリでは、1台のサーバーにLaravel、DB、ファイルをまとめる構成が選ばれがちです。初期費用は小さくできますが、ディスク障害、容量増加、バックアップ、移行の時に問題が集中します。
利用規模が読みづらい段階では、過剰な可用性構成はコストに見合わないことがあります。一方で、後からファイル保存先を変えるのは手間がかかります。最小構成でも分離すべき境界を選ぶ必要があります。
小規模LaravelをLightsailで動かす場合、サーバー1台で始められる手軽さがあります。一方で、アップロードファイル、DBバックアップ、ログ、証明書更新を同じサーバー内に閉じると、復旧時の選択肢が少なくなります。
境界をどう切るか
Laravel本体はLightsailのような単純な実行環境に置き、アップロードや生成ファイルはS3に置きます。DBは同居から始める場合でも、バックアップと外部DB移行を想定して接続設定を分離します。
設計では、アプリ実行はLightsail、永続ファイルはS3、DBは管理しやすいPostgreSQL、バックアップは別保管というように、壊れ方の違うものを分けます。最小構成でも、復旧単位を意識すると運用が安定します。
実装で効く細部
LaravelのFilesystem設定でS3を使い、アプリコードは保存先の実パスを意識しないようにします。環境変数でDB、キュー、メール、ストレージを切り替えます。デプロイ手順にはマイグレーション、キャッシュクリア、権限確認を含めます。
Laravelでは、public diskとprivate diskを分け、ユーザーアップロードはS3の非公開bucketに置きます。環境変数、queue worker、scheduler、ログローテーション、DBバックアップをsystemdやcronで管理し、手順を小さく固定します。
- アップロードファイルはサーバーローカルに置かず、再デプロイや復旧に巻き込まれないようにする。
- バックアップは取得だけでなく、別環境へ復元できるかを定期的に確認する。
- ログとアプリ容量がディスクを圧迫しないよう、ローテーションと監視を入れる。
壊れ方を観測する
検証では、DBバックアップからの復元、S3ファイルの権限、署名付きURL、サーバー再作成時の復旧時間を確認します。ディスクに残ってはいけないファイルがないかも見ます。
検証では、アプリ再起動、queue停止、DB復元、S3権限不備、証明書更新を手順として確認します。小規模構成でも、復旧演習を一度行うと、どこが単一障害点かが見えます。
捨てた選択肢とトレードオフ
Lightsailは分かりやすい反面、マネージドなスケールや監視は限定されます。将来Cloud RunやECSへ移す可能性があるなら、ログ、環境変数、ファイル保存を最初から移植しやすくしておくとよいです。
Cloud Runなどに寄せれば運用の一部は軽くなりますが、初期構成や権限設計は増えます。Lightsailは分かりやすい一方、サーバー保守の責任を持ちます。小規模では、運用できる人と復旧手順を基準に選ぶのが現実的です。
現場に残す判断軸
最小構成は、何も分けない構成ではありません。運用負荷を抑えながら、ファイル、DB、アプリの責務を分けておくことが、小規模Laravelを安全に始める判断軸です。
最小構成は、何もしない構成ではありません。小さく始めながら、ファイル、DB、バックアップを分けておくことで、Laravelアプリを無理なく運用できます。
