워드프레스 도커 운영 시 직면하는 OOM(Out Of Memory) 현상의 이해
개인용 서버나 시놀로지 NAS를 활용하여 웹사이트를 구축할 때, 도커(Docker, Container Manager)를 통한 워드프레스 설치는 가장 표준적이고 효율적인 방법으로 자리 잡았습니다. 컨테이너 기술을 활용하면 웹 서버, 데이터베이스, PHP 구동 환경을 독립적으로 분리하여 관리할 수 있기 때문입니다.
그러나 본격적으로 웹사이트에 테마를 입히고 플러그인을 설치하며 트래픽이 발생하기 시작하면, 예기치 않게 웹사이트 접속이 차단되고 브라우저에 ‘502 Bad Gateway’ 또는 ‘데이터베이스 연결 오류(Error establishing a database connection)’ 메시지가 출력되는 현상을 자주 겪게 됩니다.
시놀로지 관리자 페이지(DSM)에 접속하여 확인해 보면 멀쩡히 돌아가던 워드프레스 컨테이너나 MariaDB 컨테이너가 예고 없이 강제 종료(Stopped)되어 있는 것을 발견할 수 있습니다. 이것이 바로 리눅스 기반 시스템에서 발생하는 악명 높은 OOM(Out Of Memory) 에러의 전형적인 증상입니다.
본 글에서는 NAS의 하드웨어적 한계가 소프트웨어 시스템에 어떤 방식으로 병목 현상을 유발하는지 OOM Killer의 작동 원리를 통해 분석하고, 물리적 RAM 업그레이드가 서버 안정성에 미치는 기술적 파급 효과를 심도 있게 다루고자 합니다.
기본 RAM 2GB 환경의 한계와 스왑(Swap) 메모리의 함정
1. 기본 자원 할당량의 부족
대중적으로 많이 사용되는 시놀로지 Plus 라인업(예: DS220+, DS224+ 등)은 기본적으로 2GB의 메인보드 온보드(On-board) 메모리를 탑재하고 출시됩니다. 문제는 시놀로지의 운영체제인 DSM 자체와 파일 공유를 위한 필수 백그라운드 서비스들이 부팅 직후부터 이미 1GB 내외의 메모리를 점유한다는 점입니다.
따라서 사용자가 도커 컨테이너에 할당할 수 있는 실질적인 가용 메모리는 1GB 미만에 불과합니다. 워드프레스의 핵심인 PHP-FPM 프로세스와 MariaDB 등은 데이터 처리량이 늘어날수록 메모리 점유율이 급격히 상승하는 구조를 띄고 있어, 1GB의 여유 공간은 웹 호스팅 환경을 유지하기에 턱없이 부족한 수준입니다.
2. 디스크 I/O 병목과 스왑(Swap) 영역의 개입
물리적인 RAM이 가득 차면 리눅스 커널은 시스템 다운을 막기 위해 하드디스크(HDD)의 일부 공간을 가상 메모리, 즉 스왑(Swap) 영역으로 전환하여 사용하기 시작합니다. 당장 급한 데이터를 하드디스크에 임시로 적어두고 RAM 공간을 확보하는 일종의 연명 조치입니다.
하지만 하드디스크의 읽기/쓰기 속도는 물리적 RAM에 비해 수십에서 수백 배 이상 느립니다. 결과적으로 스왑 메모리 의존도가 높아지면 데이터 입출력(I/O)에 심각한 병목 현상이 발생하며, 워드프레스 관리자 페이지 전환에 수십 초가 걸리거나 프론트엔드 로딩 속도가 처참하게 무너지는 직접적인 원인이 됩니다.
리눅스 커널의 OOM Killer 작동 원리와 데이터베이스 강제 종료
스왑 메모리마저 한계에 다다르거나 순간적으로 처리해야 할 메모리 요구량이 가용 범위를 초과하게 되면, 리눅스 커널은 최후의 수단으로 ‘OOM Killer(Out Of Memory Killer)’ 프로세스를 호출합니다. 시스템 전체가 멈추는 커널 패닉(Kernel Panic) 상태를 방지하기 위해, 현재 가장 많은 메모리를 점유하고 있는 프로세스를 희생양으로 삼아 강제로 죽여버리는(Kill) 자기방어 매커니즘입니다.
도커 환경에서 운용되는 웹 서버의 경우, 이 OOM Killer의 최우선 타겟이 되는 것은 십중팔구 데이터베이스(MariaDB/MySQL) 프로세스입니다. 데이터베이스는 쿼리 결과를 캐싱하기 위해 구조적으로 메모리를 넉넉하게 잡아두는 성질이 있기 때문입니다.
DB 컨테이너가 OOM Killer에 의해 예고 없이 강제 종료되면, 워드프레스 웹 서버는 데이터를 읽고 쓸 곳을 잃게 되어 방문자에게 즉각적인 접속 에러를 뿜어냅니다. 이 현상은 일시적인 재시작으로 해결될 수 없으며, 물리적인 메모리 공간을 늘려주는 것만이 유일하고 근본적인 트러블슈팅 방법입니다.
RAM 업그레이드 트러블슈팅: 10GB vs 18GB 구성의 체감 차이
위와 같은 시스템 불안정성을 해결하기 위해 추가 확장 슬롯에 노트북용(SO-DIMM) DDR4 메모리를 장착하여 전체 용량을 늘려야 합니다. 일반적으로 8GB를 추가하여 총 10GB로 구성하거나, 16GB를 추가하여 총 18GB로 구성하는 방식을 선택합니다.
1. 가성비와 안정성의 균형: 10GB (8GB 추가)
1인 기업이나 개인 블로그 목적의 워드프레스 환경, 그리고 n8n과 같은 자동화 데몬을 2~3개 정도 병렬로 돌리는 용도라면 10GB 구성으로도 충분합니다. 운영체제와 핵심 패키지가 차지하는 2GB를 제외하고도 8GB의 여유 공간이 생기므로, 컨테이너들이 메모리를 아무리 많이 점유하더라도 OOM 에러가 발생할 확률은 0에 가깝게 수렴합니다.
2. 데이터 입출력 최적화의 극대화: 18GB (16GB 추가)
향후 대용량의 이미지 및 영상 에셋을 호스팅해야 하거나, 동시 접속자가 많은 커머스 플랫폼을 기획 중이라면 18GB 확장을 고려해 볼 수 있습니다. 남아도는 메모리는 결코 버려지는 것이 아니며, 리눅스의 파일 캐싱 아키텍처에 의해 웹사이트 로딩 속도를 극적으로 끌어올리는 숨은 공신 역할을 수행하게 됩니다.
업그레이드 이후의 기술적 변화: 리눅스 페이지 캐시(Page Cache)의 마법
메모리 업그레이드를 완료한 후 관리자 페이지를 모니터링해 보면, 컨테이너들이 실질적으로 사용하는 메모리는 3~4GB에 불과함에도 여유 메모리 공간이 거의 없는 것처럼 표시되는 경우가 있습니다. 이는 오류가 아니라 리눅스 운영체제의 지극히 정상적이고 효율적인 자원 관리 방식인 ‘페이지 캐시(Page Cache)’가 작동하고 있기 때문입니다.
시스템은 현재 구동 중인 앱이 사용하지 않고 남겨둔 ‘잉여 RAM 공간’을 전부 데이터 캐싱 용도로 할당합니다. 즉, 워드프레스의 테마 파일, 이미지 에셋, 자주 호출되는 DB 쿼리 데이터들을 하드디스크가 아닌 초고속 RAM 공간에 미리 올려두고 서비스하는 것입니다.
방문자가 웹페이지를 요청할 때마다 물리적인 하드디스크 헤더가 움직일 필요 없이 RAM에서 데이터를 즉각적으로 뿌려주게 되므로(Memory-mapped I/O), TTFB(Time To First Byte) 수치가 비약적으로 단축되고 전체적인 웹사이트 체감 반응 속도가 대폭 향상됩니다.
결론적으로 NAS 도커 환경에서의 RAM 업그레이드는 단순히 OOM 강제 종료라는 치명적인 에러를 막는 방어적인 조치를 넘어, 하드디스크의 I/O 병목을 우회하여 웹사이트의 전반적인 퍼포먼스와 검색엔진 최적화(SEO) 점수까지 끌어올리는 가장 강력하고 능동적인 서버 튜닝 기법이라 할 수 있습니다.
