ストレージサーバ — 大きな塊を置く倉庫

Webでよく使うのはオブジェクトストレージ（S3 のような方式）。ファイルをオブジェクトとして、バケット（入れ物）に入れて管理します。ファイル階層というより「キー＝住所でオブジェクトを出し入れする」イメージです。

• バケット／オブジェクト — 入れ物と、その中の1ファイル
• 署名付きURL — 期限・権限を埋め込んだ一時URL。直接アップ／ダウンロードに使う
• 冗長化 — 複数拠点にコピーを持ち、高い耐久性を得る

登場人物メモ:

• ※1 署名付きURL — バックを経由せず、クライアントが倉庫と直接やり取りする一時許可証
• ※2 耐久性 — データを失わない度合い（複製で担保）

1. バックが署名付きURLを発行する（「このファイルを、この期限まで、アップしてよい」）
2. クライアントはそのURLへ直接アップロード（バックは中継しない）。ブラウザから倉庫へは別オリジンへの通信になるため、倉庫側にCORS設定（許可するオリジン・メソッドの指定）が要る
3. 保存後、DBにはキー／URLだけを記録する
4. 配信時は、必要ならCDNと組み合わせて近くから配る

• ブロック／ファイル／オブジェクト — 用途で選ぶ。Webの静的資産はオブジェクトが定番
• 耐久性 vs 可用性 — 失わなさ（複製）と、いつでも使える度合いは別の指標
• ライフサイクル — 古いファイルを自動で安価な階層へ移す／削除する
• アクセス制御 — 誰が何をできるかはバケットポリシーで定め、ブロックパブリックアクセスを効かせて既定は非公開に保つ（公開は明示的に許可したものだけ）
• 結果整合性 — 分散ストレージ一般では、書いた直後に読むとまだ見えない・反映が遅れることがある（※主要クラウド（現行のS3など）は全操作で強整合になった）

3方式は「何を単位にまとめるか」で選び分けます。巨大な塊はオブジェクト、速いディスクはブロック、みんなで共有はファイルが定番です。

• 公開設定ミス — バケットを誤って公開し、機密ファイルが漏洩（重大事故の定番）。バケットポリシーとブロックパブリックアクセスで既定を非公開に保てば防げる
• 大量の小ファイル — 数が多いと一覧・管理のコストが上がる