Summary
この文書の要点
- ローカルでもバケット、オブジェクトキー、署名付きURLを使う。
- 公開ファイルと非公開ファイルの扱いを開発時から分ける。
- ローカルでもbucket、prefix、ACL相当の運用を本番に寄せる。
- 署名付きURL、MIME、サイズ制限、削除処理をローカルで検証できるようにする。
どこが設計の難所か
開発環境でローカルファイル保存を使い、本番だけS3互換ストレージにすると、URL生成、権限、MIMEタイプ、削除処理の差が後から出ます。特に署名付きURLは本番に近い環境で確認したい機能です。
本番のクラウドストレージを開発者全員が直接使うと、費用や権限、誤削除の問題があります。ローカルで近い挙動を再現しつつ、本番固有のIAMやライフサイクル設定は別途検証する必要があります。
本番ではS3互換ストレージを使うのに、ローカルではファイルシステムへ保存する構成にすると、署名付きURL、権限、オブジェクトキー、削除の挙動が開発中に見えません。その差は本番直前に問題化します。
境界をどう切るか
Docker ComposeにMinIOを入れ、アプリからはS3互換APIとして接続します。保存先の抽象化は本番と同じコードパスを使い、環境変数だけを切り替えます。
設計では、ローカルも本番も同じstorage interfaceを通し、driverだけを変えます。MinIOをDocker Composeへ入れ、bucket作成やテスト用ユーザーを初期化することで、開発者が同じ手順で確認できるようにします。
実装で効く細部
ローカル起動時にバケット作成を自動化し、アクセスキーは開発用に限定します。アプリでは公開URLを直接保存せず、オブジェクトキーを保存します。プレビュー時は署名付きURLを発行する流れをローカルでも通します。
LaravelやNode.js側では、S3 clientのendpoint、region、forcePathStyleを環境変数で切り替えます。テストではMinIO上に実際のオブジェクトを作成し、アップロード、取得、削除、署名付きURLの期限切れを確認します。
- bucket名とprefixは本番に近い命名にし、用途別に分ける。
- ローカル起動時にbucket作成を自動化し、手作業依存を避ける。
- ファイル名ではなくstorage_keyをDBへ保存し、元ファイル名はメタデータとして扱う。
壊れ方を観測する
検証では、アップロード、ダウンロード、期限切れURL、削除、存在しないファイル、MIMEタイプ不正を確認します。CIでMinIOを起動できるなら、ファイル処理の結合テストも自動化できます。
検証では、MinIO停止、bucket未作成、認証情報間違い、サイズ超過、削除済みファイル参照を再現します。ローカルでこれらが見えると、本番ストレージ周辺の障害対応がしやすくなります。
捨てた選択肢とトレードオフ
MinIOはS3互換ですが、クラウドストレージそのものではありません。IAM、リージョン、ライフサイクル、CDN連携は本番相当環境で別に確認します。それでも日常開発の差分を小さくする効果は大きいです。
MinIOを入れると開発環境のコンテナは増えますが、本番との差分は減ります。小さな機能ならローカルファイル保存でも始められますが、署名付きURLや非公開ファイルを扱うなら早めに揃えた方が安全です。
現場に残す判断軸
ファイル機能は本番だけで初めて確認すると危険です。MinIOをローカルに入れ、本番と同じ保存抽象化を通すことで、アップロード周りの不具合を早く見つけられます。
ローカルと本番のストレージ差分は、後から見つかるほど高くつきます。MinIOで失敗パターンまで再現できる環境を作ると、ファイル機能の品質が安定します。
