추측 없이 ownCloud Infinite Scale과 Nextcloud 28을 비교해 보세요

CPU 그래프가 안정적일 때에도 파일 서버는 느리게 느껴질 수 있습니다. 디렉터리 목록을 불러오는 데 몇 초가 걸리거나, 업로드가 폭주할 때 멈추거나, 프로세스가 매일 더 많은 RAM을 소비하는 것처럼 보일 수 있습니다. ownCloud Infinite Scale(oCIS)과 Nextcloud 28을 단순히 "사용자당 RAM" 수치만으로 비교하는 것은 이러한 문제를 진단하는 데 도움이 되지 않습니다. 공식적인 동일 조건 벤치마크를 통해 어느 플랫폼이 더 우수한지 가늠할 수 없으며, 두 프로젝트 모두 메모리 요구량이 워크로드 및 구성에 따라 달라진다고 명시하고 있습니다. 유용한 비교를 위해서는 동일한 파일, 클라이언트, 스토리지, 동시 접속자 수, 테스트 기간을 사용하여 각 플랫폼을 측정하고, 먼저 병목 현상이 애플리케이션, 데이터베이스, 스토리지 또는 백그라운드 작업 중 어디에 있는지 확인해야 합니다.

또한 유지 관리 측면에서도 제약이 있습니다. Nextcloud 28은 공식 일정에 따라 2024년 12월에 지원이 종료되었습니다. 더 이상 커뮤니티 릴리스 채널에서 정기적인 수정 업데이트를 받지 못합니다. Nextcloud 28을 이미 사용 중인 경우, 성능 튜닝만으로 문제를 해결하려 하기 전에 업그레이드를 계획하십시오. 아래 단계는 동작을 비교하고 리소스 부하를 파악하는 데 도움이 되지만, 지원되지 않는 버전을 안전하게 사용할 수 있도록 해주는 것은 아닙니다.

RAM 용량과 시스템 속도 측정값이 다른 이유는 무엇인가요?

Infinite Scale과 Nextcloud는 서로 다른 서버 아키텍처를 사용합니다. oCIS는 Go 기반 플랫폼에서 서비스 형태로 구성되어 있으며, 내장된 슈퍼바이저가 하나의 서버 프로세스로 서비스를 시작합니다. 메모리 요구량에는 캐시된 사용자 및 스토리지 메타데이터가 포함될 수 있으며, ownCloud 문서에서는 메모리에 저장된 공간 및 메타데이터의 수와 사용 가능한 RAM, 액세스 또는 동기화 성능 간의 관계를 구체적으로 설명합니다. 초기 대규모 스캔 후 작업 세트가 더 커지는 것은 그 자체로 메모리 누수의 증거가 될 수 없습니다. 인덱싱 후 메모리가 안정화되는지, 그리고 지연 시간이 허용 가능한 수준으로 유지되는지 확인하십시오.

Nextcloud 28은 PHP 애플리케이션입니다. 전체 메모리 사용량은 PHP-FPM 워커 수와 워커별 동작 방식, 활성화된 앱, 웹 서버, 데이터베이스, 캐시, 미리보기 생성, 백그라운드 작업 등에 따라 달라집니다. 공식 관리 설명서에 따르면 메모리 요구 사항은 사용자, 앱, 파일, 서버 활동에 따라 크게 변동합니다. 워커 수를 늘리면 병렬 요청 처리가 향상되지만 최대 RAM 사용량이 증가할 수 있습니다. 따라서 PHP 프로세스 하나와 oCIS 프로세스 하나의 메모리 사용량을 비교하는 것이 아니라 호스트 또는 컨테이너 전체의 메모리 사용량을 비교해야 합니다.

스토리지는 두 플랫폼 모두에서 중요한 역할을 합니다. 디스크, 네트워크 파일 시스템, 객체 스토어, 데이터베이스 또는 바이러스 백신 검사 속도가 느리면 요청이 애플리케이션 병목 현상처럼 보일 수 있습니다. 마찬가지로, 캐시 상태가 좋지 않은 경우와 좋은 경우의 응답 시간은 다릅니다. 따라서 어떤 제품의 유휴 시간이 더 짧은지가 중요한 것이 아니라, 어떤 스택이 RAM 및 지연 시간 예산 내에서 실제 워크로드를 처리하는지가 중요합니다.

