Synology DS423+ NAS 디스크 지연 줄이기｜HDD 절전·SSD 캐시 점검

Synology DS423+에서 WordPress와 여러 Docker 서비스를 운영하다 보면 NAS 전체가 느리지는 않은데, 특정 순간에 관리자 화면이나 파일 접근이 몇 초씩 늦어지는 경우가 있습니다.

제 환경에서도 WordPress 관리자 화면의 메뉴를 열거나 글 목록에 접근할 때 대부분은 정상적으로 열렸지만, 가끔 약 5~9초 정도 기다려야 하는 현상이 발생했습니다.

이번 점검의 목적은 HDD의 최대 읽기·쓰기 속도를 높이는 것보다 HDD가 절전 상태에서 깨어날 때 발생할 수 있는 첫 접근 지연과 백업·검사 작업이 겹치면서 생기는 순간적인 디스크 대기를 줄이는 데 초점을 맞췄습니다.

내장 HDD의 최대 절전 모드를 해제하고, Hyper Backup과 데이터 스크러빙, S.M.A.R.T. 검사, 백신 검사 시간을 서로 겹치지 않도록 분리했습니다. HDD 쓰기 캐시 상태도 DSM과 SSH에서 확인했으며, SSD를 구매하기 전 실제 접근 패턴을 파악하기 위해 SSD 캐시 어드바이저 분석도 시작했습니다.

여러 설정을 함께 조정했기 때문에 특정 설정 하나가 지연을 해결했다고 단정할 수는 없습니다. 다만 점검 이후 기존처럼 5~9초씩 기다려야 했던 현상은 현재 거의 나타나지 않고 있습니다.

WordPress 관리자 화면에서 간헐적인 지연이 발생했다

현재 Synology DS423+에서는 WordPress와 MariaDB뿐 아니라 Bitcoin Core, Fulcrum, Synology Photos, Synology Drive, Hyper Backup 등 여러 서비스를 함께 운영하고 있습니다.

NAS를 단순한 파일 저장 장치로만 사용하는 것이 아니라 데이터베이스와 Docker 서비스가 계속 디스크에 접근하는 홈서버로 사용하고 있는 셈입니다.

집에서 NAS 서버를 운영하는 이유

문제는 NAS가 계속 느린 것이 아니라는 점이었습니다.

WordPress 관리자 화면이나 글 목록이 대부분 빠르게 열리다가 가끔 한 번씩 약 5~9초 정도 지연됐습니다. 이후 같은 메뉴를 다시 누르면 바로 열리는 경우도 있었습니다.

이런 증상은 네트워크의 최대 전송속도가 낮아서 나타나는 일반적인 속도 저하와는 조금 다르게 느껴졌습니다. 특정 순간의 첫 접근이나 백그라운드 작업과 관련된 디스크 대기를 먼저 의심해볼 수 있는 형태였습니다.

이번에는 다음 항목을 차례로 확인했습니다.

내장 HDD 최대 절전 모드
Hyper Backup과 무결성 검사 일정
데이터 스크러빙 일정
HDD별 S.M.A.R.T. 검사 일정
Antivirus Essential 검사 시간과 범위
Synology Photos와 파일 색인 상태
HDD 쓰기 캐시 상태
SSD 캐시 어드바이저 분석

점검한 Synology DS423+ 환경

이번 점검 당시 NAS 환경은 다음과 같습니다.

항목	구성
NAS	Synology DS423+
DSM	7.3.2
메모리	총 18GB
HDD	WD Red Plus 4TB 4개
볼륨 용량	약 10.5TB
네트워크	1Gbps
주요 서비스	WordPress, MariaDB, Bitcoin Core, Fulcrum, Synology Photos, Synology Drive, Hyper Backup

기본 메모리에 16GB 메모리를 추가해 총 18GB로 사용하고 있습니다.

시놀로지 DS423+ RAM 16GB 업그레이드 후기｜총 18GB 사용 체감

메모리 부족으로 NAS 전체가 계속 느려지는 상황은 아니었기 때문에, 이번에는 디스크 절전과 백그라운드 작업이 겹치는 시간을 중심으로 점검했습니다.

