ownCloud Infinite Scale과 Nextcloud 28 비교: 성능 및 RAM 사용량 설명

ownCloud Infinite Scale과 Nextcloud 28은 모두 자체 호스팅 파일 동기화 및 공유 기능을 제공하지만, 서버 아키텍처 방식은 매우 다릅니다. 이러한 차이는 메모리 사용량, 요청 지연 시간, 확장 동작, 그리고 배포에 필요한 튜닝 작업량을 예측할 때 중요한 요소입니다.

가장 중요한 주의사항은 다음과 같습니다. "Infinite Scale은 XMB를 사용하고 Nextcloud 28은 YMB를 사용한다"와 같은 신뢰할 수 있는 보편적인 수치는 없습니다. RAM 사용량은 활성화된 서비스, 사용자 동시 접속 수, 백그라운드 작업, 스토리지 백엔드, PHP 워커 수, 캐싱, 미리 보기, 오피스 통합 및 애플리케이션에 따라 달라집니다. 공식 문서에서도 두 제품에 대해 서로 다른 종류의 메모리 사용량 지침을 제공하므로 해당 수치를 직접적인 벤치마크로 간주하는 것은 오해의 소지가 있습니다.

또한 수명 주기 문제도 있습니다. Hub 7이라고도 하는 Nextcloud 28은 2023년 12월에 출시되어 2024년 12월에 지원이 종료되었으며, 마지막 28.x 릴리스는 28.0.14였습니다. 2026년 10월부터는 일반적인 버그 수정이나 보안 업데이트를 더 이상 받지 못합니다. 따라서 이 비교는 기존 Nextcloud 28 설치를 이해하거나 마이그레이션을 계획하는 데 가장 유용하며, 새로운 Nextcloud 28 배포를 권장하는 데는 적합하지 않습니다. Nextcloud의 공식 유지 관리 및 릴리스 일정을 참조하십시오 .

아키텍처 차이가 대부분의 성능 절충의 원인이 됩니다.

ownCloud Infinite Scale(설정 및 문서에서는 oCIS로 줄여서 부르는 경우가 많음)은 Go 언어 서비스 집합으로 구축되었습니다. 기본 런타임은 단일 프로세스 내에서 내장 서비스를 시작하고 내장된 슈퍼바이저를 통해 관리할 수 있습니다. ownCloud는 이러한 설계가 메모리 사용량을 줄이는 데 도움이 된다고 설명하며, 배포 규모 확장이 필요할 때 개별 서비스를 다른 노드로 이동할 수도 있습니다. 이 플랫폼은 핵심 운영에 PHP나 기존 애플리케이션 데이터베이스를 필요로 하지 않습니다. 자세한 내용은 공식 Infinite Scale 아키텍처 문서 및 Infinite Scale 관리 개요를 참조하십시오 .

Nextcloud 28은 익숙한 PHP 웹 애플리케이션 모델을 따릅니다. 일반적인 프로덕션 스택에는 Apache 또는 Nginx와 같은 웹 서버, PHP 또는 PHP-FPM 워커, 지원되는 관계형 데이터베이스, 그리고 일반적으로 메모리 캐싱이 포함됩니다. Nextcloud 자체 문서에서는 조직 배포 환경에서 로컬 캐싱에는 APCu를, 분산 캐싱 및 트랜잭션 파일 잠금에는 Redis를 권장합니다. 이러한 구성 덕분에 Nextcloud는 매우 유연하지만, 전체 메모리 예산이 단일 서버 프로세스가 아닌 여러 독립적인 프로세스와 서비스에 분산된다는 의미이기도 합니다.

RAM 사용량: 공식 수치의 실제 의미는 무엇일까요?

ownCloud의 현재 프로덕션 배포 예시에서는 최소 4~6GB의 메모리를 권장하며 , 바이러스 백신 검사를 활성화할 경우 추가 메모리가 필요하다고 명시하고 있습니다. 이 수치는 "oCIS 자체가 항상 4~6GB의 메모리를 사용한다"는 의미로 해석해서는 안 됩니다. 문서화된 설정에는 오피스 패키지 및 기타 필수 구성 요소도 포함됩니다. 자세한 내용은 공식 Infinite Scale 프로덕션 배포 예시를 참조하십시오 .

Nextcloud 28은 시스템 요구 사항 문서에서 다른 접근 방식을 취합니다. 사용자, 애플리케이션, 파일 및 활동에 따라 RAM 요구량이 크게 달라진다고 명시하면서 프로세스당 최소 128MB, 권장 512MB를 제시합니다 . 이는 여러 워커 프로세스가 동시에 활성화될 수 있는 PHP-FPM 환경에서 특히 중요합니다. 따라서 높은 동시성을 지원하도록 구성된 서버는 프로세스당 권장량보다 훨씬 더 많은 메모리를 확보할 수 있습니다. Nextcloud 28 시스템 요구 사항을 참조하십시오 .