동일한 조건에서 비교하십시오.

1. 정확한 빌드 및 배포 정보를 기록하십시오. oCIS 버전, Nextcloud 28 패치 레벨, 운영 체제, 컨테이너 제한, CPU 할당량, 데이터베이스, 스토리지 백엔드, 활성화된 앱 및 서비스, PHP 버전, 웹 서버 등을 기록해 두십시오. 가능한 경우 동일한 하드웨어와 데이터 경로를 유지하십시오. 한 플랫폼의 컨테이너 메모리 제한과 다른 플랫폼의 전체 호스트 사용량을 혼합하여 사용하지 마십시오.
2. 대표적인 테스트 세트를 사용하십시오. 프로덕션 환경에서 속도가 느린 작업(초기 동기화, 증분 동기화, 대규모 디렉터리 탐색, 파일 다운로드 및 업로드, 공유, 동시 로그인)을 포함하십시오. 파일 개수, 파일 크기 분포, 활성 클라이언트 수 및 동시 접속자 수를 일관되게 유지하십시오. 스테이징 복사본을 사용하고 프로덕션 데이터에 과부하를 주지 마십시오.
3. 기준선을 측정한 후 반복합니다. 시작 후 유휴 메모리, 각 작업 부하 중 메모리 사용량, 최대 메모리 사용량, CPU 사용량, 디스크 I/O, 데이터베이스 활동, 요청 또는 동기화 지연 시간을 측정합니다. 클린 스타트 후 한 번, 캐시를 워밍업한 후 한 번 실행합니다. 결과가 안정적인지 확인하기 위해 각 실행을 충분히 반복합니다. 단일 실행 결과를 벤치마크로 간주하지 마십시오.
4. 애플리케이션 메모리와 호스트 메모리를 분리하십시오. 컨테이너의 경우 컨테이너의 메모리 작업 세트와 제한을 확인하고, Linux 프로세스의 경우 프로세스 모니터와 시스템 메모리 통계를 사용하십시오. 또한 스왑, 메모리 부족 이벤트 및 데이터베이스 메모리 사용량도 관찰하십시오. 호스트 캐시가 증가하는 것이 애플리케이션 메모리 누수와 동일한 것은 아니며, 컨테이너 제한은 런타임에 따라 메모리 사용량을 다르게 보고할 수 있습니다.

oCIS 모니터링의 경우, 서비스 메트릭 및 Prometheus 엔드포인트에 대한 자세한 내용은 해당 버전에 맞는 설명서를 참조하십시오. ownCloud 8.2 설명서에는 지원되는 서비스에 대한 메트릭이 설명되어 있으며, 메트릭은 서비스 및 릴리스에 따라 다릅니다. Nextcloud의 관리 개요 및 시스템 도구를 통해 설정 경고를 확인할 수 있으며, 총 RAM 사용량을 파악하려면 운영 체제 및 데이터베이스 모니터링이 필요합니다. 가능한 한 테스트 도구를 동일하게 유지하고 단위와 샘플링 간격을 기록하십시오.

무엇을 먼저 조정해야 할까요?

1. 실제 메모리 압박이 있는지 확인하십시오.

지속적인 높은 메모리 사용량과 함께 스와핑, OOM(메모리 부족)으로 인한 종료, 컨테이너 재시작 또는 요청 지연 시간 증가가 발생하는지 확인하십시오. 높은 RAM 사용량만 나타나는 경우는 유용한 캐싱을 나타낼 수 있습니다. 스캔 중에 사용량이 증가했다가 안정되면 메모리 증가가 불필요할 수 있습니다. 안정적인 작업 부하 상태에서 사용량이 계속 증가하고 안정되지 않으면 로그, 서비스 수준 메모리 및 제한 변경 전에 실행 중이던 작업을 검사하십시오.

2. 불필요한 배경 작업을 줄입니다.

미리 보기 생성, 바이러스 검사, 인덱싱, 동기화 급증 및 예약된 유지 관리와 같은 작업을 식별하십시오. 이러한 작업은 대화형 요청과 충돌할 수 있습니다. 사용량이 많은 작업은 사용량이 적은 시간대로 이동하거나 설치된 버전에 대한 문서화된 제어 기능을 사용하여 동시 실행 수를 줄이십시오. 그래프 크기를 줄이기 위해 보안 검사 또는 필수 유지 관리를 비활성화하지 마십시오. 먼저 작업 비용과 사용자에게 미치는 영향을 정량화해야 합니다.

