[소소한 개발 일지] EC2의 CPU 점유율이 100%로 멈출 때 (Ubuntu, NGINX)
[소소한 개발 일지] EC2의 CPU 점유율이 100%로 멈출 때 (Ubuntu, NGINX)
2024-10-05
Explanation
어제 갑작이 블로그가 갑자기 접속이 안되는 이슈가 있었는데요. 오늘이 이 문제를 해결한 과정에 대하여 소소히 공유해 보려 합니다.
저는 Ubuntu 22.04.4 버전을 사용하고 있습니다.
우선, AWS의 CloudWatch를 확인해 봤는데요, CPU 사용률이 평소에는 5% 내외로 사용하는데 어느 시점으로 급증하더니 100%에 가깝게 지표가 나타났답니다.
이럴 때, 모두가 아는 가장 보편적이고 확실한 해결 방법!!
EC2를 재시작해 봤는데요. 재부팅된 서버 컴퓨터가 괜찮다가 NGINX만 실행하면 다시 CPU가 100%까지 증가하는 문제가 있었습니다.
이전에도 비슷한 문제가 있었는데, 그때는 사용하는 컴퓨터의 메모리가 부족해서 발생한 이슈였는데요.
1 |
$ free |
1 2 3 |
total used free shared buff/cache available Mem: 980416 425512 113120 53468 441784 340212 Swap: 0 0 0 |
위와 같이 free 명령어를 통해서 현재의 메모리 사용 상태를 확인할 수 있습니다.
Ubuntu에는 시스템의 물리적 메모리(RAM)가 부족할 때 임시로 디스크 공간을 메모리로 사용할 수 있도록 하는 “Swap”이라는 기능이 있는데요. 이 기능을 이용해서, 서버 컴퓨터의 사양을 직접적으로 업그레이드 하지 않고 임시로 문제를 해결할 수 있습니다.
1 |
$ sudo dd if=/dev/zero of=/swapfile bs=1K count=2000000 |
dd 명령어를 사용해서 원하는 크기의 빈 파일을 생성합니다.
– if=/dev/zero : 빈 데이터를 읽어오는 소스
– of=/swapfile : 생성될 Swap 파일 경로
– bs=1K : 블록 크기, 여기서는 1KB씩 할당
– count=2000000 : 블록의 수, 즉 총 2000000KB (약 2GB)를 생성
Swap 파일의 권한을 설정해주고
1 |
$ sudo chmod 600 /swapfile |
“/swapfile” 파일을 Swap 파일 형식으로 지정합니다.
1 |
$ mkswap /swapfile |
“/swapfile” 파일을 Swap 공간으로 활성화합니다.
1 |
$ swapon /swapfile |
끝으로 다시 메모리를 확인해봅니다.
1 |
$ free |
1 2 3 |
total used free shared buff/cache available Mem: 980416 356176 115544 33920 508696 430484 Swap: 1999996 516096 1483900 |
위와 같이 Swap에 2000M의 공간이 메모리로 사용되는 것을 확인할 수 있습니다.
필요한 경우, 설정한 Swap은 아래의 명령어를 통해 해지할 수 있습니다.
1 2 |
$ sudo swapoff -a # 활성화 된 Swap을 비활성화 합니다. $ sudo rm /swapfile # 기존의 Swap 파일을 제거합니다. |
저는 위와 같이 Swap 기능을 사용하여 메모리의 여유 공간을 주었는데도 CPU의 점유율이 줄어들지 않아서 로그를 확인해봤는데요.
1 2 |
$ cat /var/log/nginx/error.log # 오류 로그 확인 $ cat /var/log/nginx/access.log # 액세스 로그 확인 |
저는 오류 로그를 확인 했을 때, 대부분 CPU 점유율 문제로 NGINX의 PHP-FPM가 연결에 실패하는 오류가 대부분이었습니다. 그래서 다음으로 액세스 로그를 확인해 봤는데요.
1 2 3 4 5 6 7 |
3.134.98.106 - - [04/Oct/2024:06:25:20 +0000] "GET /.git/objects/d8/5f9a96f6324844bdb2584eb6efa5ce6... 3.134.98.106 - - [04/Oct/2024:06:25:20 +0000] "GET /.git/objects/84/816e43ebbe62fd5ee01706ada63d28e... 3.134.98.106 - - [04/Oct/2024:06:25:25 +0000] "GET /.git/objects/30/12513d252f9efecb4d508567ecc7f24... 3.134.98.106 - - [04/Oct/2024:06:25:25 +0000] "GET /.git/objects/7b/70a6454cd92c202c46f15bcc8d31047... 3.134.98.106 - - [04/Oct/2024:06:25:25 +0000] "GET /.git/objects/c4/3f1932628775837343c42ad9be35729... 3.134.98.106 - - [04/Oct/2024:06:25:33 +0000] "GET /.git/objects/c4/c9b1e457dc6ad66c5440928c61d4799... ... |
아주 빠른 속도로 위와 같은 요청이 계속 오는 것을 확인하였답니다.
.git 디렉토리의 하위 파일을, 거기다 반복적으로 접근하는 것을 봐서 악의적인 스캔이거나 DDoS 공격인 것 같았어요. 그래서 NGINX의 가상 호스트 설정에서 .git 디렉토리에 대한 접근 차단 설정 후 NGINX를 재시작 하였더니 점차 CPU 점유율이 안정적으로 돌아오는 것을 확인할 수 있었습니다.
저와 같은 경우라면, 대략 아래와 같이 차단할 수 있습니다.
1 2 3 4 5 6 7 8 |
server { ... # .git 디렉토리에 대한 모든 접근 차단 location ~ /\.git { deny all; } ... } |