コンテンツにスキップ

507 Insufficient Storageエラーの原因と対処法|ディスク容量・S3・クラウド環境

カテゴリ:サーバー・インフラ

ファイルアップロードや大量データの書き込み処理中に「507 Insufficient Storage」エラーが発生するケースがあります。このエラーは、サーバーがリクエストを処理するのに必要なストレージ容量が不足していることを示します。本記事では、507エラーの発生原因から、ディスク容量の確認方法、ログの肥大化対策、クラウドストレージの容量管理、そしてモニタリングの設定まで体系的に解説します。

507エラーとは何か

HTTP 507 Insufficient Storage は、RFC 4918(WebDAV拡張)で定義されたステータスコードです。サーバーがリクエストを完了するために必要なストレージ空間を確保できない場合に返されます。元々は WebDAV プロトコルのためのステータスですが、現在ではファイルストレージ関連の汎用的なエラーとしても使われています。

このエラーは一時的な状態異常であることが多く、ディスク容量を確保すれば解消します。しかし、放置するとデータベースの書き込み失敗、ログ出力の停止、アプリケーション全体のクラッシュなど深刻な障害につながる可能性があります。

関連ステータス 名称 違い
413 Content Too Large リクエストサイズが設定上限を超えている(サーバー容量は関係なし)
507 Insufficient Storage サーバー側の物理的/論理的なストレージ容量が不足
503 Service Unavailable 一時的なサービス停止(容量不足が原因の場合もあり)

サーバーのディスク容量確認方法

507エラーが発生したら、まずサーバーのディスク容量を確認します。以下のコマンドを使い分けて、どこで容量を消費しているか特定します。

# ファイルシステムごとの使用量を確認
df -h

# 出力例:
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sda1        50G   47G  3.0G  94% /
# /dev/sdb1       200G  180G   20G  90% /data

# 特定ディレクトリの使用量を確認
du -sh /var/log/
du -sh /var/www/
du -sh /tmp/

# サブディレクトリごとの使用量をソートして表示
du -h --max-depth=1 /var/ | sort -rh | head -20

# inode(ファイル数)の使用状況も確認(容量はあるのにファイルが作れない場合)
df -i

# 大きなファイルを探す(100MB以上)
find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -20

# 最近24時間以内に更新された大きなファイルを探す
find /var -type f -mtime -1 -size +50M -ls 2>/dev/null

ログファイルの肥大化対策(logrotate)

ディスク容量不足の最も多い原因の1つがログファイルの肥大化です。アクセスログ、エラーログ、アプリケーションログが数GBに膨れ上がることは珍しくありません。Linux の logrotate を適切に設定して、ログの自動ローテーションを行いましょう。

