WordPress에서 Storage Server 활용하기: 무엇이 되고 무엇이 안 되는지

wp-content/uploads 디렉터리는 WordPress에서 거침없이 커지는 부분입니다. 이미지, PDF 파일, 영상이 쌓이고, 거기에 WordPress가 이미지마다 자동으로 만들어 내는 여러 크기가 더해집니다. 몇 해가 지나면 거기에 수십 기가바이트가 놓이고, 웹 서버의 저장 공간은 살 수 있는 공간 가운데 가장 비쌉니다.

Storage Server는 그 비용의 일부만 듭니다. 문제는 무엇을 정말로 옮길 수 있느냐뿐입니다. 인터넷에는 이에 관해 실무에서는 통하지 않는 이야기가 많이 적혀 있습니다. 이 글에서는 세 가지 경우를 깔끔하게 나눕니다.

세 가지 경우 한눈에 보기

마지막 항목이 대부분이 걸려 넘어지는 곳입니다. 그래서 불편한 진실부터 먼저 말하겠습니다.

미디어 라이브러리에 맞는 플러그인이 없는 이유

널리 알려진 WordPress 외부 저장 플러그인은 모두 같은 말을 씁니다. 바로 S3입니다. Amazon S3나 그 호환 서비스에 연결해 파일을 거기로 올리고, 로컬 사본을 지우고, 글에 적힌 주소를 그 서비스의 공개 주소로 바꿉니다.

바로 그것을 Storage Server로는 옮겨 올 수 없고, 이유가 두 가지입니다.

• 스토리지는 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는 이미지마다 여러 크기를 만들어 두고 페이지를 열 때마다 그것을 불러옵니다. 이 작은 파일들이 네트워크 스토리지에 놓이면 파일마다 네트워크 지연이 더해지고, 이미지 마흔 장이 있는 갤러리는 마흔 번을 기다립니다.

두 가지 해법이 있고, 둘 다 좋습니다.

• 앞에 캐시를 두는 방법입니다. 예를 들어 웹 서버 안의 캐시가 내보낸 파일을 로컬에 들고 있게 합니다.
• 원본만 스토리지에 올리고 만들어진 크기들은 로컬에 남기는 방법입니다. 손이 조금 더 가지만, 이미지가 많은 사이트에는 가장 깔끔한 길입니다.

백업: 가장 빠른 이득

딱 한 가지만 한다면 이것을 하세요. 같은 서버에 있는 백업은 백업이 아닙니다. 디스크가 지워지거나 웹사이트가 암호화되면 백업도 함께 사라집니다. 분리된 스토리지에 있으면 살아남습니다.

무료 플러그인 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을 쓰고, 모든 사업자가 그런 포트로 나가는 연결을 허용하는 것은 아닙니다. 주문하기 전에 짧게 확인해 보는 편이 좋습니다.

용도마다 하위 계정 하나

모든 Storage Server는 하위 계정을 최대 100개까지 허용하며, 각 계정은 고유한 시작 디렉터리, 고유한 비밀번호, 고유한 프로토콜 권한을 가집니다. WordPress라면 최소한 두 개를 뜻합니다.

• 웹사이트용 계정, /uploads만 보이는 계정입니다.
• 백업용 계정, /backup만 보이는 계정입니다.

웹사이트가 한 번 넘어가면 공격자는 wp-config.php에서 첫 번째 계정의 접속 정보를 찾아냅니다. 백업은 손대지 못한 채로 남습니다. 이 계정이 백업을 아예 모르기 때문입니다. 기본 계정 하나만 썼다면 이 지점에서 모든 것이 사라졌을 것입니다.

여러 사용자가 각자의 용량을 필요로 할 때

Storage Server에는 하위 계정별 할당량이 없습니다. 계정은 자기 디렉터리 안에 머물지만, 그 안에서 요금제 전체를 채울 수 있습니다. 고객이나 사진가, 편집자에게 각자 제한된 용량을 주려면 그 일을 맡아 줄 애플리케이션을 앞에 두어야 합니다. Nextcloud가 가장 가까운 선택이고, 사용자, 할당량, 공유 링크를 함께 갖추고 있습니다: Nextcloud를 Storage Server와 연결하기.

어떤 요금제가 맞는지

백업을 포함한 WordPress 사이트 하나라면 Storage-1으로 보통 오래 버팁니다. 여러 사이트의 미디어 라이브러리를 옮기거나 영상 작업을 한다면 금방 Storage-2나 Storage-3에 이릅니다. 모든 요금제는 독일에 있고, 설치 비용이 없으며, 선불 방식으로 정산되고 최소 계약 기간이 없습니다. 한 단계 큰 요금제로 옮기는 것은 데이터를 건드리지 않고 언제든지 가능합니다.