내장 HDD 최대 절전 모드를 해제한 이유

DSM에서는 일정 시간 동안 HDD 접근이 없으면 디스크 회전을 멈추는 최대 절전 모드를 설정할 수 있습니다.

절전 상태에 들어간 HDD에 다시 접근하면 디스크가 회전을 시작하고 정상 속도에 도달할 때까지 시간이 필요합니다. 이 과정에서 처음 여는 폴더나 서비스 화면이 늦게 반응하는 것처럼 느껴질 수 있습니다.

제 NAS의 내장 HDD 최대 절전 모드는 기존에 20분으로 설정돼 있었습니다. 이번 점검에서는 내장 HDD의 최대 절전 모드를 없음으로 변경했습니다.

상시 서비스가 많으면 HDD가 충분히 쉬기 어렵다

HDD 절전은 파일 저장용으로 사용하거나 접근 횟수가 적은 NAS에서는 전력 소비와 소음을 줄이는 데 도움이 될 수 있습니다.

하지만 제 환경에서는 다음과 같은 서비스가 계속 동작하고 있습니다.

WordPress와 MariaDB
Bitcoin Core와 Fulcrum
Synology Photos
Synology Drive
Docker 컨테이너
Hyper Backup
DSM의 각종 로그와 유지관리 작업

이런 환경에서는 HDD가 절전 상태에 들어가더라도 얼마 지나지 않아 다른 서비스가 다시 접근할 가능성이 있습니다.

절전과 재가동이 반복된다면 실제 절전 효과는 크지 않으면서 첫 접근 지연만 체감될 수도 있습니다. 그래서 상시 서비스가 많은 현재 환경에서는 내장 HDD를 계속 동작시키는 쪽이 더 적합할 수 있다고 판단했습니다.

내장 HDD 절전 해제의 장점과 단점

내장 HDD 절전 모드를 해제하면 다음과 같은 장점을 기대할 수 있습니다.

절전 상태에서 깨어나는 첫 접근 시간 감소 가능
스핀업과 스핀다운 반복 감소
상시 운영 서비스의 접근 반응 개선 가능

반대로 다음과 같은 단점도 있습니다.

대기 중 전력 소비 증가
HDD 작동 소음 증가 가능
내부 온도 상승 가능
파일 저장 위주로 사용하는 환경에서는 불필요한 상시 회전이 될 수 있음

설정 변경 후 확인한 HDD 온도는 약 31~34℃ 범위였습니다. 이 수치는 이번 점검 당시 제 환경에서 확인한 값일 뿐, 모든 NAS 환경에 적용되는 절대적인 정상 기준은 아닙니다.

NAS 설치 장소, 실내 온도, 환기 상태, HDD 종류에 따라 온도는 달라질 수 있습니다.

외장 USB 백업 HDD는 절전 설정을 유지했다

내장 HDD와 달리 외장 USB HDD는 Hyper Backup 작업이 실행될 때 주로 사용합니다.

평소에는 계속 접근할 필요가 없기 때문에 외장 USB 백업 HDD의 최대 절전 모드는 기존 20분 설정을 유지했습니다.

내장 HDD와 외장 백업 HDD의 역할이 다르기 때문에 절전 설정도 동일하게 맞출 필요는 없다고 생각했습니다.

디스크 작업이 겹치지 않도록 전체 일정을 분리했다

NAS에서는 백업 외에도 데이터 스크러빙, S.M.A.R.T. 검사, 백신 검사 등 여러 유지관리 작업이 실행됩니다.

각 작업은 데이터 보호를 위해 필요한 기능이지만, 여러 작업이 같은 시간에 실행되면 HDD 읽기와 쓰기가 한꺼번에 증가할 수 있습니다.

이번에는 유지관리 작업을 서로 겹치지 않도록 시간을 분산했습니다.

현재 구성한 스케줄은 다음과 같습니다.

