Storage Server を WordPress で使う：できることとできないこと

ディレクトリ wp-content/uploads は、WordPress のなかで歯止めなく膨らんでいく部分です。画像、PDF ファイル、動画、さらに WordPress が自動で生成する各画像の複数サイズ。数年経てば数十ギガバイトがそこに溜まり、ウェブサーバーの容量は買えるもののなかで最も高価です。

Storage Server の費用はその数分の一です。問題は、実際に何を外へ出せるのかという点だけです。ネット上には、実務では機能しない情報が多く載っています。本記事では 3 つのケースをはっきり分けます。

3 つのケースの概要

最後の項目が、多くの人がつまずくところです。ですから、まず不都合な事実から始めます。

メディアライブラリ向けのプラグインが存在しない理由

WordPress でよく知られているオフロード系のプラグインは、どれも同じ言葉を話します。S3 です。Amazon S3 かその互換サービスに接続し、そこへファイルをアップロードし、ローカルのコピーを削除して、投稿内のアドレスをそのサービスの公開アドレスに置き換えます。

これをそのまま Storage Server に移すことはできません。理由は 2 つあります。

• ストレージは SMB、SFTP、WebDAV を話しますが、S3 は話しません。
• ファイルごとの公開アドレスがありません。すべてのアクセスに認証が必要なので、訪問者のブラウザーが直接呼び出せるリンクは存在し得ません。

FTP で動くプラグインは個別に存在しますが、メディアライブラリを SFTP や WebDAV で完全に外へ出せて、しかも相応の普及と現在も続く保守を備えたものはありません。見つけた場合は、使う前に最終更新日とアクティブインストール数を確認してください。

うまくいく道：外へ出すのではなくマウントする

root 権限のある自前のサーバーでは、話を逆にします。WordPress に外部ストレージと会話することを教え込むのではなく、WordPress がもともと書き込む場所にストレージを持ってくるのです。

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=YOUR_PASSWORD\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

/etc/fstab への記述は次のとおりです。

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

続いて既存のファイルを移し、ディレクトリを置き換えます。

mount -a
mkdir -p /mnt/storage/uploads
rsync -a /var/www/example.com/wp-content/uploads/ /mnt/storage/uploads/
mv /var/www/example.com/wp-content/uploads /var/www/example.com/wp-content/uploads.alt
ln -s /mnt/storage/uploads /var/www/example.com/wp-content/uploads

WordPress はそれに気づきません。アプリケーションからすればまったく普通のパスです。古いディレクトリは uploads.alt として、すべて問題なく動くことを確認するまで残しておきます。削除するのはその後で、先に消してはいけません。

ここでの落とし穴：サムネイル

WordPress は各画像から複数のサイズを生成し、ページを表示するたびにそれらを読み込みます。この小さなファイルがネットワークストレージ上にあると、ファイルごとにネットワークの待ち時間が加わり、40 枚の画像があるギャラリーは 40 回待つことになります。

解決策は 2 つあり、どちらも有効です。

• 前にキャッシュを置きます。たとえば、配信したファイルをローカルに保持するウェブサーバー内のキャッシュです。
• オリジナルだけをストレージに置き、生成されたサイズはローカルに残します。手間は少し増えますが、画像の多いサイトにとっては最もきれいな方法です。

バックアップ：最も早く効く使い道

1 つだけ手を打つなら、これにしてください。同じサーバー上のバックアップは、バックアップではありません。ディスクが消去されたりウェブサイトが暗号化されたりすれば、一緒に失われます。分離したストレージ上なら生き残ります。

無料のプラグイン WPvivid は、基本版でも SFTP でストレージへバックアップでき、スケジュールと保持ルールも使えます。詳しい手順は WordPress のバックアップを Storage Server へ で解説しています。

自前のサーバーなら、さらに良い方法があります。スケジュールから直接 rsync か BorgBackup を動かすやり方です。これなら変更分だけを転送でき、BorgBackup はさらに重複排除も行います。

大きなダウンロードを配信する

訪問者にダウンロードさせるファイルには、ストレージが最適です。読まれる頻度は低く、サイズは大きく、速い必要はなく、届けばよいからです。アクセスは、先に権限を確認する小さなスクリプトを通します。

<?php
// functions.php の中か、独自のプラグインとして
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('ログインしてください', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('ファイルが見つかりません', '', ['response' => 404]);
    }

    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="' . basename($pfad) . '"');
    header('Content-Length: ' . filesize($pfad));
    readfile($pfad);
    exit;
});

この例はマウント済みのストレージを前提にしています。マウントしない場合は、readfile() を SFTP か WebDAV の取得処理に置き換えます。その方法は Storage Server を自分のウェブサイトで使う で解説しています。

副作用も心地よいものです。ファイルが公開アドレスを持たないので、誰もリンクを他人に渡せません。権限の確認を回避することもできません。

共用ホスティングで残るもの

共用ホスティングでは、HTTPS 経由の WebDAV が最も確実な道です。ポート 443 が塞がれていることはまずないからです。SFTP も機能しますが、当社ではポート 23 で動いており、そうしたポートへの外向き接続をすべての事業者が許可しているわけではありません。これは注文の前に軽く確認しておくべきです。

用途ごとに 1 つのサブアカウント

どの Storage Server でも、専用のホームディレクトリ、専用のパスワード、専用のプロトコル許可を持つサブアカウントを最大 100 個まで作成できます。WordPress では、少なくとも 2 つを用意します。

• ウェブサイト用のアカウント、/uploads しか見えないもの。
• バックアップ用のアカウント、/backup しか見えないもの。

ウェブサイトが乗っ取られると、攻撃者は wp-config.php の中で 1 つ目のアカウントの認証情報を見つけます。それでもバックアップは手つかずのままです。このアカウントはバックアップの存在すら知らないからです。メインアカウント 1 つだけで運用していたら、この場面ですべてを失っていました。

複数のユーザーに専用の容量が必要な場合

Storage Server にはサブアカウントごとのクォータがありません。アカウントは自分のディレクトリの中にとどまりますが、その中でプランの容量をすべて埋められます。顧客、カメラマン、編集者にそれぞれ上限付きの枠を与えたいなら、その役割を引き受けるアプリケーションを前に置きます。Nextcloud が最も近い選択で、ユーザー、クォータ、共有リンクを備えています。Nextcloud と Storage Server を連携する をご覧ください。

どのプランが合うか

バックアップ付きの WordPress サイトが 1 つだけなら、Storage-1 で通常は長く足ります。複数サイトのメディアライブラリを外へ出す場合や動画を扱う場合は、すぐに Storage-2 や Storage-3 になります。どのプランもドイツに設置され、初期費用はなく、プリペイド方式で請求され、最低契約期間もありません。1 つ上のプランへの変更は、データに手を触れずにいつでも可能です。