파일 중심 작업 부하에서 어느 쪽이 더 가볍게 느껴질까요?

주요 작업 부하가 인증, 브라우징, 동기화, 업로드, 다운로드 및 공유인 경우, Infinite Scale의 Go 런타임 및 서비스 설계는 PHP 요청 스택과 관련된 오버헤드를 줄일 수 있습니다. ownCloud는 또한 서비스 통신의 일부에 gRPC와 같은 바이너리 프로토콜을 내부적으로 사용합니다. 이러한 아키텍처적 특징 덕분에 Infinite Scale은 PHP 워커 프로세스를 늘리지 않고도 높은 동시성을 확보할 수 있습니다.

그렇다고 해서 모든 스토리지 환경에서 처리량 측면에서 이점이 있는 것은 아닙니다 . 스토리지 지연 시간이 파일 작업에 큰 영향을 미칠 수 있고, TLS 및 역방향 프록시는 오버헤드를 추가하며, 메타데이터 동작은 선택한 스토리지 드라이버에 따라 달라지고, 선택적 서비스는 성능 프로필을 변경할 수 있습니다. ownCloud의 스토리지 관련 문서에서는 로컬 스토리지, NFS 및 S3 기반 배포 환경에 따라 메모리와 성능을 최적화하는 방법을 명확하게 설명하고 있습니다. 자세한 내용은 무한 확장 스토리지 고려 사항을 참조하십시오 .

Nextcloud 28은 올바르게 튜닝하면 뛰어난 성능을 발휘할 수 있습니다. 문서에 따르면 메모리 캐싱은 서버 성능을 크게 향상시킬 수 있습니다. APCu는 자주 사용되는 PHP 객체를 로컬에서 반복적으로 재구축하는 것을 방지하고, Redis는 분산 캐시 데이터와 트랜잭션 파일 잠금을 처리할 수 있습니다. 단일 조직 서버의 경우, Nextcloud 28은 로컬 캐시로 APCu를, 분산 캐싱 및 잠금에는 Redis를 권장합니다. 자세한 내용은 Nextcloud 28 메모리 캐싱 문서를 참조하십시오 .

Nextcloud의 RAM은 어디에 저장될까요?

Nextcloud 28의 경우, "Nextcloud RAM 사용량"은 여러 가지 할당량의 합계입니다. PHP-FPM 워커는 활성화된 PHP 모듈과 애플리케이션 코드에 따라 메모리를 소비합니다. 데이터베이스는 자체 버퍼와 연결 메모리가 필요합니다. Redis는 캐시된 객체와 잠금에 메모리를 사용합니다. APCu는 각 PHP 환경에 로컬 캐시를 유지합니다. 미리보기 생성, 바이러스 백신 통합, Talk, 전체 텍스트 검색 및 타사 앱은 자체 프로세스 또는 백그라운드 활동을 추가할 수 있습니다.

이 모델은 관리자에게 다양한 튜닝 옵션을 제공합니다. PHP-FPM 워커 제한을 줄이면 RAM 용량이 제한된 환경에서도 소규모 서버를 유지할 수 있지만, 부하가 걸리면 요청이 대기열에 쌓일 수 있습니다. 워커 수를 늘리면 CPU, RAM, 데이터베이스 연결 또는 I/O가 병목 현상을 일으키기 전까지 동시 처리 능력이 향상됩니다. 메모리가 부족한 환경에서는 Redis를 로컬 캐시로 사용하면 메모리를 절약할 수 있지만, Nextcloud 공식 문서에 따르면 충분한 RAM이 확보된 경우 APCu를 사용하는 것이 로컬 캐싱에 더 빠릅니다. 따라서 모든 호스트에 권장되는 단일 설정이 아니라 성능과 메모리 사용량 간의 실제적인 절충점을 고려해야 합니다.

Infinite Scale의 RAM은 어디에 위치할까요?

Infinite Scale은 여러 논리적 서비스로 구성되어 있지만, 내장 런타임을 통해 하나의 프로세스 내에서 내장 서비스를 관리하고 각 서비스를 Go 루틴에서 실행할 수 있습니다. ownCloud는 이를 관리자 친화적인 방식으로 플랫폼을 패키징하면서도 분산 배포를 위해 개별 서비스를 분리할 수 있도록 하는 방법이라고 설명합니다. 또한 내장된 슈퍼바이저는 실패한 서비스를 재시작하며, 모든 서비스를 외부 슈퍼바이저에서 실행하는 것보다 메모리 사용량을 줄여준다고 명시적으로 문서화되어 있습니다.