3. Nextcloud의 PHP 및 캐시 구성을 신중하게 조정하십시오.

Nextcloud의 경우, 버전 28에서 지원되는 PHP 구성을 확인하고 사용 가능한 RAM에 맞춰 PHP-FPM 워커 크기를 조정하십시오. 워커 수가 너무 적으면 요청 대기열에 남을 수 있고, 너무 많으면 메모리가 부족해질 수 있습니다. 버전 28 설명서를 참조하여 필요한 경우 지원되는 메모리 캐시와 트랜잭션 파일 잠금을 위한 Redis를 구성하십시오. 캐시는 메모리를 소모하지만 반복 작업의 성능을 향상시킬 수 있으므로 지연 시간과 메모리 사용량을 함께 비교하십시오. 버전별 설명서를 확인하지 않고 현재 Nextcloud 릴리스의 설정을 버전 28에 복사하지 마십시오.

4. oCIS 메타데이터 및 저장 방식 검토

무한 확장(Infinite Scale)을 위해서는 공간 수, 파일 및 디렉터리 메타데이터, 스토리지 드라이버, 캐시 동작을 평가해야 합니다. 공식 필수 조건 문서에 따르면 메모리에 유지되는 메타데이터는 액세스 및 동기화 성능에 영향을 미칩니다. 대규모 목록 조회 또는 동기화 워크로드가 메모리 부족 현상과 동시에 발생하는 경우, RAM을 추가하기 전에 관련 서비스 및 스토리지 메트릭을 비교해야 합니다. 스토리지별 옵션은 정확한 oCIS 릴리스 버전을 기준으로 확인해야 하며, 스토리지 백엔드 간의 메모리 동작이 동일하다고 가정해서는 안 됩니다.

5. 제약 요인을 파악한 후에만 용량을 늘리십시오.

측정된 워크로드의 지연 시간이 안정적이고 허용 가능한 수준이지만 메모리 한계에 도달하는 경우, RAM을 추가하거나 리소스 할당을 조정하고 동일한 테스트를 반복하십시오. 메모리 사용량은 충분한데 지연 시간이 좋지 않은 경우, 데이터베이스 쿼리, 스토리지 지연 시간, 네트워크 처리량, 락, CPU 포화도를 조사하십시오. 적절하게 설계된 배포 환경에서는 oCIS 서비스를 확장하거나 워커를 추가하면 처리량을 향상시킬 수 있지만, 리소스 요구량과 운영 복잡성도 증가합니다. 결과를 명확하게 분석하려면 한 번에 하나의 변수만 변경하십시오.

결과를 확인하는 방법

각 변경 후 원래 작업 부하를 반복하고 동일한 지표(최대 및 정상 상태 RAM 사용량, 스왑 활동, p95 요청 또는 동기화 지연 시간(가능한 경우), 완료된 전송 수, 오류 또는 재시작 횟수)를 비교하십시오. 성공적인 수정은 다른 곳에 메모리 부담을 발생시키지 않으면서 사용자가 보고한 작동 문제를 개선해야 합니다. 공정한 플랫폼 비교를 위해 결과와 함께 테스트 조건을 게시하고 캐시가 콜드 상태인지 웜 상태인지 명시하십시오. 하나의 소규모 서버 또는 데이터 세트에서 얻은 결과를 일반화하지 마십시오.

마지막으로, Nextcloud 28의 지원 종료 상태는 별도의 운영 문제로 간주하십시오. 프로젝트의 업그레이드 지침을 사용하여 지원되는 릴리스로 이동한 다음 비교를 다시 실행하십시오. 최신 코드, PHP 버전, 애플리케이션 및 마이그레이션 변경 사항으로 인해 리소스 사용량이 달라질 수 있습니다. 현재 배포 요구 사항 및 릴리스별 설정은 ownCloud Infinite Scale 8.2 필수 조건 , Prometheus용 ownCloud 메트릭 , Nextcloud 28 시스템 요구 사항 , Nextcloud 28 메모리 캐싱 및 Nextcloud 유지 관리 및 릴리스 일정을 참조하십시오 .