작업	실행 일정
Hyper Backup	매일 00:30
Hyper Backup 무결성 검사	매주 일요일 05:00
무결성 데이터 검사 제한	최대 30분
데이터 스크러빙	3개월마다
일요일 스크러빙 허용 시간	02:00~05:00
월요일~토요일 스크러빙 허용 시간	02:00~08:00
빠른 S.M.A.R.T. 검사	HDD별 월 1회, 날짜 분리
확장 S.M.A.R.T. 검사	HDD별 3개월마다, 날짜 분리
Antivirus Essential	매주 일요일 06:00

이 스케줄은 모든 NAS 사용자에게 그대로 적용할 수 있는 권장값이 아닙니다.

NAS를 많이 사용하는 시간, 백업 데이터 크기, HDD 수, 서비스 종류에 따라 적절한 시간은 달라집니다. 중요한 것은 특정 시간표를 그대로 복사하는 것이 아니라, 디스크를 많이 사용하는 작업이 동시에 시작되지 않도록 전체 일정을 한 번에 확인하는 것입니다.

Hyper Backup과 무결성 검사 사이에 간격을 뒀다

Hyper Backup은 매일 00시 30분에 실행하도록 설정했습니다.

무결성 검사는 매주 일요일 오전 5시에 실행하고, 무결성 데이터 검사 시간은 최대 30분으로 제한했습니다.

백업 직후 바로 무결성 검사를 시작하지 않고 시간 간격을 둔 이유는 두 작업이 겹칠 가능성을 줄이기 위해서입니다.

다만 백업 데이터가 많거나 네트워크 상태가 느리면 백업이 예상보다 오래 걸릴 수 있습니다. 실제 백업 종료 시간이 오전 5시에 가까워진다면 무결성 검사 시간을 더 늦게 조정해야 합니다.

예약 시간을 정할 때는 시작 시간만 확인하기보다 최근 백업 기록에서 실제 종료 시간도 함께 살펴보는 것이 좋습니다.

데이터 스크러빙의 역할과 실행 시간

데이터 스크러빙은 저장소의 RAID 정보와 데이터 일관성을 확인하고, 잠재적인 오류를 찾는 유지관리 작업입니다.

Btrfs 볼륨에서는 체크섬 정보를 이용해 데이터 오류를 탐지하고, 복구 가능한 상태라면 정상 데이터로 수정하는 데 도움을 줄 수 있습니다.

쉽게 말하면 데이터가 겉으로 정상적으로 보이더라도 저장 과정에서 발생한 잠재적인 손상이 없는지 주기적으로 확인하는 작업이라고 볼 수 있습니다.

데이터 스크러빙은 백업을 대신하지 않는다

데이터 스크러빙은 저장소 안의 오류를 확인하는 기능이지 별도의 복사본을 만드는 백업 기능이 아닙니다.

실수로 파일을 삭제했거나 랜섬웨어로 파일이 변경됐거나 NAS 자체가 손상된 경우까지 데이터 스크러빙이 해결해주는 것은 아닙니다.

따라서 다음 기능은 각각 역할이 다릅니다.

데이터 스크러빙: 저장소 내부의 일관성과 오류 확인
S.M.A.R.T. 검사: 개별 HDD의 상태 확인
Hyper Backup: 별도의 백업본 생성과 복구
스냅샷: 특정 시점의 파일 상태 보존

한 가지 기능이 정상이라고 해서 다른 데이터 보호 수단을 생략할 수 있는 것은 아닙니다.

허용 시간 안에 끝나지 않아도 이어서 진행할 수 있다

데이터 스크러빙은 HDD 용량과 사용량에 따라 오랜 시간이 걸릴 수 있습니다.

이번 설정에서는 3개월마다 실행하고, 일요일은 오전 2시부터 5시까지, 월요일부터 토요일은 오전 2시부터 8시까지 작업을 허용했습니다.

허용 시간 안에 스크러빙이 끝나지 않으면 작업이 중단되거나 대기했다가 다음 허용 시간에 이어서 진행될 수 있습니다.

따라서 짧은 시간 안에 무조건 끝내려고 다른 작업과 겹치는 긴 시간대를 지정하기보다, NAS 사용이 적은 시간에 나누어 진행하도록 구성했습니다.

