시놀로지 NAS 워드프레스와 Docker 서비스 자원 충돌, 갑자기 느려질 때 확인할 순서
시놀로지 NAS에서 워드프레스와 Docker 서비스를 함께 운영하다 보면 사이트가 갑자기 느려지거나 관리자 페이지가 늦게 열리는 경우가 있습니다.
워드프레스 설정이나 플러그인을 변경하지 않았는데도 속도가 떨어지면 워드프레스 자체의 문제라고 판단하기 어렵습니다.
같은 NAS에서 실행되는 Docker 컨테이너가 CPU와 메모리를 많이 사용하거나 대량의 디스크 읽기·쓰기를 발생시키면 Web Station, PHP와 MariaDB도 영향을 받을 수 있기 때문입니다.
특히 미디어 서버, 다운로드 프로그램, 검색 색인, 이미지 처리, AI 서비스, 데이터베이스와 자동 백업 컨테이너는 특정 작업이 시작될 때 NAS 자원을 집중적으로 사용할 수 있습니다.
이 문제를 해결하려면 컨테이너를 전부 삭제하거나 NAS를 재부팅하기보다 CPU·메모리·디스크·네트워크·포트 중 어느 자원에서 충돌이 발생했는지 먼저 구분해야 합니다.
Docker의 격리는 자원까지 자동으로 분리하지 않는다
Docker 컨테이너는 애플리케이션의 파일과 실행 환경을 분리해 관리할 수 있게 해줍니다.
그러나 컨테이너가 별도의 물리적 CPU, 메모리와 디스크를 갖는 것은 아닙니다. 같은 NAS에서 실행되는 모든 컨테이너와 DSM 패키지는 실제 하드웨어 자원을 공유합니다.
기본적으로 별도의 제한을 설정하지 않은 컨테이너는 호스트에서 사용할 수 있는 CPU와 메모리를 상당 부분 사용할 수 있습니다.
NAS에서 함께 자원을 사용하는 대표적인 서비스는 다음과 같습니다.
- Web Station
- PHP
- MariaDB
- Container Manager
- 워드프레스 컨테이너
- Docker용 MariaDB 컨테이너
- Synology Drive
- Hyper Backup
- Snapshot Replication
- 미디어 색인
- 파일 공유 서비스
- 백신 및 보안 검사
- 다운로드 서비스
컨테이너는 서로 분리되어 보여도 CPU, 메모리, 저장장치와 네트워크는 같은 NAS의 것을 사용합니다.
자원 충돌과 포트 충돌은 다른 문제다
Docker 서비스 충돌은 크게 두 종류로 구분할 수 있습니다.
자원 충돌
한 서비스가 CPU, 메모리, 디스크 또는 네트워크를 과도하게 사용해 다른 서비스의 응답이 느려지는 현상입니다.
대표적인 증상은 다음과 같습니다.
- 워드프레스 페이지가 늦게 열림
- DSM 전체가 느려짐
- 파일 전송 속도가 떨어짐
- 관리자 페이지 저장이 오래 걸림
- MariaDB 응답이 느려짐
- 간헐적으로 502·504 오류가 발생함
- 컨테이너가 강제로 종료되거나 재시작됨
포트 충돌
두 서비스가 동일한 NAS 포트를 사용하려고 할 때 발생합니다.
대표적인 증상은 다음과 같습니다.
- 컨테이너가 시작되지 않음
- 포트가 이미 사용 중이라는 오류가 표시됨
- 예상과 다른 서비스가 열림
- 리버스 프록시 대상에 접속되지 않음
- 502 Bad Gateway가 발생함
사이트가 느린 현상은 자원 충돌에 가깝고, 컨테이너가 실행되지 않거나 접속 주소가 다른 서비스로 연결된다면 포트 문제를 먼저 확인해야 합니다.
먼저 증상과 발생 시점을 구분한다
Docker 자원 충돌은 항상 발생하는 것이 아니라 특정 작업 시간에만 나타날 수 있습니다.
| 발생 상황 | 우선 확인할 원인 |
|---|---|
| 특정 컨테이너 실행 후 느려짐 | 해당 컨테이너의 CPU·메모리 |
| 매일 같은 시간에 느려짐 | 예약 백업, 검사, 다운로드 |
| 대용량 파일 작업 중 느려짐 | 디스크 I/O와 네트워크 |
| 방문자가 늘면 느려짐 | PHP·DB·컨테이너 자원 경쟁 |
| DSM까지 함께 느려짐 | NAS 전체 자원 부족 |
| 워드프레스만 느려짐 | PHP·DB·Docker 내부 연결 |
| 컨테이너가 반복 재시작됨 | 메모리 부족, 앱 오류, 상태 확인 실패 |
| 502·504 오류가 나타남 | 백엔드 지연, 포트, 프록시 |
| 재부팅하면 잠시 정상 | 메모리·스왑·로그·반복 작업 |
| 컨테이너 시작 직후 접속 불가 | 포트 충돌 또는 초기화 작업 |
문제가 발생한 시간과 Container Manager에서 실행된 작업을 함께 비교해야 합니다.
1단계: NAS 전체가 느린지 워드프레스만 느린지 확인한다
가장 먼저 문제 범위를 나눕니다.
다음 항목을 같은 시간에 확인합니다.
- 워드프레스 방문자 페이지
- 워드프레스 관리자 페이지
- DSM 화면
- File Station
- NAS 파일 복사 속도
- 다른 Docker 서비스
- 같은 NAS의 다른 웹사이트
NAS 전체가 함께 느린 경우
CPU, 메모리, 디스크 또는 네트워크 자원 부족을 먼저 의심합니다.
워드프레스만 느린 경우
워드프레스 컨테이너, PHP, MariaDB, 리버스 프록시와 컨테이너 네트워크를 확인합니다.
특정 Docker 서비스만 느린 경우
해당 컨테이너의 내부 오류, 저장장치 연결, 볼륨 권한과 데이터베이스 상태를 확인합니다.
문제 범위를 구분하지 않고 워드프레스 플러그인부터 삭제하면 실제 원인을 찾지 못할 수 있습니다.
2단계: DSM 리소스 모니터에서 병목을 찾는다
DSM 리소스 모니터에서는 CPU, 메모리, 디스크, 볼륨과 네트워크 사용 상태를 확인할 수 있습니다.
사이트가 느려지는 순간에 어떤 그래프가 올라가는지 살펴봅니다.
CPU 사용률이 높을 때
다음 작업을 의심할 수 있습니다.
- 동영상 변환
- 사진 및 미디어 색인
- 이미지 압축
- AI 추론
- 파일 압축
- 보안 검사
- 데이터베이스 처리
- 대량 백업
- 검색 색인 생성
CPU 사용률이 높을 때는 작업 관리자에서 어떤 서비스와 프로세스가 CPU를 사용하는지 확인합니다.
Container Manager 화면에서도 실행 중인 프로젝트와 컨테이너의 자원 사용량을 비교합니다.
메모리와 스왑이 증가할 때
메모리가 부족하면 NAS는 저장장치의 스왑 공간을 사용하게 됩니다. 스왑은 실제 메모리보다 느리기 때문에 CPU 사용률이 높지 않아도 NAS 반응이 크게 느려질 수 있습니다.
다음 항목을 확인합니다.
- 전체 메모리 사용량
- 스왑 사용량
- 컨테이너별 메모리 사용량
- MariaDB 메모리
- PHP 프로세스 수
- 컨테이너 재시작 기록
메모리 사용률이 높다는 사실만으로 바로 부족하다고 판단하지 않습니다. 시스템 캐시도 사용 메모리로 표시될 수 있기 때문입니다.
스왑 사용이 지속적으로 증가하고 디스크 작업까지 많아진다면 실제 메모리 압박일 가능성이 높습니다.
디스크 사용률이 높을 때
CPU와 메모리가 정상인데 사이트가 느리다면 디스크 I/O를 확인합니다.
다음 작업은 HDD 읽기·쓰기를 크게 증가시킬 수 있습니다.
- 토렌트 다운로드와 파일 검사
- 미디어 라이브러리 색인
- 대용량 파일 압축 해제
- Docker 데이터베이스 처리
- 워드프레스 백업
- Hyper Backup
- 보안 검사
- 썸네일 생성
- 컨테이너 로그 기록
워드프레스는 페이지를 생성하면서 PHP 파일과 DB 데이터를 읽습니다. 다른 컨테이너가 저장장치를 계속 점유하면 워드프레스 요청이 디스크 응답을 기다릴 수 있습니다.
3단계: Container Manager에서 컨테이너별 사용량을 확인한다
Container Manager에서 실행 중인 컨테이너의 CPU, 메모리와 네트워크 사용 상태를 확인합니다.
문제가 발생하는 순간 사용량이 크게 증가하는 컨테이너를 찾습니다.
다음 내용을 기록하면 원인 비교에 도움이 됩니다.
- 컨테이너 이름
- CPU 사용량
- 메모리 사용량
- 네트워크 송수신
- 시작 시간
- 재시작 횟수
- 상태
- 연결된 볼륨
- 최근 로그
- 실행 중인 내부 작업
순간 사용량만 보면 안 되는 이유
일부 컨테이너는 평소에는 거의 자원을 사용하지 않다가 예약 작업이 시작되면 짧은 시간 동안 CPU와 디스크를 집중적으로 사용합니다.
실시간 화면에서 정상으로 보이더라도 문제가 발생하는 시간대의 기록을 비교해야 합니다.
가능하다면 DSM 리소스 사용 기록을 활성화하고 사이트가 느려진 시간과 컨테이너 작업 시간을 맞춰봅니다.
4단계: 의심되는 컨테이너를 한 개씩 중지해 비교한다
자원 충돌을 확인하는 가장 직접적인 방법은 의심되는 컨테이너를 잠시 중지한 뒤 워드프레스 속도를 비교하는 것입니다.
테스트 순서
- 워드프레스 페이지와 관리자 화면의 반응 시간을 확인합니다.
- DSM의 CPU·메모리·디스크 상태를 기록합니다.
- 의심되는 컨테이너 하나를 중지합니다.
- 같은 워드프레스 페이지를 다시 엽니다.
- 관리자 글 목록과 글 저장 속도를 비교합니다.
- DSM 자원 사용량이 내려갔는지 확인합니다.
- 컨테이너를 다시 실행해 같은 증상이 재현되는지 봅니다.
컨테이너 중지 후 사이트가 빨라졌다고 해서 바로 삭제할 필요는 없습니다.
해당 컨테이너의 어떤 작업이 자원을 사용하는지와 실행 주기를 먼저 확인해야 합니다.
중지하면 안 되는 컨테이너
다음 컨테이너는 역할을 확인하지 않고 중지하면 워드프레스 자체가 작동하지 않을 수 있습니다.
- 워드프레스 컨테이너
- 워드프레스가 사용하는 MariaDB
- 리버스 프록시
- Redis 또는 객체 캐시
- 필수 네트워크 서비스
- 인증 서비스
컨테이너 이름만 보고 판단하지 말고 프로젝트 구성과 연결 관계를 먼저 확인합니다.
5단계: CPU 충돌인지 확인한다
컨테이너에 CPU 제한을 설정하지 않으면 무거운 작업이 실행되는 동안 사용 가능한 CPU 자원을 크게 점유할 수 있습니다.
CPU 충돌은 다음과 같은 형태로 나타납니다.
- 워드프레스 첫 화면 생성이 느림
- 관리자 화면이 늦게 열림
- PHP 처리 시간이 길어짐
- MariaDB 쿼리 응답이 늦어짐
- DSM 화면 전환이 느림
- 504 Gateway Timeout 발생
- 컨테이너 상태 확인이 지연됨
CPU를 많이 사용할 수 있는 서비스
- 동영상 트랜스코딩
- 사진 얼굴 및 사물 인식
- AI 서비스
- 검색 엔진
- 대용량 압축
- 파일 무결성 검사
- 악성코드 검사
- 이미지 일괄 변환
- 소스 빌드
- 데이터베이스 색인 생성
CPU 사용률을 해석할 때 주의할 점
컨테이너별 CPU 사용률은 코어 수와 표시 방식에 따라 100%를 넘게 보일 수 있습니다.
따라서 숫자 하나만 보지 말고 다음 항목을 함께 확인합니다.
- 전체 NAS CPU 사용률
- 부하 평균
- 사용률이 지속되는 시간
- 워드프레스 지연 시간
- 해당 컨테이너 중지 전후 차이
짧은 순간의 CPU 상승은 정상적인 초기화 작업일 수 있습니다. 높은 사용률이 지속되고 워드프레스 속도 저하와 시간이 일치하는지를 봐야 합니다.
6단계: 메모리 충돌과 OOM을 확인한다
Docker 컨테이너가 사용할 수 있는 메모리를 제한하지 않으면 애플리케이션이 NAS의 메모리를 많이 사용할 수 있습니다.
메모리가 부족해지면 시스템은 스왑을 사용하거나 프로세스를 강제로 종료할 수 있습니다.
메모리 충돌의 대표적인 증상
- NAS가 시간이 지날수록 느려짐
- 컨테이너가 갑자기 종료됨
- 컨테이너가 반복적으로 재시작됨
- MariaDB가 중지됨
- 워드프레스에서 DB 연결 오류 발생
- DSM 로그인과 파일 서비스까지 느려짐
- 스왑 사용량이 계속 증가함
- 재부팅 후 잠시 정상화됨
컨테이너가 반복 재시작될 때
재시작 정책이 설정된 컨테이너는 메모리 부족이나 애플리케이션 오류로 종료된 뒤 자동으로 다시 시작될 수 있습니다.
사용자는 서비스가 계속 실행 중인 것처럼 느낄 수 있지만 내부에서는 다음 과정이 반복됩니다.
실행 → 메모리 부족 → 강제 종료 → 자동 재시작Container Manager의 상태와 로그에서 종료 원인과 재시작 횟수를 확인해야 합니다.
7단계: 메모리 제한을 너무 낮게 설정해도 문제가 된다
자원 충돌을 막기 위해 컨테이너 메모리를 지나치게 낮게 제한하면 서비스 자체가 정상적으로 작동하지 않을 수 있습니다.
예를 들어 MariaDB 컨테이너의 메모리를 실제 필요량보다 낮게 제한하면 쿼리가 느려지거나 컨테이너가 종료될 수 있습니다.
워드프레스 컨테이너도 PHP 처리에 필요한 메모리를 확보하지 못하면 다음 오류가 나타날 수 있습니다.
Allowed memory size exhausted컨테이너 메모리 제한과 PHP의 memory_limit은 서로 다른 설정입니다.
PHP가 512MB를 사용할 수 있도록 설정되어 있어도 컨테이너 전체 메모리 제한이 그보다 낮으면 실제로는 필요한 메모리를 확보하지 못할 수 있습니다.
메모리 제한 전 확인할 항목
- 평상시 메모리 사용량
- 최대 부하 시 사용량
- 초기화나 업데이트 시 필요한 메모리
- 컨테이너 안에서 실행되는 프로세스 수
- NAS 전체 메모리
- 다른 필수 서비스가 사용할 여유 메모리
- 스왑 사용 여부
현재 사용량을 측정하지 않고 임의의 낮은 값을 적용하면 서비스 장애가 발생할 수 있습니다.
8단계: 디스크 I/O 충돌을 확인한다
시놀로지 NAS는 CPU 사용률보다 디스크 작업 때문에 느려지는 경우가 많습니다.
특히 HDD로 구성된 NAS에서는 여러 컨테이너가 작은 파일을 반복해서 읽고 쓰면 대용량 파일 한 개를 복사할 때보다 응답이 느려질 수 있습니다.
워드프레스가 사용하는 디스크 작업
- PHP 파일 읽기
- 업로드 이미지 읽기
- 캐시 파일 생성
- 로그 기록
- MariaDB 데이터 읽기·쓰기
- 플러그인과 테마 업데이트
- 이미지 썸네일 생성
- 백업 압축
다른 컨테이너의 영향을 받을 수 있는 작업
- 다운로드 후 파일 검사
- 미디어 라이브러리 스캔
- 썸네일 생성
- 검색 색인
- 데이터베이스 백업
- 로그 대량 기록
- 파일 동기화
- 영상 변환
- 압축 해제
CPU 사용률이 낮은데 볼륨 사용률과 I/O 대기가 높다면 CPU나 메모리를 늘리는 것보다 디스크 작업 시간을 분리하는 것이 효과적일 수 있습니다.
9단계: Docker 볼륨 위치를 확인한다
각 컨테이너가 어떤 NAS 공유 폴더나 Docker 볼륨을 사용하는지 확인합니다.
워드프레스 파일과 MariaDB 데이터가 다른 컨테이너의 작업 폴더와 같은 볼륨에 있으면 디스크 작업이 집중될 수 있습니다.
확인할 항목
- 워드프레스 파일 볼륨
- MariaDB 데이터 볼륨
- 업로드 이미지 폴더
- 컨테이너 로그 위치
- 다운로드 폴더
- 미디어 색인 대상
- 백업 대상 폴더
- Synology Drive 팀 폴더 여부
- Snapshot Replication 대상 여부
워드프레스의 MariaDB 데이터 폴더가 다운로드나 미디어 변환 작업과 같은 디스크에 있다는 이유만으로 바로 이동할 필요는 없습니다.
먼저 문제가 발생하는 시간과 디스크 사용량을 확인해 실제 충돌 여부를 판단해야 합니다.
10단계: 컨테이너 로그가 디스크를 점유하는지 확인한다
애플리케이션 오류가 반복되면 컨테이너 로그가 빠르게 증가할 수 있습니다.
로그 파일이 커지는 것뿐 아니라 짧은 시간에 로그를 계속 기록하는 작업 자체가 디스크 I/O를 발생시킵니다.
로그 폭증을 의심할 수 있는 상황
- 컨테이너가 반복 재시작됨
- 같은 오류가 계속 표시됨
- 외부 서버 연결이 반복 실패함
- DB 연결 오류가 반복됨
- 권한 오류가 반복됨
- 상태 확인 요청이 계속 실패함
- 컨테이너 실행 직후 로그가 빠르게 증가함
로그를 삭제하는 것만으로는 근본적인 해결이 되지 않습니다.
로그에 반복되는 첫 번째 오류를 찾아 네트워크, 권한, DB 연결 또는 환경변수 문제를 해결해야 합니다.
Compose 환경이라면 로그 크기와 보관 파일 수를 제한하는 설정도 검토할 수 있습니다.
예시는 다음과 같습니다.
services:
app:
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"실제 지원 여부와 현재 사용 중인 로깅 드라이버를 확인한 뒤 적용해야 합니다.
11단계: 네트워크 대역폭 충돌을 확인한다
Docker 서비스가 대용량 데이터를 외부로 전송하거나 내려받으면 워드프레스 접속 속도도 영향을 받을 수 있습니다.
다음 서비스가 네트워크를 많이 사용할 수 있습니다.
- 다운로드 컨테이너
- 클라우드 동기화
- 외부 백업
- 미디어 스트리밍
- 원격 파일 전송
- 영상 서버
- 사이트 크롤링
- 외부 DB 동기화
네트워크 충돌의 증상
- 내부 접속은 빠르지만 외부 접속이 느림
- 이미지 로딩이 오래 걸림
- 파일 업로드가 실패함
- 백업 시간에만 사이트가 느림
- NAS의 송수신량이 계속 높음
- 리버스 프록시에서 시간 초과가 발생함
내부 네트워크에서도 느리다면 CPU나 디스크 문제일 가능성이 높고, 외부 접속만 느리다면 인터넷 회선의 업로드 대역폭도 확인해야 합니다.
가정용 인터넷은 다운로드 속도보다 업로드 속도가 낮을 수 있습니다. NAS에서 대용량 외부 백업을 실행하면 워드프레스 방문자에게 보낼 데이터도 영향을 받을 수 있습니다.
12단계: 포트 충돌을 확인한다
두 컨테이너가 같은 호스트 포트를 사용할 수는 없습니다.
워드프레스 또는 프록시가 이미 사용 중인 포트를 새로운 컨테이너에 할당하면 컨테이너가 실행되지 않거나 접속 경로가 꼬일 수 있습니다.
예를 들어 다음 서비스가 동일한 호스트 포트를 요구할 수 있습니다.
- 워드프레스
- 웹 관리 화면
- 리버스 프록시
- 다른 웹 애플리케이션
- 데이터베이스 관리 도구
컨테이너 포트와 호스트 포트 구분
컨테이너 내부에서는 여러 서비스가 같은 포트를 사용할 수 있습니다.
하지만 NAS에서 외부에 공개하는 호스트 포트는 서로 달라야 합니다.
예를 들면 다음과 같이 구성할 수 있습니다.
워드프레스 A: NAS 8080 → 컨테이너 80
워드프레스 B: NAS 8081 → 컨테이너 80두 컨테이너 모두 내부에서는 80번을 사용하지만 NAS의 호스트 포트는 8080과 8081로 구분됩니다.
포트 충돌의 판단 기준
- 컨테이너가 시작되지 않음
- 포트가 이미 할당됐다는 메시지
- 예상과 다른 서비스가 열림
- 리버스 프록시 대상 포트가 잘못됨
- Container Manager의 포트 설정과 프록시가 일치하지 않음
13단계: 리버스 프록시와 컨테이너 연결을 확인한다
도메인으로 Docker 워드프레스에 접속한다면 리버스 프록시가 NAS의 특정 포트로 요청을 전달할 수 있습니다.
컨테이너를 다시 만들면서 호스트 포트가 바뀌었는데 리버스 프록시의 목적지 포트를 수정하지 않으면 접속 오류가 발생합니다.
확인할 항목
- 소스 도메인
- 소스 프로토콜
- 외부 HTTPS 포트
- 목적지 호스트
- 목적지 포트
- 컨테이너 호스트 포트
- Web Station 포털과의 중복
- HTTPS 전달 방식
오류별 판단
| 증상 | 가능성이 높은 원인 |
|---|---|
| 502 오류 | 프록시가 컨테이너에 연결하지 못함 |
| 504 오류 | 컨테이너 응답이 지나치게 늦음 |
| 다른 서비스 표시 | 대상 포트 또는 포털 중복 |
| HTTP는 되고 HTTPS는 안 됨 | 인증서와 프록시 프로토콜 |
| 컨테이너 직접 접속은 정상 | 리버스 프록시 설정 |
컨테이너의 내부 접속이 정상인데 도메인에서만 오류가 발생한다면 워드프레스 파일보다 리버스 프록시를 먼저 확인합니다.
14단계: 워드프레스와 MariaDB 컨테이너 관계를 확인한다
워드프레스를 Docker로 운영한다면 워드프레스와 MariaDB가 별도 컨테이너로 구성되는 경우가 많습니다.
워드프레스 화면이 느리다고 워드프레스 컨테이너만 확인하면 실제 DB 병목을 놓칠 수 있습니다.
MariaDB 컨테이너가 원인일 수 있는 증상
- 첫 화면 생성이 오래 걸림
- 관리자 글 목록이 늦게 표시됨
- 글 저장이 오래 걸림
- DB 연결 오류가 간헐적으로 발생함
- MariaDB 컨테이너가 재시작됨
- 디스크 사용률이 계속 높음
- 워드프레스 컨테이너 CPU는 낮음
확인할 항목
- MariaDB 컨테이너 상태
- 메모리 사용량
- 재시작 횟수
- DB 볼륨 위치
- 저장공간 여유
- 오류 로그
- 워드프레스와 연결된 컨테이너 네트워크
- 환경변수의 DB 호스트 이름
MariaDB를 중지하면 워드프레스 자체가 작동하지 않으므로 일반 컨테이너처럼 중지 전후 속도를 비교해서는 안 됩니다.
DB 컨테이너은 상태, 자원 사용량과 로그를 중심으로 확인합니다.
15단계: 예약 작업이 겹치는지 확인한다
컨테이너 자체는 평소에 가벼워도 예약 작업이 같은 시간에 몰리면 자원 충돌이 발생할 수 있습니다.
예를 들어 새벽 2시에 다음 작업이 동시에 실행될 수 있습니다.
- 워드프레스 자동 백업
- MariaDB 덤프
- Hyper Backup
- Docker 데이터 백업
- 미디어 라이브러리 검사
- 보안 검사
- Synology Drive 동기화
- 스냅샷 생성
각 작업은 정상이어도 동시에 실행되면 CPU, 디스크와 네트워크가 부족해질 수 있습니다.
판단 방법
- 사이트가 느려지는 시간을 기록합니다.
- DSM 작업 스케줄러를 확인합니다.
- 워드프레스 WP-Cron 작업을 확인합니다.
- 컨테이너 내부 예약 작업을 확인합니다.
- Hyper Backup과 스냅샷 시간을 확인합니다.
- 실행 시간을 서로 다르게 조정합니다.
- 같은 문제가 재현되는지 확인합니다.
자원 제한을 적용하기 전에 예약 작업 시간을 분리하는 것만으로 문제가 해결될 수 있습니다.
16단계: CPU와 메모리 제한을 검토한다
Docker에서는 컨테이너가 사용할 수 있는 CPU와 메모리 범위를 제한할 수 있습니다.
Compose 구성에서는 환경과 지원 버전에 따라 cpus, mem_limit 또는 배포 자원 제한을 사용할 수 있습니다.
개념적인 예시는 다음과 같습니다.
services:
app:
cpus: "1.0"
mem_limit: 1g이 설정은 해당 서비스가 사용할 수 있는 CPU와 메모리에 상한을 두기 위한 예시입니다.
Container Manager와 현재 Compose 버전에서 실제로 지원되는 항목인지 확인한 뒤 적용해야 합니다.
자원 제한을 적용할 때 주의할 점
- 현재 최대 사용량을 먼저 측정합니다.
- 워드프레스와 DB를 같은 기준으로 제한하지 않습니다.
- 초기 업데이트와 백업에 필요한 여유를 고려합니다.
- 메모리를 너무 낮게 제한하지 않습니다.
- 제한 적용 후 컨테이너 재시작 여부를 확인합니다.
- 사이트와 관리자 기능을 다시 테스트합니다.
- OOM 또는 강제 종료 기록을 확인합니다.
자원 제한은 성능을 높이는 설정이 아니라 한 컨테이너가 NAS 전체 자원을 독점하지 못하도록 만드는 안전장치에 가깝습니다.
자원 충돌을 빠르게 찾는 진단표
| 확인 결과 | 가능성이 높은 원인 | 우선 조치 |
|---|---|---|
| 특정 컨테이너 중지 후 빨라짐 | 해당 컨테이너 자원 점유 | 내부 작업과 실행 주기 확인 |
| CPU가 장시간 높음 | 연산 작업 | CPU 사용 컨테이너 확인 |
| 스왑 사용량이 계속 증가 | 메모리 부족 | 컨테이너 메모리와 재시작 확인 |
| CPU는 낮지만 디스크가 높음 | I/O 충돌 | 백업·다운로드·색인 확인 |
| 내부는 빠르고 외부만 느림 | 업로드 대역폭 | 외부 백업·스트리밍 확인 |
| 컨테이너가 시작되지 않음 | 포트 충돌 | 호스트 포트 확인 |
| 직접 포트 접속은 정상 | 프록시 문제 | 리버스 프록시 목적지 확인 |
| MariaDB 재시작 기록 존재 | DB 메모리·오류 | DB 자원과 볼륨 확인 |
| 매일 같은 시간에 느림 | 예약 작업 중복 | 실행 시간 분리 |
| 로그가 계속 증가 | 반복 오류 | 최초 오류 원인 해결 |
| 재부팅 후 잠시 정상 | 메모리·스왑·누적 작업 | 시간대별 기록 확인 |
| WordPress만 느림 | PHP·DB·컨테이너 연결 | 관련 컨테이너만 점검 |
가장 효율적인 진단 순서
- 사이트가 느려지는 시간과 증상을 기록합니다.
- NAS 전체가 느린지 워드프레스만 느린지 구분합니다.
- DSM 리소스 모니터에서 CPU·메모리·디스크·네트워크를 확인합니다.
- Container Manager에서 컨테이너별 사용량을 비교합니다.
- 문제가 발생한 시간에 실행된 작업을 찾습니다.
- 의심되는 일반 컨테이너를 하나씩 중지해 비교합니다.
- 스왑과 컨테이너 재시작 여부를 확인합니다.
- 볼륨 위치와 디스크 I/O를 확인합니다.
- 로그 파일의 증가와 반복 오류를 확인합니다.
- 네트워크 송수신과 외부 백업을 확인합니다.
- 호스트 포트 중복 여부를 점검합니다.
- 리버스 프록시의 목적지 포트를 확인합니다.
- WordPress와 MariaDB 컨테이너 연결을 확인합니다.
- DSM·워드프레스·컨테이너 예약 작업 시간을 비교합니다.
- 실제 사용량을 기준으로 CPU와 메모리 제한을 검토합니다.
바로 하면 위험한 조치
이름을 모르는 컨테이너를 중지하지 않는다
워드프레스 DB, 리버스 프록시 또는 인증 서비스일 수 있습니다.
Docker 볼륨을 삭제하지 않는다
사용하지 않는 것처럼 보이는 볼륨에 MariaDB 데이터나 워드프레스 파일이 저장되어 있을 수 있습니다.
CPU와 메모리를 극단적으로 제한하지 않는다
자원 충돌은 줄어들 수 있지만 컨테이너가 정상적으로 시작되지 않거나 반복 종료될 수 있습니다.
OOM 종료 기능을 무조건 끄지 않는다
메모리 부족 상태에서 프로세스를 종료하지 못하게 하면 NAS 전체가 불안정해질 수 있습니다.
컨테이너 로그만 삭제하지 않는다
반복되는 오류를 해결하지 않으면 로그가 다시 증가합니다.
모든 컨테이너를 동시에 재시작하지 않는다
재시작 직후 초기화, DB 검사와 색인이 동시에 실행돼 오히려 부하가 커질 수 있습니다.
NAS 메모리 부족이라고 바로 단정하지 않는다
디스크 I/O나 외부 통신 지연도 비슷한 증상을 만들 수 있습니다.
자원 충돌을 예방하는 운영 방법
컨테이너 역할을 기록한다
컨테이너 이름, 내부 포트, 호스트 포트, 볼륨과 다른 서비스와의 연결 관계를 정리합니다.
무거운 작업 시간을 분리한다
백업, 색인, 미디어 변환과 보안 검사가 같은 시간에 실행되지 않도록 조정합니다.
로그 보존 크기를 관리한다
컨테이너 로그가 무제한으로 증가하지 않도록 크기와 보관 개수를 검토합니다.
사용하지 않는 컨테이너는 자동 실행하지 않는다
가끔 사용하는 서비스까지 NAS 부팅과 동시에 실행할 필요가 있는지 확인합니다.
워드프레스와 DB 자원을 함께 본다
워드프레스 컨테이너만 가볍다고 사이트가 빠른 것은 아닙니다. MariaDB와 캐시 서비스도 함께 확인해야 합니다.
변경 전후 사용량을 비교한다
새 컨테이너를 설치할 때는 실행 전과 실행 후의 CPU, 메모리, 디스크와 네트워크 사용량을 기록합니다.
NAS에 여유 자원을 남긴다
모든 컨테이너에 자원을 최대로 할당하면 DSM, 파일 서비스와 긴급 작업이 사용할 여유가 없어집니다.
자주 묻는 질문
Docker 컨테이너는 서로 분리되어 있는데 왜 워드프레스가 느려지나요?
실행 환경은 분리되어 있지만 CPU, 메모리, 저장장치와 네트워크는 같은 NAS의 자원을 공유하기 때문입니다.
컨테이너 CPU가 100%를 넘으면 오류인가요?
표시 방식과 CPU 코어 수에 따라 100%를 넘게 보일 수 있습니다. 전체 CPU 사용률과 지속 시간, 사이트 지연을 함께 확인해야 합니다.
메모리 제한을 설정하면 NAS가 빨라지나요?
한 컨테이너의 자원 독점을 막는 데 도움이 될 수 있지만 제한이 너무 낮으면 컨테이너가 종료되거나 느려질 수 있습니다. 먼저 실제 사용량을 측정해야 합니다.
CPU가 낮은데 NAS가 느린 이유는 무엇인가요?
디스크 I/O, 스왑, 네트워크 대역폭 또는 외부 서버 응답이 병목일 수 있습니다.
컨테이너를 중지하니 워드프레스가 빨라졌습니다. 삭제해도 되나요?
먼저 해당 컨테이너의 역할, 볼륨과 다른 서비스와의 연결을 확인해야 합니다. 작업 시간 조정이나 자원 제한만으로 해결될 수도 있습니다.
502와 504 오류도 자원 충돌 때문에 생길 수 있나요?
가능합니다. 502는 프록시가 백엔드 서비스에 연결하지 못했을 때, 504는 응답을 기다리다 시간이 초과됐을 때 나타날 수 있습니다. 포트 설정과 자원 사용량을 함께 확인해야 합니다.
WordPress와 MariaDB 중 어느 컨테이너에 자원을 더 줘야 하나요?
사이트 규모, 플러그인, 방문량과 쿼리 형태에 따라 다릅니다. 컨테이너별 실제 사용량과 병목을 확인하지 않고 일괄적으로 결정하면 안 됩니다.
예약 작업 시간만 바꿔도 해결될 수 있나요?
여러 서비스가 같은 시간에 정상 작업을 실행하면서 충돌한 경우에는 실행 시간 분리만으로도 효과가 클 수 있습니다.
마무리
시놀로지 NAS에서 워드프레스와 Docker 서비스를 함께 운영할 때 발생하는 성능 저하는 워드프레스 자체의 문제만으로 판단해서는 안 됩니다.
컨테이너는 실행 환경은 분리하지만 CPU, 메모리, 저장장치와 네트워크를 자동으로 분리해 보장하지는 않습니다.
먼저 NAS 전체가 느린지 워드프레스만 느린지 구분하고, DSM 리소스 모니터와 Container Manager에서 같은 시간대의 사용량을 비교해야 합니다.
CPU가 높다면 연산 작업을, 스왑이 증가한다면 메모리 부족을, 디스크 사용률이 높다면 백업·다운로드·색인·로그 작업을 확인합니다. 외부 접속만 느리다면 네트워크 업로드 대역폭도 살펴봐야 합니다.
컨테이너가 시작되지 않거나 예상과 다른 서비스가 열리면 자원보다 호스트 포트와 리버스 프록시 설정을 먼저 확인하는 것이 맞습니다.
가장 확실한 방법은 연결 관계를 확인한 일반 컨테이너를 하나씩 중지해 워드프레스 속도가 달라지는지 비교하는 것입니다.
원인이 확인된 뒤에 예약 작업 시간 조정, 로그 제한, 자동 실행 정리와 CPU·메모리 제한을 적용해야 합니다. 측정 없이 모든 컨테이너를 삭제하거나 자원을 지나치게 제한하면 새로운 장애가 생길 수 있습니다.
IT왕세자
댓글 0
첫 댓글을 남겨보세요.