# /etc/logrotate.d/nginx の設定例
/var/log/nginx/*.log {
    daily           # 毎日ローテーション
    missingok       # ログファイルが無くてもエラーにしない
    rotate 14       # 14世代分を保持
    compress        # gzip で圧縮
    delaycompress   # 直近1世代は圧縮しない
    notifempty      # 空のログはローテーションしない
    create 0640 www-data adm  # 新しいログファイルの権限
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}
# /etc/logrotate.d/app の設定例(アプリケーションログ)
/var/www/app/storage/logs/*.log {
    daily
    missingok
    rotate 7         # 7日分を保持
    compress
    delaycompress
    notifempty
    create 0644 www-data www-data
    maxsize 100M     # 100MB を超えたら日次以外でもローテーション
    dateext          # 日付をファイル名に付与
    dateformat -%Y%m%d
}

# 手動でローテーションを実行(テスト)
sudo logrotate -f /etc/logrotate.d/app

# ドライラン(実行せずに結果を確認)
sudo logrotate -d /etc/logrotate.d/app

# ログのサイズを即座に確認
ls -lhS /var/log/nginx/ | head -10
ls -lhS /var/www/app/storage/logs/ | head -10

tmpディレクトリの掃除

ファイルアップロード時の一時ファイルや、セッションファイル、キャッシュファイルが /tmp ディレクトリに蓄積されて容量を圧迫するケースも頻繁に発生します。

# /tmp の使用量を確認
du -sh /tmp/

# 古い一時ファイルの確認(7日以上前)
find /tmp -type f -mtime +7 -ls | head -20

# 古い一時ファイルを削除(7日以上前のファイル)
find /tmp -type f -mtime +7 -delete

# PHPセッションファイルの確認と掃除
du -sh /var/lib/php/sessions/
find /var/lib/php/sessions/ -type f -mtime +1 -delete

# PHPのアップロード一時ファイルが残っていないか確認
ls -la /tmp/php*

# systemd-tmpfiles を使った自動掃除(systemd環境)
# /etc/tmpfiles.d/cleanup.conf に以下を追加:
# d /tmp 1777 root root 7d
# 上記設定は /tmp 内の7日以上前のファイルを自動削除
# cron で定期的に掃除するスクリプト例
# /etc/cron.daily/cleanup-tmp

#!/bin/bash
# 7日以上前のtmpファイルを削除
find /tmp -type f -mtime +7 -delete 2>/dev/null

# アプリケーションのキャッシュを掃除
find /var/www/app/storage/framework/cache -type f -mtime +3 -delete 2>/dev/null

# 容量を記録
echo "$(date '+%Y-%m-%d %H:%M:%S') - $(df -h / | tail -1)" >> /var/log/disk-usage.log

S3・クラウドストレージでの容量制限

クラウドストレージを使用している場合でも、容量に関する制限やコストに注意が必要です。AWS S3 自体にはバケットの容量上限はありませんが、コスト管理やライフサイクルポリシーを適切に設定する必要があります。

# AWS CLI で S3 バケットのサイズを確認
aws s3 ls s3://my-bucket --recursive --summarize --human-readable | tail -2
# 出力例:
# Total Objects: 152345
# Total Size: 85.3 GiB

# CloudWatch メトリクスでバケットサイズを確認
aws cloudwatch get-metric-statistics \
    --namespace AWS/S3 \
    --metric-name BucketSizeBytes \
    --dimensions Name=BucketName,Value=my-bucket Name=StorageType,Value=StandardStorage \
    --start-time 2026-04-13T00:00:00Z \
    --end-time 2026-04-14T00:00:00Z \
    --period 86400 \
    --statistics Average
// S3 ライフサイクルポリシーの設定例
// 古いファイルを自動的にアーカイブ・削除
{
    "Rules": [
        {
            "ID": "archive-old-uploads",
            "Status": "Enabled",
            "Filter": {
                "Prefix": "uploads/"
            },
            "Transitions": [
                {
                    "Days": 90,
                    "StorageClass": "STANDARD_IA"
                },
                {
                    "Days": 365,
                    "StorageClass": "GLACIER"
                }
            ]
        },
        {
            "ID": "delete-temp-files",
            "Status": "Enabled",
            "Filter": {
                "Prefix": "tmp/"
            },
            "Expiration": {
                "Days": 7
            }
        },
        {
            "ID": "cleanup-incomplete-uploads",
            "Status": "Enabled",
            "Filter": {
                "Prefix": ""
            },
            "AbortIncompleteMultipartUpload": {
                "DaysAfterInitiation": 3
            }
        }
    ]
}
クラウドサービス 容量上限 1ファイルの上限 注意点
AWS S3 無制限 5TB コスト管理、ライフサイクルポリシーの設定が重要
Google Cloud Storage 無制限 5TB オブジェクトバージョニング有効時はコスト増加に注意
Azure Blob Storage 無制限 約4.75TB(Block Blob) アカウントごとの帯域幅・IOPS制限あり
DigitalOcean Spaces 250GB(プランによる) 5GB プランの容量上限に注意

モニタリング設定(しきい値アラート)

507エラーは予防が最も重要です。ディスク使用率が一定のしきい値を超えたらアラートを発報するモニタリングを設定しましょう。

#!/bin/bash
# /usr/local/bin/disk-alert.sh
# ディスク使用率監視スクリプト

THRESHOLD=80  # 警告しきい値(%)
CRITICAL=90   # 危険しきい値(%)
MAILTO="admin@example.com"

df -h --output=pcent,target | tail -n +2 | while read usage mount; do
    # パーセント記号を除去
    usage_num=$(echo "$usage" | tr -d '%')

    if [ "$usage_num" -ge "$CRITICAL" ]; then
        echo "CRITICAL: ${mount} のディスク使用率が ${usage}% です" | \
            mail -s "[CRITICAL] ディスク容量警告 - $(hostname)" "$MAILTO"
    elif [ "$usage_num" -ge "$THRESHOLD" ]; then
        echo "WARNING: ${mount} のディスク使用率が ${usage}% です" | \
            mail -s "[WARNING] ディスク容量警告 - $(hostname)" "$MAILTO"
    fi
done

# crontab に登録(5分ごとに実行)
# */5 * * * * /usr/local/bin/disk-alert.sh
# Prometheus + node_exporter でのアラート設定例
# /etc/prometheus/alerts/disk.yml

groups:
  - name: disk_alerts
    rules:
      - alert: DiskSpaceWarning
        expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "ディスク使用率が80%を超えています"
          description: "{{ $labels.instance }} の {{ $labels.mountpoint }} の使用率が {{ $value }}% です。"

      - alert: DiskSpaceCritical
        expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 90
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "ディスク使用率が90%を超えています - 即時対応が必要"
          description: "{{ $labels.instance }} の {{ $labels.mountpoint }} の使用率が {{ $value }}% です。"

      - alert: DiskInodeWarning
        expr: (1 - node_filesystem_files_free / node_filesystem_files) * 100 > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "inode使用率が80%を超えています"