S.M.A.R.T. 검사를 HDD별로 나눈 이유

S.M.A.R.T.는 HDD가 기록하는 자체 상태 정보를 확인하는 기능입니다.

DSM에서는 빠른 검사와 확장 검사를 예약할 수 있습니다.

빠른 검사와 확장 검사의 차이

빠른 S.M.A.R.T. 검사는 비교적 짧은 시간 동안 주요 상태 항목을 확인합니다. 정기적으로 HDD의 기본적인 이상 징후를 살펴볼 때 사용할 수 있습니다.

확장 S.M.A.R.T. 검사는 HDD 표면을 포함해 더 넓은 범위를 확인하므로 시간이 오래 걸리고 디스크 작업량도 커질 수 있습니다.

두 검사 모두 HDD 상태를 확인하는 데 도움이 되지만, 검사 결과가 정상이라고 해서 향후 고장이 발생하지 않는다는 의미는 아닙니다.

HDD는 검사 당시 정상이어도 갑자기 문제가 발생할 수 있으므로 S.M.A.R.T. 검사와 별개로 백업을 유지해야 합니다.

HDD 4개를 같은 시간에 검사하지 않았다

DS423+에는 HDD 4개가 설치돼 있습니다.

처음에는 4개 드라이브의 검사를 같은 날짜에 실행하도록 설정할 수도 있지만, 그렇게 하면 여러 HDD에서 동시에 검사 작업이 시작될 수 있습니다.

이번에는 빠른 검사와 확장 검사 모두 드라이브별로 날짜를 나눴습니다.

예를 들어 첫 번째 HDD 검사가 끝난 뒤 며칠 후 두 번째 HDD를 검사하는 방식으로 구성했습니다. 검사 작업을 분산하면 특정 시간에 여러 디스크가 동시에 바빠지는 상황을 줄이는 데 도움이 될 수 있습니다.

Antivirus Essential 검사 시간과 범위를 조정했다

Antivirus Essential은 매주 일요일 오전 6시에 실행하도록 설정했습니다.

검사 전에 바이러스 정의를 먼저 업데이트하도록 설정하고, 스마트 스캔과 감염 파일 격리 기능도 사용했습니다.

일반 문서가 저장된 폴더를 중심으로 검사했다

백신 검사 대상은 가족 문서와 일반 파일이 저장된 공유 폴더를 중심으로 구성했습니다.

반면 WordPress, MariaDB, Bitcoin Core, Fulcrum처럼 서비스가 실행 중인 데이터 경로는 일반 문서 폴더와 같은 방식으로 검사하지 않았습니다.

데이터베이스나 컨테이너가 사용 중인 파일을 백신이 오탐으로 판단해 격리하면 서비스가 멈추거나 데이터에 문제가 생길 수 있기 때문입니다.

그렇다고 Docker나 데이터베이스 경로를 모든 환경에서 반드시 제외해야 한다는 뜻은 아닙니다.

검사 대상과 제외 대상은 다음 조건을 함께 고려해 결정해야 합니다.

외부에서 파일이 유입되는 경로
사용자가 직접 열고 편집하는 문서 폴더
서비스가 실시간으로 사용하는 데이터
별도 백업 여부
해당 서비스의 보안 정책
오탐 발생 시 서비스에 미치는 영향

백신 검사를 무조건 넓게 설정하는 것보다, 각 공유 폴더의 역할을 확인하고 검사 범위를 정하는 것이 중요합니다.

Synology Photos와 파일 색인은 불필요하게 다시 실행하지 않았다

Synology Photos에서 사진 누락이나 검색 오류가 발생하면 전체 재색인을 고려할 수 있습니다.

하지만 전체 재색인은 많은 사진과 동영상을 다시 분석하면서 CPU와 HDD 사용량을 크게 높일 수 있습니다.

현재 Synology Photos에서는 사진이 정상적으로 표시되고 있었기 때문에 전체 재색인을 실행하지 않았습니다.

성능 문제를 점검한다는 이유로 정상적으로 작동하는 색인을 다시 만드는 것은 오히려 새로운 백그라운드 작업을 추가할 수 있습니다.

