· OpenWorks · tech-tips

ファイルアップロード機能の再設計──ローカルストレージからクラウドストレージへの切り替え時に見落とす要件

移行が起きやすい場面と、その判断の落とし穴

サーバー上のローカルストレージにファイルを保存していたシステムが、容量不足やスケーリングの課題を理由にクラウドストレージ（S3やGCSなど）への移行を検討する。これは多くの企業で起こる判断です。

一見すると「単に保存先を変えるだけ」に見えるのですが、実装の簡潔さと現場の要件のズレが、後々の運用負荷や予期しないコストを生み出します。私が関わってきた案件でも、この移行を甘く見て、リリース後に対応が増えるケースが少なくありません。

特に見落とされやすいのが以下の3点です。

  • 既存ファイルの扱い方：移行前のローカルストレージにあるファイルをどう扱うか、その検証と変換コスト
  • アクセス権限と有効期限：クラウドストレージのURLは時間とともに無効になる可能性があり、その管理戦略
  • ネットワークI/Oのコスト構造：ローカルストレージは「ほぼ無料」だが、クラウドは読み書きと転送に課金される

この記事では、実装段階で判断を誤りやすい箇所を、設計・実装・運用の観点から整理します。

クラウドストレージ移行時に設計で決めておくべき3つの要件

1. 既存ファイルの移行戦略と検証

ローカルストレージから移行する場合、既に存在するファイルをどのタイミングでクラウドに移すかが最初の決断です。

一括移行 か 遅延移行 かで、実装の複雑さと運用リスクが大きく変わります。

一括移行は移行完了後の状態が明確ですが、移行中のダウンタイムやロールバック戦略が必要になります。遅延移行（新規ファイルはクラウド、既存ファイルはアクセス時に移行）は段階的ですが、実装が複雑になり、ファイル参照の度に「どちらのストレージにあるか」を判定するロジックが増えます。

現場では「遅延移行にしておけば安全」と考えがちですが、その判定ロジックが複数の箇所に散らばると、後々のメンテナンスが重くなります。

重要なのは、移行前に既存ファイルの整合性を確認することです。

  • ファイルが物理的に存在するか
  • ファイルサイズがデータベースの記録と一致するか
  • 破損ファイルがないか

これらの検証を移行前に実施し、問題のあるファイルを洗い出しておかないと、クラウド移行後に「あのファイルが見つからない」という苦情が増えます。

2. URLの有効期限とアクセス権限の管理

クラウドストレージ（特にS3）を「非公開」で運用する場合、ファイルへのアクセスには署名付きURLを使うのが一般的です。この署名付きURLには有効期限があります。

ローカルストレージでは「ファイルパスを保存して、いつでも読める」という感覚ですが、クラウドストレージではそうではありません。

データベースに保存するべき情報は何か を明確にしておく必要があります。

例えば、ユーザーがアップロードしたファイルへのリンクをメールで送る場合：

  • ローカル：/uploads/user123/document.pdf をそのままメールに含める
  • クラウド：署名付きURL（有効期限1時間）をその都度生成してメールに含める

後者の場合、メールを受け取ったユーザーが数日後にリンクをクリックすると「URLが無効です」というエラーが出ます。これを避けるには：

  1. 有効期限を長めに設定する（例：7日間）が、セキュリティリスクが増す
  2. ダウンロード時に新しいURLを生成する仕組みにする
  3. ファイルを一時的に公開URLで配信する（ただしセキュリティ要件に応じて判断）

選択肢によって実装の複雑さが異なります。

3. 読み書きのコスト構造と月額予測

ローカルストレージは「容量に対してのみコストがかかる」という感覚が根強いですが、クラウドストレージは異なります。

一般的なS3の料金体系：

  • 保存コスト：GB単価（月額）
  • PUT/POST/DELETE：1000リクエスト単価
  • GET：1000リクエスト単価
  • データ転送：GB単価（特に外部ネットワークへの転送が高い）

例えば、1000ユーザーが毎日1回ファイルをダウンロードする場合、月間30,000GETリクエストが発生します。これ自体は数百円程度ですが、そのファイルが1GBで月間転送量が30GBになると、転送コストだけで数千円になります。

