어제 갑작이 블로그가 갑자기 접속이 안되는 이슈가 있었는데요. 오늘이 이 문제를 해결한 과정에 대하여 소소히 공유해 보려 합니다.

저는 Ubuntu 22.04.4 버전을 사용하고 있습니다.

1. 문제 상황

우선, AWS의 CloudWatch를 확인해 봤는데요, CPU 사용률이 평소에는 5% 내외로 사용하는데 어느 시점으로 급증하더니 100%에 가깝게 지표가 나타났답니다.

이럴 때, 모두가 아는 가장 보편적이고 확실한 해결 방법!!
EC2를 재시작해 봤는데요. 재부팅된 서버 컴퓨터가 괜찮다가 NGINX만 실행하면 다시 CPU가 100%까지 증가하는 문제가 있었습니다.

이전에도 비슷한 문제가 있었는데, 그때는 사용하는 컴퓨터의 메모리가 부족해서 발생한 이슈였는데요.

위와 같이 free 명령어를 통해서 현재의 메모리 사용 상태를 확인할 수 있습니다.

2. Swap

Ubuntu에는 시스템의 물리적 메모리(RAM)가 부족할 때 임시로 디스크 공간을 메모리로 사용할 수 있도록 하는 “Swap”이라는 기능이 있는데요. 이 기능을 이용해서, 서버 컴퓨터의 사양을 직접적으로 업그레이드 하지 않고 임시로 문제를 해결할 수 있습니다.

dd 명령어를 사용해서 원하는 크기의 빈 파일을 생성합니다.
– if=/dev/zero : 빈 데이터를 읽어오는 소스
– of=/swapfile : 생성될 Swap 파일 경로
– bs=1K : 블록 크기, 여기서는 1KB씩 할당
– count=2000000 : 블록의 수, 즉 총 2000000KB (약 2GB)를 생성

Swap 파일의 권한을 설정해주고

“/swapfile” 파일을 Swap 파일 형식으로 지정합니다.

“/swapfile” 파일을 Swap 공간으로 활성화합니다.

끝으로 다시 메모리를 확인해봅니다.

위와 같이 Swap에 2000M의 공간이 메모리로 사용되는 것을 확인할 수 있습니다.

필요한 경우, 설정한 Swap은 아래의 명령어를 통해 해지할 수 있습니다.

3. 로그 확인 및 해결

저는 위와 같이 Swap 기능을 사용하여 메모리의 여유 공간을 주었는데도 CPU의 점유율이 줄어들지 않아서 로그를 확인해봤는데요.

저는 오류 로그를 확인 했을 때, 대부분 CPU 점유율 문제로 NGINX의 PHP-FPM가 연결에 실패하는 오류가 대부분이었습니다. 그래서 다음으로 액세스 로그를 확인해 봤는데요.

아주 빠른 속도로 위와 같은 요청이 계속 오는 것을 확인하였답니다.
.git 디렉토리의 하위 파일을, 거기다 반복적으로 접근하는 것을 봐서 악의적인 스캔이거나 DDoS 공격인 것 같았어요. 그래서 NGINX의 가상 호스트 설정에서 .git 디렉토리에 대한 접근 차단 설정 후 NGINX를 재시작 하였더니 점차 CPU 점유율이 안정적으로 돌아오는 것을 확인할 수 있었습니다.

저와 같은 경우라면, 대략 아래와 같이 차단할 수 있습니다.

끝