ownCloud Infinite Scale을 위한 S3 객체 스토리지 구성 방법

ownCloud Infinite Scale은 파일 블롭을 위해 S3 호환 객체 스토리지를 사용하고 파일 메타데이터는 POSIX 호환 파일 시스템에 보관할 수 있습니다. 여기서 가장 먼저 이해해야 할 개념은 S3가 모든 로컬 데이터 디렉터리를 완벽하게 대체할 수 있는 것은 아니라는 점입니다. 지원되는 s3ng구성에서 객체 스토리지는 바이너리 파일 콘텐츠를 저장하고 메타데이터는 로컬 파일 시스템이나 NFS와 같은 POSIX 스토리지에 유지됩니다.

이 가이드는 2026년 10월 기준으로 제공되는 ownCloud Infinite Scale 스토리지 문서의 최신 버전을 기반으로 작성되었습니다. 이 가이드는 드라이버를 처음 접하는 관리자를 위해 작성되었으며, s3ngDocker Compose, systemd, Kubernetes 또는 기타 배포 방식에 적용하기 전에 이해하기 쉬운 구성 방법을 제공합니다.

이 가이드 전체에서 사용된 공식 참조 자료는 ownCloud S3 스토리지 문서 , Storage-Users 서비스 구성 및 일반적인 스토리지 고려 사항 입니다 .

ownCloud Infinite Scale에서 S3는 무엇을 의미합니까?

S3 는 아마존에서 처음 선보인 객체 스토리지 API입니다. S3 호환 서비스는 버킷 내에 데이터를 객체 형태로 저장하고 HTTP 기반 API를 통해 작업에 접근할 수 있도록 합니다. ownCloud Infinite Scale은 s3ng이러한 버킷에 파일 블롭을 저장하기 위해 스토리지 드라이버를 사용합니다.

POSIX 스토리지 란 Infinite Scale이 메타데이터에 대해 기대하는 파일 시스템 동작을 제공하는 파일 시스템을 의미합니다. 이 경우 s3ng메타데이터는 S3 버킷으로 이동하지 않습니다. ownCloud는 Blob은 S3로 이동하지만 메타데이터는 POSIX 스토리지에 유지된다는 사실을 명시적으로 문서화하고 있습니다.

이러한 구분은 흔히 발생하는 오류를 방지합니다. 즉, Infinite Scale을 버킷에 연결하고 서버 상태 전체가 해당 버킷에 저장된다고 가정하는 것을 막습니다. 서버 상태는 버킷에만 저장되는 것이 아닙니다. 백업 및 복구 계획은 POSIX 측 메타데이터와 S3 측 블롭 모두를 포함해야 합니다.

1단계: 버킷, 메타데이터 저장소, 자격 증명 및 네트워크 경로를 준비합니다.

무한 스케일을 변경하기 전에 다음 네 가지를 준비하세요.

• 전용 S3 버킷.
• 메타데이터를 위한 POSIX 규격 경로입니다 s3ng. 멀티 노드 배포의 경우, ownCloud는 공유 스토리지에 대해 신중하게 고려할 것을 권장합니다. NFS는 여러 Infinite Scale 인스턴스가 메타데이터 경로에 액세스해야 할 때 일반적으로 사용됩니다.
• Infinite Scale에 필요한 버킷 권한만 포함된 액세스 키와 비밀 키입니다.
• Infinite Scale 호스트 또는 컨테이너에서 S3 엔드포인트까지의 네트워크 연결 가능성(일반적으로 HTTPS를 통해).

버킷을 공개하지 마십시오. Infinite Scale은 자격 증명을 사용하여 버킷에 인증하므로 공개 액세스는 필요하지도 않고 바람직하지도 않습니다. 또한 전용 서비스 ID를 생성할 수 있는 경우 일반적인 관리자 자격 증명을 재사용하지 마십시오.

Amazon S3를 사용하는 경우 엔드포인트와 리전은 AWS 규정을 따릅니다. 다른 S3 호환 공급자를 사용하는 경우 해당 공급자의 설명서에서 엔드포인트 형식, 리전 동작, TLS 요구 사항 및 정책 구문을 확인하십시오. ownCloud는 특히 암호화 세부 정보와 같은 동작이 공급자마다 다를 수 있음을 경고합니다.

2단계: s3ng 드라이버를 활성화하고 S3 연결 설정을 제공합니다.