# Python での簡易ディスク監視スクリプト
import shutil
import smtplib
from email.mime.text import MIMEText

def check_disk_usage(path='/', warning_threshold=80, critical_threshold=90):
    """ディスク使用率を確認してアラートを送信"""
    total, used, free = shutil.disk_usage(path)

    usage_percent = (used / total) * 100
    free_gb = free / (1024 ** 3)

    print(f"パス: {path}")
    print(f"使用率: {usage_percent:.1f}%")
    print(f"空き容量: {free_gb:.1f} GB")

    if usage_percent >= critical_threshold:
        send_alert(
            level="CRITICAL",
            message=f"{path} の使用率が {usage_percent:.1f}% です。"
                    f"空き容量: {free_gb:.1f} GB"
        )
    elif usage_percent >= warning_threshold:
        send_alert(
            level="WARNING",
            message=f"{path} の使用率が {usage_percent:.1f}% です。"
                    f"空き容量: {free_gb:.1f} GB"
        )

    return usage_percent

def send_alert(level, message):
    """メールアラートを送信"""
    msg = MIMEText(message)
    msg['Subject'] = f"[{level}] ディスク容量アラート"
    msg['From'] = "monitor@example.com"
    msg['To'] = "admin@example.com"

    with smtplib.SMTP('localhost') as server:
        server.send_message(msg)

if __name__ == '__main__':
    check_disk_usage('/')
    check_disk_usage('/data')

緊急時の容量確保手順

507エラーが発生してサービスが停止している場合は、以下の手順で迅速に容量を確保します。

# 1. まず現状を把握
df -h
du -h --max-depth=1 / | sort -rh | head -10

# 2. 即座に削除できるファイル
# 古いログファイル(圧縮済み)
rm -f /var/log/nginx/*.gz
rm -f /var/log/syslog.*.gz

# パッケージマネージャーのキャッシュ
apt-get clean          # Debian/Ubuntu
yum clean all          # CentOS/RHEL

# 古いカーネル(Ubuntu)
apt-get autoremove --purge

# 3. 大きな不要ファイルを探して削除
find /var -type f -size +100M -mtime +30 -ls
find /tmp -type f -mtime +1 -delete

# 4. ログの即時ローテーション
logrotate -f /etc/logrotate.conf

# 5. journalctl のログを圧縮(systemd環境)
journalctl --vacuum-size=100M
journalctl --vacuum-time=7d

# 6. 削除後の確認
df -h

この記事で使えるテストファイル(無料)

📚 関連記事

PNG vs WebP vs AVIF|画像フォーマットの選び方と変換方法

PNG / JPEG / WebP / AVIF の特徴・用途・ブラウザ対応状況を比較。picture 要素での出し分け、DevLab の画像フォーマット変換ツールの使い方も解説。

2026-04-18

Whois でドメイン情報を調べる方法|有効期限・ネームサーバー・登録者

Whois でわかること (登録者・有効期限・レジストラ・NS)、GDPR によるプライバシー保護の影響、ドメイン管理の実務的な使い方を解説。

2026-04-18

HTTP ステータスコード完全ガイド|よくあるエラーの原因と対処法

開発者が頻出する HTTP ステータスコード (200/301/302/400/401/403/404/413/422/429/500/502/503/504) の意味・原因・対処法を解説。301 vs 302 の SEO 影響、400 vs 422 の使い分けも。

2026-04-18

cURL コマンドを JavaScript fetch・Python requests に変換する方法|DevTools 連携

Chrome DevTools の Copy as cURL を fetch / axios / Python requests / PHP cURL / Go net/http に変換する手順を解説。主要 cURL オプション (-X / -H / -d / -F / -u / -b / -L) の変換パターン、認証トークンの扱い、注意点まで。

2026-04-16

Cookie のセキュリティフラグ完全ガイド|Secure / HttpOnly / SameSite / __Host-

Cookie のセキュリティ属性 Secure / HttpOnly / SameSite (Strict/Lax/None) / __Host- __Secure- プレフィックス / 4096 バイト制限を解説。CSRF / XSS / セッションハイジャック対策と、Laravel / Express の実装例。

2026-04-16

JWT のセキュリティベストプラクティス|alg none 攻撃 / 有効期限 / 署名検証

JWT (JSON Web Token) の代表的な脆弱性 6 種類 (alg none 攻撃 / 鍵混同 / 無期限トークン / payload への機密情報 / 失効不可 / 弱いシークレット) と対策。リフレッシュトークンパターン、失効リスト、HttpOnly Cookie 格納まで。

2026-04-16