Nextcloud를 Storage Server에 연결하기: 용량, 할당량, 공유

Nextcloud는 Storage Server가 하지 못하는 일을 모두 할 수 있습니다. 사용자를 관리하고, 각자에게 용량 한도를 따로 배정하고, 폴더를 공유하고, 비밀번호와 만료일이 붙은 링크를 만들고, 파일을 HTTPS로 브라우저에 내보내는 일입니다. 반대로 Nextcloud를 비싸게 만드는 것은 용량입니다. 그 용량이 서버의 NVMe SSD에 놓이기 때문입니다.

이 둘을 합치면 실무에서 자리를 잡은 구성이 나옵니다. Nextcloud는 작은 서버에, 파일은 Storage Server에 둡니다. 이 글에서는 두 가지 설정 방법을 모두 보여 주고, 어느 쪽이 언제 더 나은지 설명하고, 그 과정에서 어김없이 나타나는 함정을 짚습니다.

이 조합이 유난히 잘 맞는 이유

많은 프로젝트에서 결정적인 점은 이것입니다. Storage Server에는 하위 계정별 할당량이 없습니다. 하위 계정은 자기 디렉터리 안에 머물기는 하지만, 그 안에서 요금제 전체를 다 채울 수 있습니다. Nextcloud가 바로 그 문제를 풀어 줍니다. 거기서는 사용자마다 넘을 수 없는 용량 한도를 받기 때문입니다.

두 가지 방법, 그리고 어느 쪽이 더 나은지

방법 A: Nextcloud가 내장된 SMB 또는 SFTP 드라이버로 스토리지에 직접 접속합니다. 운영체제는 손대지 않아도 됩니다.

방법 B: 스토리지를 운영체제에서 디렉터리로 마운트하고, Nextcloud에서는 그 디렉터리를 가리키는 “로컬” 유형의 외부 저장소를 설정합니다.

root 권한이 있다면 방법 B를 쓰세요. 파일 시스템을 거치는 쪽이 Nextcloud의 SFTP 드라이버보다 눈에 띄게 빠르고, 특히 작은 파일이 많을 때 그렇습니다. 그리고 네트워크 장애도 더 잘 넘깁니다. 방법 A는 운영체제를 바꿀 수 없거나 바꾸고 싶지 않을 때의 답입니다.

준비: 전용 하위 계정 만들기

고객 포털에서 Nextcloud만을 위한 하위 계정을 만드세요. 시작 디렉터리도 따로 주고, 예를 들면 /nextcloud로 둡니다. 실제로 쓰는 프로토콜만 허용하세요. 그리고 “접근 설정”에서 외부 접근 허용이 켜져 있는지 확인하세요. 꺼져 있으면 서버가 스토리지에 닿지 못합니다.

이 글의 예시는 아래 값을 사용하니, 본인의 값으로 바꿔서 입력하세요.

방법 B: 마운트해서 로컬 저장소로 쓰기

먼저 마운트입니다. Debian과 Ubuntu에서는 이렇게 합니다.

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

중요한 옵션은 세 가지입니다. uid=www-data는 웹 서버가 쓰기를 할 수 있게 해 주고, seal은 SMB 3으로 전송을 암호화하고, _netdev와 nofail은 스토리지가 마침 응답하지 않을 때 서버가 부팅 중에 멈추는 것을 막아 줍니다.

mount -a
sudo -u www-data touch /mnt/storage/test && echo "쓰기 접근 정상"

그다음 Nextcloud에서 “External storage support” 앱을 켜고 스토리지를 등록합니다. 화면에서는 관리, 외부 저장소 메뉴에서 하고, 명령줄에서는 이렇게 합니다.

sudo -u www-data php occ app:enable files_external
sudo -u www-data php occ files_external:create 데이터 local null::null -c datadir=/mnt/storage
sudo -u www-data php occ files_external:list

이제 “데이터” 폴더가, 접근을 허용한 사용자에게 나타납니다. 허용 범위는 사용자별 또는 그룹별로 정하므로, 모두가 모든 것을 보지는 않게 됩니다.

방법 A: Nextcloud에서 바로 외부 저장소 등록

root 권한이 없어도 마운트 없이 됩니다. SMB에는 그에 맞는 PHP 확장이 필요합니다.

