NAS가 느리다고 느끼면 가장 먼저 CPU가 더 빠른 신제품을 찾기 쉽다. 하지만 실제 운영에서는 CPU가 원인이 아닌 경우가 많다.
파일 복사는 네트워크가 막고, Docker 데이터베이스는 디스크 latency가 막고, 여러 서비스를 동시에 올리면 RAM 부족과 swap이 문제를 만들 수 있다.
따라서 NAS 교체는 모델 비교보다 먼저 현재 workload에서 무엇이 포화됐는가를 확인해야 한다.
1. CPU: 평균 사용률보다 ‘언제 꽉 차는가’를 본다
CPU 사용률이 평소 10~20%라고 해서 충분하다고 단정할 수 없다.
백업 압축, 사진 인덱싱, 미디어 처리, 패키지 업데이트나 여러 컨테이너가 동시에 동작할 때 CPU가 장시간 100%에 붙는다면 사용자 체감이 급격히 나빠질 수 있다.
반대로 파일 저장과 공유가 주용도인데 CPU가 대부분 낮다면 더 빠른 프로세서로 바꿔도 체감효과는 제한적이다.
CPU 업그레이드가 필요한 신호는 단순한 순간 peak가 아니라 실제 업무시간에 반복적으로 계산 작업이 대기열을 만드는가다.
2. RAM: 남은 용량보다 swap과 OOM 위험을 본다
DSM과 Linux 계열 시스템은 사용하지 않는 메모리를 적극적으로 cache에 사용할 수 있기 때문에 “메모리가 거의 다 사용 중”이라는 화면만 보고 부족하다고 판단하면 안 된다.
더 중요한 것은:
- swap 사용이 지속적으로 증가하는가
- 컨테이너가 메모리 부족으로 재시작되는가
- VM과 Docker를 동시에 돌릴 때 응답성이 급격히 떨어지는가
- 백업·DB·미디어 작업이 겹칠 때 memory pressure가 발생하는가
이런 문제가 없다면 RAM을 늘려도 큰 차이가 없을 수 있다.
반대로 메모리 때문에 디스크 swap이 반복된다면 CPU보다 RAM 증설이 훨씬 직접적인 개선이다.
3. HDD I/O: CPU가 한가한데 느리다면 가장 먼저 의심한다
NAS에서 가장 흔하게 놓치는 병목 중 하나가 storage latency다.
대용량 동영상 한 개를 순차적으로 읽는 작업은 HDD도 잘 처리할 수 있다.
하지만 데이터베이스, Docker 로그, 작은 파일 수천 개, VM 시스템디스크처럼 작은 random I/O가 동시에 발생하면 상황이 달라진다.
이때 CPU는 한가해 보이는데 애플리케이션은 느릴 수 있다. CPU가 계산할 데이터가 디스크에서 오기를 기다리고 있기 때문이다.
HDD와 NVMe는 ‘빠른 저장장치’가 아니라 역할을 분리해서 쓴다
모든 데이터를 NVMe에 둘 필요는 없다.
대용량 사진·영상·백업 아카이브는 HDD의 용량당 비용이 유리하고, 다음과 같은 active workload는 SSD/NVMe의 low-latency 특성이 훨씬 큰 효과를 낼 수 있다.
- Docker volume
- 데이터베이스
- VM 시스템디스크
- 빌드·캐시·임시 작업공간
- 작은 파일을 빈번하게 읽고 쓰는 서비스
따라서 스토리지를 “빠른 디스크 vs 느린 디스크”로 나누기보다 active working set과 bulk/archive data로 나누는 편이 운영에 유리하다.
4. 네트워크: 스토리지가 빨라도 1GbE가 먼저 막을 수 있다
1GbE는 이론값과 프로토콜 overhead를 감안하면 실제 파일전송에서 대략 100MB/s 전후가 상한이 되는 경우가 많다.
NAS의 디스크가 그 이상을 처리할 수 있는데 대용량 파일복사만 느리다면 본체를 교체하기 전에 네트워크 경로를 확인해야 한다.
NAS 포트만 2.5GbE라고 끝나는 것도 아니다.
- 클라이언트 NIC
- 스위치
- 케이블
- 중간 라우팅 경로
전체 경로가 같은 속도를 지원해야 한다.
5. Docker와 VM은 같은 ‘NAS 앱’이 아니다
컨테이너는 호스트 커널을 공유하므로 일반적으로 VM보다 오버헤드가 작다.
반면 Windows 같은 완전한 운영체제를 VM으로 실행하면 별도의 메모리, CPU와 storage I/O를 계속 소비한다.
따라서 NAS를 파일서버로만 쓰던 시절에는 충분했던 사양이 Docker 몇 개와 VM 하나를 추가한 뒤 갑자기 부족해지는 것은 자연스럽다.
이때 필요한 것은 “NAS가 느리다”는 평가가 아니라 서비스별 resource budget이다.
| Workload | 주로 확인할 자원 |
|---|---|
| 파일서버 | 네트워크·HDD throughput |
| DB 컨테이너 | RAM·random I/O latency |
| 다수 Docker 서비스 | RAM·CPU·로그 I/O |
| Windows VM | RAM·CPU·storage latency |
| 백업 | 디스크·네트워크·압축 CPU |
6. 성능보다 더 중요한 병목: 복구시간
Production 용도로 NAS를 쓰기 시작하면 “평소 얼마나 빠른가”만큼 중요한 질문이 있다.
고장났을 때 몇 시간 안에 복구할 수 있는가?
데이터가 수 TB로 늘어난 뒤 백업은 성공하지만 restore에 며칠이 걸린다면 운영 관점에서는 이미 병목이다.
새 NAS나 더 많은 디스크를 검토할 때는:
- backup window
- restore throughput
- snapshot 활용
- off-device backup
- 장애 시 서비스 우선순위
까지 같이 본다.
NAS의 성능은 정상상태의 benchmark뿐 아니라 장애상태의 RTO에도 나타난다.
업그레이드 전에 4가지 개선을 먼저 시험한다
본체 교체 전 다음 조치로 해결되는지 확인할 수 있다.
- 불필요한 서비스와 동시 작업을 줄인다.
- 메모리 pressure가 원인이면 RAM을 증설한다.
- I/O가 민감한 active workload를 SSD/NVMe로 분리한다.
- 파일전송 병목이면 네트워크 경로를 개선한다.
이 조치 후에도 CPU 또는 플랫폼 한계가 명확하다면 본체 교체의 근거가 생긴다.
Synology DS725+ 같은 모델도 ‘스펙’보다 배치가 중요하다
예를 들어 Synology DS725+는 공식 사양상 Ryzen R1600, 2개의 메모리 슬롯과 최대 32GB 메모리, 1GbE와 2.5GbE 포트, 2개의 M.2 NVMe 슬롯을 제공하고 지원 SSD를 이용한 SSD storage pool 구성도 지원한다.
하지만 이런 사양이 있다는 것 자체가 성능을 보장하지는 않는다.
DB를 HDD에 두고 NVMe를 사용하지 않으면서 CPU만 업그레이드한다면 기대한 효과가 없을 수 있다. 반대로 random-I/O가 병목인 환경에서 active data를 NVMe에 분리하면 본체를 바꾸지 않고도 체감이 크게 달라질 수 있다.
호환 가능한 드라이브·메모리와 지원 기능은 DSM 및 제품 정책이 바뀔 수 있으므로 실제 구성 시에는 Synology 공식 compatibility와 모델 문서를 다시 확인해야 한다.
교체할 시점은 ‘불편하다’가 아니라 측정 가능한 조건으로 정한다
다음 중 하나가 반복되면 본체 교체를 본격 검토할 이유가 있다.
- 필요한 workload에서 CPU가 장시간 포화된다.
- 최대 지원 RAM으로도 memory pressure를 해결할 수 없다.
- 필요한 네트워크 대역폭을 해당 모델이 제공할 수 없다.
- VM·컨테이너·DB workload에 필요한 I/O 구성이 불가능하다.
- 스토리지 확장성 자체가 향후 용량계획을 충족하지 못한다.
- backup/restore window가 운영 요구사항을 만족하지 못한다.
결론
NAS 업그레이드는 CPU 세대 비교부터 시작하면 안 된다.
CPU → RAM → storage latency → network → workload architecture → recovery time 순서로 실제 병목을 찾는 것이 먼저다.
병목이 특정 자원 하나라면 RAM, NVMe 또는 네트워크 개선이 본체 교체보다 저렴하고 효과적일 수 있다.
반대로 여러 자원이 동시에 한계에 도달하고 확장성까지 부족하다면 그때는 새 NAS가 단순한 성능 업그레이드가 아니라 운영 리스크를 줄이는 인프라 투자가 된다.