사진 누락, 썸네일 오류, 검색 결과 이상과 같은 문제가 없다면 전체 재색인은 필요한 경우에만 실행하는 편이 좋다고 생각합니다.

Universal Search와 저장소 분석기는 성능 향상 기능이 아니다

Universal Search는 NAS에 저장된 파일 내용을 검색하거나 색인을 만드는 기능입니다.

저장소 분석기는 저장 공간 사용 현황과 파일 분포를 분석하는 기능입니다.

두 기능 모두 필요한 사용자에게는 유용하지만, 설치한다고 해서 WordPress나 HDD의 기본 성능이 빨라지는 기능은 아닙니다.

저는 Universal Search를 사용하지 않아 설치하지 않았고, 저장소 분석기도 이번 성능 점검 목적과 맞지 않아 설치하지 않았습니다.

기능이 많을수록 무조건 NAS가 좋아지는 것은 아닙니다. 사용하지 않는 색인이나 분석 기능은 추가적인 디스크 접근을 만들 수 있으므로 실제 필요 여부를 먼저 확인하는 것이 좋습니다.

HDD 쓰기 캐시 상태를 DSM과 SSH에서 확인했다

DSM 저장소 관리자에서는 HDD 쓰기 캐시와 관련된 설정을 확인할 수 있습니다.

쓰기 캐시는 HDD로 전달된 데이터를 바로 디스크 표면에 기록하기 전에 드라이브 내부의 임시 메모리에 잠시 보관하는 기능입니다.

작은 쓰기 작업을 효율적으로 처리하는 데 도움이 될 수 있지만, HDD 쓰기 캐시와 SSD 캐시는 서로 다른 기능입니다.

HDD 쓰기 캐시: 각 HDD 내부의 임시 캐시를 이용
SSD 캐시: 별도의 SSD를 이용해 자주 접근하는 데이터를 캐싱

DSM 화면에서 쓰기 캐시가 활성화된 것으로 표시되더라도 실제 드라이브 상태를 한 번 더 확인하기 위해 SSH 명령도 사용했습니다.

확인에 사용한 명령어는 다음과 같습니다.

for d in /dev/sata1 /dev/sata2 /dev/sata3 /dev/sata4; do
  echo "=== $d ==="
  /bin/smartctl -g wcache "$d"
done

이 명령은 /dev/sata1부터 /dev/sata4까지 각 HDD의 쓰기 캐시 상태를 차례로 표시합니다.

네 드라이브 모두 다음과 같이 활성화된 상태로 확인됐습니다.

Writeback Cache is: Enabled

실제 명령 결과를 블로그나 커뮤니티에 공개할 때는 디스크 모델과 캐시 상태 외에 계정명, 내부 경로, 네트워크 정보 같은 민감한 내용이 포함되지 않았는지 확인하는 것이 좋습니다.

쓰기 캐시가 지연을 직접 해결했다고 볼 수는 없다

HDD 쓰기 캐시가 활성화돼 있으면 작은 쓰기 작업을 처리하는 데 도움이 될 수 있습니다.

하지만 이번에 발생한 WordPress 관리자 화면 지연을 쓰기 캐시 하나만으로 설명하기는 어렵습니다.

쓰기 캐시는 이미 활성화된 상태였고, 이번 점검에서는 설정을 새로 켜기보다 실제 상태를 확인하는 데 의미가 있었습니다.

따라서 쓰기 캐시를 활성화하면 WordPress 관리자 화면이 반드시 빨라진다고 해석해서는 안 됩니다.

UPS가 없는 상태에서 기존 설정을 유지했다

쓰기 캐시에 아직 남아 있는 데이터가 HDD에 완전히 기록되기 전에 전원이 차단되면 일부 데이터가 손실될 가능성이 있습니다.

UPS는 정전이 발생했을 때 NAS가 안전하게 종료될 시간을 확보해주는 장치입니다. 쓰기 캐시뿐 아니라 파일 시스템과 데이터베이스, 실행 중인 컨테이너가 비정상적으로 종료되는 위험을 줄이는 데도 도움이 될 수 있습니다.