이러한 통합을 통해 단일 호스트에서 리소스 동작을 더 쉽게 파악할 수 있지만, RAM 사용량이 고정되는 것은 아닙니다. Collabora 또는 OnlyOffice 추가, 바이러스 백신 검사, 외부 ID 서비스, Redis 또는 NATS 기반 구성 요소, 썸네일 처리, 더 큰 캐시 추가 등은 리소스 사용량에 영향을 미칩니다. 서비스를 별도의 컨테이너나 Kubernetes Pod로 이동하면 기본 오버헤드가 증가할 수 있지만, 격리성과 수평적 확장성을 향상시킬 수 있습니다.

작업 부하별 성능 비교

어떻게 공정하게 벤치마킹할 것인가

성능이 결정적인 요소라면, 커뮤니티에서 제공하는 스크린샷이나 개별적인 메모리 용량 수치에 의존하지 말고 동일한 하드웨어에서 두 제품의 벤치마크 테스트를 진행하십시오. 동일한 저장 장치 또는 백엔드, 네트워크 경로, TLS 종료 방식, 테스트 파일 세트, 사용자 수, 클라이언트 동작을 사용해야 합니다. 안정적인 상태를 기록하기 전에 캐시를 미리 로드하고, 콜드 스타트 ​​동작도 별도로 측정하십시오.

유용한 지표로는 디렉터리 목록 보기, 메타데이터 작업, 소형 파일 업로드, 대형 파일 업로드, 다운로드 및 공유 생성에 대한 중앙값 및 95번째 백분위수 지연 시간, 초당 완료된 요청 수, 모든 관련 프로세스의 총 상주 메모리, CPU 사용률, 스토리지 IOPS, Nextcloud 데이터베이스 지연 시간, 백그라운드 작업 영향 등이 있습니다. 유휴 RAM은 사용 중인 RAM과 별도로 측정해야 합니다. 유휴 상태일 때는 메모리 사용량이 적어 보이는 시스템이라도 동시 사용 시 훨씬 더 많은 메모리를 할당할 수 있기 때문입니다.

Nextcloud의 경우 웹 서버, PHP-FPM, 데이터베이스, Redis 및 기타 애플리케이션 서비스를 모두 포함해야 합니다. Infinite Scale의 경우 oCIS 서비스에 더해 리버스 프록시, ID 구성 요소, 오피스 통합, 캐시 및 스토리지 관련 서비스까지 포함해야 합니다. 그렇지 않으면 벤치마크로 위장한 아키텍처 비교가 되어버립니다.

어떤 것을 선택하시겠습니까?

파일 중심의 최신 플랫폼을 우선시하고, Go 기반 서비스 아키텍처를 중요하게 생각하며, PHP 워커와 코어 서버에 필수적인 관계형 데이터베이스를 사용하는 운영 모델을 피하고 싶다면 ownCloud Infinite Scale을 선택하십시오. 특히 수평적 서비스 확장이나 대규모 파일 공유 환경을 계획하는 조직에 적합합니다.

Nextcloud 앱 생태계, 그룹웨어 통합, 기존 관리 지식 또는 애플리케이션 호환성이 런타임 계층 최소화보다 더 중요한 경우 지원되는 Nextcloud 릴리스를 선택하십시오 . 현재 Nextcloud 28을 실행 중인 경우 단기적으로 성능 튜닝이 도움이 될 수 있지만, 버전 28은 2024년 12월부터 지원이 종료되었으므로 보안 수명 주기 측면에서 업그레이드를 계획하는 것이 더 중요합니다.

만약 RAM 용량에 관한 결정이라면, 어느 벤더가 공개한 요구사항만으로는 만능 해결책을 제시하기 어렵습니다. Infinite Scale은 PHP와 기존 애플리케이션 데이터베이스를 핵심 스택에서 제거하고 효율적인 서비스 실행을 위해 의도적으로 설계한 반면, Nextcloud는 성숙한 캐싱 제어 기능과 고도로 구성 가능한 PHP 동시 실행 기능을 제공합니다. 따라서 가장 합리적인 선택은 실제로 운영할 전체 프로덕션 스택을 동일한 워크로드를 사용하여 비교하고, 특정 프로세스의 RAM 용량만 측정하는 것이 아니라 시스템 전체의 RAM 용량을 측정하는 것입니다.