apt install -y smbclient php-smbclient
systemctl restart php8.3-fpm

그다음 관리, 외부 저장소에서 항목을 하나 만듭니다.

SFTP를 쓰려면 유형을 “SFTP”로 고르고, 호스트에는 u123456.storage.kernelhost.net을, 포트에는 23을 넣습니다. 이 방법에서 가장 흔한 오류의 원인이 바로 이것입니다. Nextcloud는 22를 제시하지만, 우리 스토리지는 23에서 듣습니다.

사용자마다 할당량 주기

이제 이 구성 전체를 정당화하는 부분입니다. 관리, 사용자 메뉴에서 계정마다 용량 한도를 적습니다. 예를 들어 50 GB입니다. 명령줄에서는 이렇게 합니다.

sudo -u www-data php occ user:setting photographer1 files quota "50 GB"

Nextcloud는 이때 버전과 휴지통도 함께 셉니다. 그것이 맞는 동작이지만 사람을 놀라게 하기도 합니다. 50 GB를 받아 50 GB를 올린 사람은 오래된 버전 때문에 생각보다 빨리 더 많이 차지하게 됩니다. 추가보다 교체가 많은 계정에서는 버전 보관 기간을 제한하는 편이 이득입니다.

내 웹사이트를 위한 공유 링크

Nextcloud에게 외부 저장소는 다른 폴더와 똑같은 폴더이므로, 공유도 그대로 동작합니다. 비밀번호와 만료일이 붙은 링크는 세 번 클릭으로 만들어지고, 파일은 스토리지에서 바로 나가지 않고 Nextcloud를 거쳐 나갑니다. 그래서 스토리지 접속 정보는 서버를 떠나는 일이 없습니다.

이것이 바로 Storage Server 하나만으로는 빠져 있는 조각입니다. 다운로드 영역이 있는 웹사이트를 운영한다면 사용자 관리와 권한, 전송을 한 번에 얻게 되고, 직접 프로그래밍할 것도 없습니다. Nextcloud 없이 가는 쪽은 어떤 모습인지는 Storage Server를 내 웹사이트에 활용하기에서 다룹니다.

어김없이 나타나는 네 가지 함정

• 데이터 디렉터리는 스토리지에 두지 않습니다. 기술적으로는 되지만 실무에서는 위험합니다. Nextcloud는 거기에 잠금 파일과 중간 상태도 쓰기 때문에, 짧은 네트워크 장애 하나로 인스턴스 전체가 멈춥니다. 외부 저장소로 붙여 두면 장애는 그 폴더 하나에만 닿습니다.
• 데이터베이스는 로컬에 남습니다. 언제나 그렇습니다. 스토리지에는 파일만 두고, 그 밖의 것은 두지 않습니다.
• Redis를 설정하세요. 파일 잠금을 받아 둘 캐시가 없으면, 외부 저장소를 쓰는 Nextcloud는 눈에 띄게 느려집니다. 잠금이 하나하나 데이터베이스를 거치기 때문입니다.
• 22가 아니라 포트 23입니다. SFTP에서 Nextcloud는 22를 제시합니다. 우리 스토리지는 23에서 듣고, 그에 대한 오류 메시지는 별로 도움이 되지 않습니다.

어떤 서버와 어떤 요금제를 고를지

Nextcloud 자체에는 작은 장비로 충분합니다. 파일은 다른 곳에 있고 서버는 관리만 하기 때문입니다. 활성 사용자가 몇 명에서 수십 명 정도라면 RAM 4 GB에서 8 GB로 충분합니다. 다만 Redis가 돌고 백그라운드 작업이 설정되어 있어야 합니다. 그 안내는 내 서버에 Nextcloud 설치하기에 있습니다.

스토리지는 필요한 용량에 따라 고르면 됩니다.

모든 Storage Server는 독일에 있고, SMB와 SFTP, WebDAV 등을 지원하며, 하위 계정을 최대 100개까지 허용하고 스냅샷도 함께 제공합니다. 설치 비용이 없고, 선불 방식으로 정산되며, 최소 계약 기간도 없습니다. 필요한 용량이 늘어나면 데이터는 손대지 않고 더 큰 요금제로 옮기면 됩니다.