현재 제 환경에서는 UPS를 사용하지 않고 있습니다.

다만 쓰기 캐시 설정을 임의로 변경하지 않고 기존 활성화 상태를 유지했습니다. 이것은 UPS가 없어도 쓰기 캐시 사용이 항상 안전하다는 권장 설정이 아니라, 이번 점검 당시 실제 운영 상태를 기록한 것입니다.

중요한 데이터를 운영하는 환경이라면 쓰기 캐시 설정만 따로 보기보다 UPS와 백업, 안전 종료 방식을 함께 검토하는 편이 좋습니다.

SSD를 구매하기 전에 캐시 어드바이저 분석을 시작했다

DS423+에는 NVMe SSD를 장착해 SSD 캐시를 구성할 수 있습니다.

WordPress와 MariaDB를 운영하고 있기 때문에 SSD 캐시를 설치하면 지연이 줄어들지 궁금했습니다. 하지만 실제 접근 패턴을 확인하지 않은 상태에서 먼저 SSD를 구매하지는 않았습니다.

DSM의 SSD 캐시 어드바이저를 이용하면 현재 볼륨의 접근 패턴을 분석해 예상 캐시 크기를 확인할 수 있습니다.

실행 경로는 다음과 같습니다.

저장소 관리자 → 저장소 → SSD 캐시 어드바이저

DSM 버전이나 화면 구성에 따라 메뉴 이름과 위치는 조금 달라질 수 있습니다.

SSD가 없어도 분석을 시작할 수 있다

SSD 캐시 어드바이저는 NVMe SSD를 아직 설치하지 않은 상태에서도 분석을 시작할 수 있습니다.

분석을 시작한 뒤에는 최소 약 7일 정도 데이터를 수집하고, 사용 패턴이 다양하다면 최대 약 30일까지 살펴볼 수 있습니다.

분석 기간에는 특정 작업만 일부러 반복하기보다 평소처럼 NAS를 사용하는 것이 중요합니다.

제 환경에서는 다음 작업을 평소와 비슷하게 유지할 예정입니다.

WordPress 관리자 화면 사용
글 작성과 수정
MariaDB 읽기·쓰기
Bitcoin Core와 Fulcrum 운영
Synology Photos 이용
Synology Drive 동기화
Hyper Backup 실행
정기 유지관리 작업

그래야 일시적인 테스트가 아니라 실제 운영 환경에 가까운 접근 패턴이 분석 결과에 반영될 수 있습니다.

분석 초기 예상 캐시 크기가 0바이트로 표시됐다

분석을 시작한 직후 SSD 캐시 어드바이저에는 예상 캐시 크기가 0바이트로 표시됐습니다.

처음에는 캐시가 전혀 필요 없다는 결과처럼 보일 수 있지만, 분석을 시작한 직후에는 접근 데이터가 충분히 쌓이지 않은 상태일 수 있습니다.

따라서 초기 화면만 보고 결론을 내리지 않고 분석 기간이 지난 뒤 다시 확인할 예정입니다.

SSD 캐시가 항상 큰 효과를 내는 것은 아니다

SSD 캐시는 자주 반복해서 읽는 데이터가 많을 때 효과를 볼 가능성이 있습니다.

반대로 대용량 파일을 순차적으로 읽고 쓰는 작업이나 한 번만 접근하는 데이터가 대부분이라면 기대한 만큼 체감되지 않을 수도 있습니다.

WordPress와 MariaDB처럼 작은 파일과 데이터베이스 접근이 많은 서비스는 SSD 캐시의 후보가 될 수 있지만, 실제 효과는 메모리 용량, 데이터베이스 설정, 캐시 플러그인, HDD 상태, 동시 작업량에 따라서도 달라질 수 있습니다.

Bitcoin Core와 Fulcrum 데이터 역시 접근 패턴과 구성에 따라 결과가 달라질 수 있으므로 SSD 캐시에 반드시 적합하다고 단정하기 어렵습니다.

SSD 캐시와 SSD 볼륨도 목적이 다릅니다.