핵심 저장소 설정은 다음과 같습니다 STORAGE_USERS_DRIVER=s3ng. Storage-Users 서비스는 Infinite Scale 구성 요소로서 사용자 파일 저장소를 담당합니다. 공식 구성에서는 시스템 저장소 드라이버도 일반 ocis백엔드에 유지됩니다.

최소한의 환경 변수 세트는 다음과 같습니다.

STORAGE_USERS_DRIVER=s3ng
STORAGE_USERS_S3NG_ROOT=/var/lib/ocis/storage/users
STORAGE_SYSTEM_DRIVER=ocis

STORAGE_USERS_S3NG_ENDPOINT=https://s3.example.com
STORAGE_USERS_S3NG_REGION=us-east-1
STORAGE_USERS_S3NG_ACCESS_KEY=YOUR_ACCESS_KEY
STORAGE_USERS_S3NG_SECRET_KEY=YOUR_SECRET_KEY
STORAGE_USERS_S3NG_BUCKET=ocis-files

예시 값은 자리 표시자입니다. 실제 엔드포인트, 지역, 버킷 및 자격 증명은 서비스 제공업체에서 발급한 것을 사용하십시오. 비밀 키를 공개 Git 저장소에 커밋하지 마십시오. 컨테이너 오케스트레이션에서는 자격 증명을 Compose 파일이나 매니페스트에 직접 포함하는 대신 플랫폼의 비밀 키 관리 메커니즘을 사용하는 것이 좋습니다.

배포 방식에 따라 이러한 변수들이 어디에 위치할지 결정됩니다. Docker Compose 배포의 경우, Infinite Scale 서비스의 `<Property>` environment섹션에 변수를 배치하거나 환경 파일에서 불러올 수 있습니다. systemd 배포는 환경 파일이나 유닛 구성을 사용할 수 있습니다. Kubernetes는 일반적으로 Secret과 Deployment 또는 StatefulSet을 통해 변수를 주입합니다. 변수 이름이 중요하며, 주변 구문은 플랫폼에 따라 다릅니다.

3단계: Infinite Scale에 필요한 버킷 권한을 부여합니다.

버킷 정책 은 인증된 ID가 버킷 및 해당 객체에 대해 수행할 수 있는 작업을 제어하는 ​​ID 및 액세스 관리(IAM) 규칙입니다. ownCloud는 드라이버에 필요한 정책 패턴을 게시합니다 s3ng.

bucket-name다음 정책에서 버킷 이름을 실제 이름으로 바꾸십시오 .

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::bucket-name"]
    },
    {
      "Sid": "ActionsInBucketContext",
      "Effect": "Allow",
      "Action": [
        "s3:*Object",
        "s3:*MultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": ["arn:aws:s3:::bucket-name/*"]
    }
  ]
}

계정의 모든 버킷에 권한을 부여하여 액세스 거부 오류를 해결하지 마십시오 s3:*. 먼저 문서화된 버킷 범위 권한을 설정한 다음, S3 공급자가 공급자별 권한을 요구하는 경우에만 해당 권한을 조정하십시오.

4단계: Infinite Scale을 재시작하고 스토리지 경로를 확인합니다.

배포 환경에 맞는 일반적인 재시작 절차를 사용하여 구성을 적용하십시오. 예를 들어 systemd 설치의 경우 `--restart` 명령어를 사용할 수 있으며 systemctl restart ocis, Compose 배포의 경우 영향을 받는 서비스 컨테이너를 다시 생성하거나 재시작합니다. 시작 직후 로그를 확인하여 인증, DNS, TLS, 지역 또는 권한 오류가 있는지 확인하십시오.

S3 공급자의 CLI를 사용하여 버킷 목록을 확인하는 것은 호스트와 자격 증명으로 버킷에 접근할 수 있음을 증명하는 것이지만, 그것만으로는 Infinite Scale이 블롭을 올바르게 기록하고 있음을 증명하는 것은 아닙니다. 보다 정확한 엔드투엔드 테스트는 Infinite Scale을 시작하고 ownCloud 웹 인터페이스를 통해 작은 파일을 업로드한 다음 다시 다운로드하고 서비스 로그에서 오류를 확인하는 것입니다.

설치된 Infinite Scale 버전에 ownCloud에서 제공하는 blobstore 유지 관리 명령이 포함되어 있는 경우, 해당 명령을 사용할 수도 있습니다 ocis storage-users blobstore check. ownCloud는 이 명령을 구성된 blobstore에 대한 업로드/다운로드/삭제 왕복 작업으로 설명합니다. 버전별 구문은 공식 blobstore 검증 문서를 참조하십시오.