ローカルストレージでは考えなかったコスト構造が、クラウド移行後に予想外に膨らむケースが少なくありません。

移行前に以下を把握しておくべきです：

  • 月間のアップロード数（PUTリクエスト数）
  • 月間のダウンロード数（GETリクエスト数）
  • 保存期間（削除ポリシー）
  • 想定される転送データ量

これらを基に月額コストを試算し、「本当にコスト削減になるのか」を確認します。

実装時に気をつけるべき設計パターン

ハイブリッド運用の実装例

既存ファイルはローカル、新規ファイルはクラウドという方針の場合、アプリケーション層で両方に対応する必要があります。

class FileStorage:
    def __init__(self, local_path, s3_client):
        self.local_path = local_path
        self.s3_client = s3_client
    
    def get_file(self, file_id, file_path):
        # クラウドに存在するか確認
        if self._exists_in_s3(file_id):
            return self.s3_client.get_object(
                Bucket='my-bucket',
                Key=file_id
            )
        
        # ローカルにフォールバック
        local_file = os.path.join(self.local_path, file_path)
        if os.path.exists(local_file):
            with open(local_file, 'rb') as f:
                return f.read()
        
        raise FileNotFoundError(f"File {file_id} not found")
    
    def _exists_in_s3(self, file_id):
        try:
            self.s3_client.head_object(
                Bucket='my-bucket',
                Key=file_id
            )
            return True
        except:
            return False

このパターンは「とりあえず動く」ですが、問題があります。

毎回S3に問い合わせるため、ローカルファイルへのアクセスも遅くなる 可能性があります。特にアクセス頻度の高いファイルの場合、レイテンシが目立ちます。

改善案として、ファイルのメタデータにストレージ種別を記録しておく方法があります：

# ファイルメタデータ
{
    "file_id": "abc123",
    "storage_type": "s3",  # "local" or "s3"
    "created_at": "2025-01-15T10:30:00Z",
    "s3_key": "uploads/abc123"
}

こうすることで、毎回の存在確認が不要になり、パフォーマンスが安定します。

URLの有効期限管理

署名付きURLの有効期限を管理する場合、以下のようなアプローチが考えられます：

from datetime import datetime, timedelta

def generate_download_url(file_id, expiration_hours=24):
    """署名付きURLを生成"""
    expiration_seconds = expiration_hours * 3600
    
    url = s3_client.generate_presigned_url(
        'get_object',
        Params={
            'Bucket': 'my-bucket',
            'Key': file_id
        },
        ExpiresIn=expiration_seconds
    )
    
    # URLの有効期限をDBに記録（ログ・監査用）
    db.insert('file_access_logs', {
        'file_id': file_id,
        'url_generated_at': datetime.now(),
        'url_expires_at': datetime.now() + timedelta(hours=expiration_hours)
    })
    
    return url

ここで重要なのは、有効期限をアプリケーション側でも記録する ことです。

ユーザーが古いURLでアクセスしてきた場合、「URLが無効です」というエラーメッセージだけでなく、「新しいURLを生成してください」という案内を出せるようになります。

運用時に陥りやすい落とし穴

1. コスト予測の甘さ

クラウド移行時に「月額XXX円で済む」という見積もりが、実際には2倍以上になるケースがあります。

原因の多くは、想定外のアクセスパターン です。

  • キャッシュ機構がないため、同じファイルへのアクセスが何度も発生
  • ログ出力やバッチ処理でのファイル読み込みが多い
  • CDNを使わずにクラウドストレージから直接配信している

これらは実装段階では見落とされやすく、本番運用で顕在化します。

対策として、移行後の最初の3ヶ月は月ごとのコスト推移を監視する ことをお勧めします。

2. 既存ファイルへのアクセス性能低下

ローカルストレージでは「ディスクI/O」で済んでいたファイル読み込みが、クラウド移行後は「ネットワークレイテンシ」を伴うようになります。

特に以下のようなケースで性能低下が目立ちます：

  • 小さいファイルを大量に読み込む（メタデータ取得の都度ネットワーク往復