SSD 캐시는 기존 HDD 볼륨의 일부 접근을 빠르게 보조하는 방식이고, 별도 SSD 볼륨은 특정 서비스나 데이터를 SSD에 직접 저장하는 방식입니다.

어떤 구성이 적합한지는 캐시 어드바이저 결과와 실제 서비스 특성을 함께 보고 판단해야 합니다.

설정 변경 후 지연은 현재 거의 나타나지 않고 있다

내장 HDD 절전 모드를 해제하고 백업과 각종 유지관리 일정을 분리한 뒤, WordPress 관리자 화면에서 기존처럼 약 5~9초씩 기다리는 현상은 현재 거의 나타나지 않고 있습니다.

메뉴와 글 목록도 대부분 바로 열리고 있습니다.

다만 여러 설정을 함께 변경했기 때문에 다음 중 특정 항목 하나가 해결 원인이라고 단정할 수는 없습니다.

내장 HDD 절전 해제
Hyper Backup과 무결성 검사 시간 분리
데이터 스크러빙 일정 조정
HDD별 S.M.A.R.T. 검사 날짜 분리
백신 검사 시간과 범위 조정
불필요한 전체 재색인 미실행
여러 백그라운드 디스크 작업의 집중 완화

사용하면서 느낀 바로는 HDD 절전 해제와 백그라운드 디스크 작업 분산이 첫 접근 지연 감소에 영향을 줬을 가능성이 커 보입니다.

하지만 지연이 다시 발생할 수도 있고, SSD 캐시 어드바이저 분석도 아직 진행 중입니다. 앞으로 일정 기간 더 사용하면서 WordPress 관리자 화면과 NAS 전체의 디스크 반응을 확인할 필요가 있습니다.

Synology NAS 디스크 지연 점검 순서

이번에 진행한 점검을 순서대로 정리하면 다음과 같습니다.

HDD 최대 절전 상태 확인
백업과 유지관리 작업 시간 분리
HDD별 S.M.A.R.T. 검사 예약
불필요한 전체 색인과 검사 최소화
HDD 쓰기 캐시의 실제 상태 확인
SSD 캐시 어드바이저로 평소 사용 패턴 분석

가끔 발생하는 지연을 줄이기 위해 곧바로 SSD를 구매하거나 유지관리 기능을 중지하기보다, 현재 NAS에서 어떤 작업이 언제 실행되고 있는지 먼저 확인하는 것이 좋습니다.

백업, 데이터 스크러빙, S.M.A.R.T. 검사, 백신 검사는 NAS와 데이터를 보호하기 위해 필요한 기능입니다. 이번 점검에서도 이 기능들을 제거하지 않고 실행 시간을 분산하는 방향으로 정리했습니다.

또한 HDD 절전 모드 해제가 모든 NAS에 적합한 것은 아닙니다.

파일 저장용으로만 사용하거나 하루 중 대부분 접근하지 않는 NAS라면 절전 기능을 유지하는 편이 전력 소비와 소음 면에서 더 적합할 수 있습니다.

반대로 WordPress, 데이터베이스, Docker, 사진 관리와 같은 상시 서비스를 함께 운영한다면 절전 효과보다 반복되는 첫 접근 지연을 더 크게 느낄 수도 있습니다.

제 환경에서는 설정을 조정한 뒤 간헐적인 지연이 현재 거의 나타나지 않고 있습니다. 다음 단계는 SSD 캐시 어드바이저 분석 결과를 충분히 모은 뒤, DS423+에 NVMe SSD 캐시가 실제로 필요한지 판단하는 것입니다.

분석 결과가 충분히 쌓이면 SSD 캐시 권장 용량과 실제 접근 패턴, SSD 캐시와 별도 SSD 볼륨의 차이를 후속 글에서 정리해보겠습니다.

후속 글 예정: Synology SSD 캐시 어드바이저 분석 결과｜DS423+에 NVMe 캐시가 필요할까?

Synology DS423+ NAS 간헐적 디스크 지연 줄이기: HDD 절전부터 SSD 캐시 어드바이저까지