원본 파일 이름이 일반적인 S3 객체처럼 나타날 것이라고 기대하지 마십시오.

가장 흔히 저지르는 오해 중 하나는 버킷을 탐색할 때 익숙한 사용자 폴더 트리(예: `.`)를 기대하는 것입니다 Documents/report.pdf. Infinite Scale은 S3를 사용자가 직접 볼 수 있는 파일 시스템이 아닌 블롭 저장소로 취급합니다. 문서화된 s3ng키 형식은 스페이스 ID와 블롭 ID를 기반으로 하며, 사람이 읽을 수 있는 네임스페이스는 메타데이터에서 재구성됩니다.

즉, 버킷 내의 객체 키가 익숙하지 않다는 이유만으로 수동으로 이름을 바꾸거나, 재구성하거나, 삭제해서는 안 됩니다. 사용자 파일은 ownCloud를 통해 관리하세요. 버킷을 직접 조작하면 메타데이터와 Blob 간의 연결이 끊어질 수 있습니다.

대용량 업로드: 제작 전에 멀티파트 파일 크기를 확인하세요.

S3는 대용량 객체를 여러 부분으로 분할하여 업로드하는 멀티파트 업로드 기능을 사용합니다 . ownCloud 문서에서 STORAGE_USERS_S3NG_PUT_OBJECT_PART_SIZE부분 크기를 제어하는 ​​방법을 확인할 수 있습니다. 명시적인 값을 제공하지 않을 경우 기본값은 16MiB입니다.

Amazon S3는 멀티파트 업로드에서 최대 10,000개의 파트를 허용합니다. 파트 크기가 16MiB인 경우, 파트 개수 제한에 걸리기 전까지는 약 160GiB의 파일을 업로드할 수 있습니다. 사용자가 대용량 파일을 자주 업로드하는 경우, 대용량 전송 실패를 기다리기보다는 서비스 출시 전에 필요한 파트 크기를 계산하는 것이 좋습니다.

절충점은 명확합니다. 더 큰 용량의 버킷은 더 적은 요청으로 더 큰 최대 파일 크기를 지원하지만, 메모리, 버퍼링, 재시도 및 전송 특성이 변경됩니다. ownCloud는 또한 수신되는 파일 데이터가 버퍼링되는 동안 임시 저장 공간이 필요하므로 용량 계획에는 원격 버킷뿐만 아니라 전체 영역을 고려해야 한다고 지적합니다.

흔히 발생하는 문제와 우선 확인해야 할 사항

S3 블롭과 POSIX 메타데이터를 함께 백업합니다.

S3 버킷은 스토리지 상태의 절반 에 s3ng불과합니다. ownCloud의 백업 문서에 따르면 분산 S3 설정에는 구성, 시스템 데이터, 메타데이터 및 Blob이 포함되어야 합니다. 복원 문서에서도 마찬가지로 이러한 데이터 세트를 일관되게 복원해야 합니다.

운영 환경에서는 메타데이터 마운트, 버킷, 자격 증명 또는 역할, 구성 파일 및 백업 절차를 동일한 런북에 문서화해야 합니다. 설계에 의존하기 전에 복구 테스트를 수행하십시오. 관련 공식 참조 자료는 ownCloud 백업 가이드 및 복원 고려 사항 입니다 .

추천 시작점

첫 배포 시에는 설계를 단순하게 유지하십시오. 블롭 저장을 위한 전용 S3 버킷 하나, 영구적인 POSIX 메타데이터 경로 하나, 문서화된 버킷 권한을 가진 전용 서비스 ID, 객체 스토리지 엔드포인트에 대한 HTTPS 연결, 그리고 예상 파일 크기에 따라 변경이 필요한 경우가 아니면 기본 멀티파트 설정을 사용하십시오.

설정을 완료한 후에는 세 가지 계층을 각각 검증합니다. 버킷에 대한 네트워크 및 자격 증명 액세스, 스토리지 오류 없이 Infinite Scale이 시작되는지, 그리고 ownCloud를 통한 실제 업로드/다운로드를 확인합니다. 이러한 검사를 모두 통과하면 모니터링, 백업, 수명 주기 규칙 및 성능 튜닝 단계로 넘어갑니다. 이러한 순서로 진행하면 각 테스트가 서로 다른 질문에 대한 답을 제공하므로 문제 해결이 훨씬 쉬워집니다. "S3가 작동한다"는 것을 단일한 결과로만 간주해서는 안 됩니다.