배경

포트폴리오 사이트의 접속이 느려지고 서버가 자주 응답하지 않았다. 화면의 틀은 먼저 나타났지만 글과 이미지가 늦게 채워졌다. 배포에도 시간이 오래 걸렸다.

처음에는 작은 서버의 메모리가 부족한 문제라고 생각했다. 프론트가 죽으면 systemd 감시 서비스로 다시 시작하게 해두었지만, 재시작은 증상을 잠시 줄일 뿐이었다. 결국 컨테이너 내부 프로세스까지 확인하면서 단순한 사양 부족과 다른 정황을 발견했다.

이 글은 당시 수집한 로그를 바탕으로 원인을 좁혀간 기록이다. 특정 취약점이 실제 침입 경로였는지까지 입증한 보안 분석 보고서는 아니다.

가설 1. 메모리 부족

먼저 메모리, 스왑, 디스크와 OOM 여부를 확인했다.

free -h
swapon --show
df -h
sudo journalctl -k --since "24 hours ago" | grep -Ei 'oom|out of memory|killed process'
docker inspect portfolio-front --format 'OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}} Restarts={{.RestartCount}}'

주요 결과는 다음과 같았다.

항목	관측값
메모리 available	약 669MiB
스왑	2GiB 중 약 336MiB 사
루트 디스크 사용률	27%

free 열의 값은 작았지만, 캐시를 회수해 사용할 수 있는 available 메모리는 남아 있었다. 스왑이 사용 중이라는 사실만으로 현재 메모리 부족을 확정할 수도 없었다.

이 결과는 모든 과거 OOM을 배제하지 않는다. 특히 컨테이너가 재생성됐다면 현재 컨테이너의 상태만으로 이전 장애를 설명할 수 없다. 다만 이 시점에는 메모리보다 다른 자원도 확인할 이유가 충분했다.

가설 2 .CPU 사용률

nproc
uptime
docker stats --no-stream
vmstat 1 5

nproc는 2를 반환했고, load average는 다음과 같았다.

load average: 12.06, 13.72, 18.09

2개의 CPU를 사용할 수 있는 환경에서 높은 부하가 지속되고 있었다. 다만 load average는 CPU 사용률 자체가 아니다. 실행 대기 작업뿐 아니라 일부 I/O 대기 작업도 포함하므로 vmstat와 함께 읽어야 한다.

5초 간격으로 반복한 docker stats에서는 프론트가 약 366~399%, 관리자가 약 357~378%로 표시됐다. 반면 백엔드와 PostgreSQL은 거의 0%였다.

여기에는 해석상의 주의점도 있었다. 2 CPU라는 결과와 컨테이너 CPU 백분율을 단순 합산한 값이 맞지 않았다. 이 숫자만 보고 실제로 몇 개의 코어를 사용했다고 결론 내리지는 않았다. 반복해서 같은 두 컨테이너가 높게 나타난다는 점을 조사 우선순위로 삼았다.

vmstat의 후속 샘플에서는 실행 대기 r이 14~18, idle은 거의 0%, steal time인 st가 약 79~81%였다. 첫 줄은 부팅 이후 평균이므로 후속 샘플과 구분했다.

높은 steal time은 가상 머신이 CPU를 할당받지 못하는 시간을 나타낸다. 버스터블 인스턴스의 제한이나 호스트 측 자원 상황을 함께 확인할 신호지만, 이것만으로 Lightsail 버스트 용량 소진을 확정할 수는 없다. 콘솔의 남은 버스트 용량 지표는 별도로 확인해야 한다.

가설 3 . 다른 프로세스가 점유중?

프론트와 관리자 컨테이너의 프로세스를 확인했다.

docker top portfolio-front -eo pid,ppid,pcpu,pmem,etime,args
docker top portfolio-admin -eo pid,ppid,pcpu,pmem,etime,args

정상적인 Next.js 서버 외에 다음과 같은 명령이 보였다.

next-server (v15.3.3)
./5pcy40ee
./i5q8g4nn5ljg
/root/.lbduczvgapal --guard > /dev/null 2>&1 &
/tmp/dashboard --config /tmp/v.json

관리자 컨테이너의 /tmp/dashboard는 약 27일 동안 실행된 상태였고, 프로세스 평균 CPU 사용률은 99.5%로 표시됐다. 프론트에서도 무작위 이름의 실행 파일과 여러 셸 프로세스가 Next.js 프로세스 아래에 연결되어 있었다.

이 시점부터는 일반적인 렌더링 성능 문제보다 컨테이너 침해와 비정상 프로그램 실행을 강하게 의심해야 하는 상황이었다. 채굴 악성코드와 유사한 정황이지만, 실행 파일 분석 없이 악성코드 종류나 최초 침입 경로까지 단정하지는 않았다. 프로세스 이름이 next-server라고 해서 정상 프로세스라고 보장되는 것도 아니다.

의심 컨테이너를 멈춘 뒤 지표 재확인

자동으로 프론트를 다시 켜는 watchdog을 비활성화하고, 의심되는 프론트·관리자 컨테이너를 중지했다. 감시 서비스가 살아 있으면 조사 중인 컨테이너가 다시 실행될 수 있기 때문이다.

그 뒤 확인한 vmstat 후속 샘플은 크게 달라졌다.

항목	중지 전	중지 후
실행 대기 작업 r	약 14~18	0
CPU idle	거의 0%	약 99~100%
\| CPU steal	약 79~81%	\| 약 0~1%

이 변화는 해당 컨테이너의 부하가 장애에 크게 기여했다는 근거가 됐다. 다만 부하가 줄어든 사실이 호스트 전체의 안전성을 증명해주지는 않는다.

중지 후에도 MainThread라는 프로세스가 보여 추가로 확인했다. 다음은 당시 PID를 사용한 명령이다.

sudo cat /proc/3658532/cgroup /proc/3658279/cgroup
sudo readlink /proc/3658532/exe /proc/3658279/exe

두 프로세스는 백엔드 컨테이너에 속했고 실행 파일은 /usr/local/bin/node였다. 이름만 보고 추가 악성코드라고 판단할 근거는 없었다. 반대로 Node 프로세스라는 사실만으로 무조건 정상이라고 단정할 수도 없다. 소속, 실행 인자, 로그를 함께 보는 것이 중요했다.

복구

의심 컨테이너를 재시작하는 방식 대신 깨끗한 서버에 환경을 다시 구성했다. 의존성을 업데이트하고, DB는 기존 서버 전체 스냅샷 대신 논리 백업을 통해 이전했다.

이번 장애에서 얻은 점

작은 서버가 느려졌다고 곧바로 증설하거나 스왑부터 늘릴 문제는 아니었다. 자원 지표에서 시작해 컨테이너별 부하를 비교하고, 내부 프로세스와 부모·자식 관계를 확인하면서 원인을 좁힐 수 있었다.

자동 재시작은 가용성을 보조하지만, 비정상 프로세스까지 반복해서 살려낼 수 있다. 이번에는 의심 컨테이너 중지 전후의 부하 차이가 가장 중요한 근거였다. 이후의 빌드 최적화는 이 침해 대응과 구분해서 진행했다.

전체글 보기

전체글 보기