[EC2] AWS EC2에 네트워크 트래픽 스파이크와 CPU 크레딧소모로 인한 서버 다운 해결 방법

들어가며

EC2에 t2.micro 인스턴스를 올려놓고 스테이징용 백엔드 서버로 쓰고 있었다. 그런데 어느 순간 보니 서버가 죽어 있는 것 아닌가? 인스턴스 모니터링을 보니, 네트워크 패킷 입력 그래프에 뾰족한 것이 보였다. 지금 서비스가 돌아가고 있는 서버도 아닌데, 아이고...

0. 자세한 상황

• 네트워크 패킷 입력에 스파이크 나타남
• 같은 시간대에 CPU 사용률 100% 달성
• 이후 CPU 크레딧이 0을 향해 달려감
• 서버 다운되어 접근 불가능해짐

아... 다시 봐도 머리가 아프다.

1. 예상 원인 분석

DDoS인가?
보통 필자가 겪은 가장 흔한 원인은 SecurityGroup(보안 그룹) 설정이 미흡해 랜덤 DDOS에 치이는 경우다. 그런데 본인은 이미 이를 몇 번 당해봐서 이 문제는 절대 아님을 확신할 수 있었다. 혹시 몰라 더블 체크를 했으나 당연히 문제는 없었다.

 

그럼 코드 탓인가?
그게 아니라면 인스턴스에 올라간 애플리케이션 내부 무한루프 내지는 메모리 누수가 있을 수 있다. 하지만 네트워크 패킷에 스파이크가 찍히기 전까진 고요했으니 이것도 원인이라고 할 수는 없겠다. 당장 인스턴스에 올라간 건 REST API 서버 정도였으니, 무한루프가 터지기가 더 어렵지 않을까.

결국 이리저리 분석하다 발견한 원인은 다른 무언가였으니...

2. 실제 원인 분석 과정

우선 내가 놓치고 있는 무언가가 있는지, 혹시 몰라 열린 경로를 찾아보았다.
이 글을 읽고 계신 분들 중, SecurityGroup 설정이 미흡(0.0.0.0/0으로 열어둔다던가...)한 경우 아래 명령어로 잡히는 리스닝 소켓들을 막거나, SecurityGroup 부분을 제대로 설정하면 DDoS 공격을 막을 수 있을 것이다.

$ ss -tulpn | grep 0.0.0.0

 

필자는 다른 경우였으니 다음으로 넘어가자.

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           957Mi       827Mi        67Mi       1.1Mi       219Mi       130Mi
Swap:             0B          0B          0B

 

벌써 느낌이 온다. 인스턴스를 재부팅했는데도 저렇게 메모리 압박이 다가온다.

우선 CPU가 터져나간 이유는 아마도 메모리가 먼저 터졌기 때문이리라.

실제로 무슨 일이 일어났는지는 페이징과 스레싱에 대해 따로 찾아보도록 하자. CS 만세.

 

대략 인스턴스의 사망 원인은 알아냈다. 그런데 메모리가 왜 터져나갔을까? 네트워크 트래픽은 왜 솟구쳤는가? 여기에 대한 문제가 해결되지 않았다. 네트워크 트래픽이 몰린 시간대를 보고 관련 네트워크 로그를 딸 수 있는 것들을 찾아봤다.

$ sudo journalctl --since "2 days ago" | grep -i "network\|traffic\|ddos\|attack"

 

아웃풋은 지극히 정상적인 Docker 활동이었다. 다음.

$ sudo docker-compose logs app --since 24h | head -100

 

애플리케이션 로그. 여기도 깨끗하다. 다음.

$ cat /proc/net/dev

 

네트워크 인터페이스 로그...는 봐도 잘 모르겠다. 다음.

# 네트워크 트래픽이 몰린 06:20~06:30 시간대 모든 로그
sudo journalctl --since "2025-08-28 06:20:00" --until "2025-08-28 06:30:00"

# Docker 컨테이너 로그 (해당 시간대)
sudo docker-compose logs --since "2025-08-28T06:20:00" --until "2025-08-28T06:30:00"

# 시스템 리소스 관련 로그
sudo journalctl --since "2025-08-28 06:20:00" --until "2025-08-28 06:30:00" | grep -i "cpu\|memory\|oom\|kill"

 

드디어 단서를 잡을 수 있었다. 로그를 정리해보자면 다음과 같다.

1. cron-daily 작업 시작
2. apt-daily-upgrade 작업 시작
3. PackageKit 데몬 시작
4. fwupd 서비스 재시작 (155.1M 메모리 사용)
5. 메모리 압박으로 캐시 플러시

요약하자면 데일리 시스템 업데이트가 크론잡으로 돌았고, 이때 여러 시스템 서비스가 동시에 돌면서 메모리가 터진 것이다.

그 이후는 직전에 언급한대로...

3. 해결 - 업데이트 비활성화

그리 오래 쓸 인스턴스도 아니고, 프라이빗하게 사용하는 인스턴스인데 굳이 무언가 몸을 비틀 필요는 없다고 생각했다.
자동 업데이트를 꺼버리면 해결되는 것 아닌가?

# 자동 업데이트 비활성화
sudo systemctl disable apt-daily-upgrade.service

# 타이머도 비활성화
sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl stop apt-daily-upgrade.timer

# apt-daily 관련 모든 서비스/타이머 비활성화
sudo systemctl disable apt-daily.timer
sudo systemctl stop apt-daily.timer

 

이와 별개로 t2.micro의 메모리 할당량에 대한 기억을 되찾았으니, 바로 Swap space까지 걸어주도록 하자.

Swap space 설정하기

# 128M * 16 = 2GB
sudo dd if=/dev/zero of=/swapfile bs=128M count=16

sudo chmod 600 /swapfile

sudo mkswap /swapfile

sudo swapon /swapfile

sudo swapon -s

 

Swap space 설정이 끝났다.
Swapfile용 파일을 만들고, 권한 잡고, 적용하고, 활성화했다. 마지막은 잘 되었는지 로그 확인용이다. 지금은 2GB로 설정했으며, 필요에 따라 수정하면 된다. 인스턴스 재부팅 이후에도 계속 Swap space를 적용하려면 아래 작업을 진행하자.

sudo vi /etc/fstab

 

위 명령어 입력 후 나타난 vi에  /swapfile swap swap defaults 를 작성하고 저장하자.

free

 

명령어로 Swap space가 잘 적용되었는지 확인하자.

 

맺으며

https://www.youtube.com/watch?v=n3-oeEJWgc0

 

어째 AWS, 특히 t2.micro는 매번 쓸 때마다 별 일이 다 생기는 기분이다. 언제쯤 되어야 이런 일들을 겪지 않을 수 있을지...

 

Reference

https://diary-developer.tistory.com/32 - Swapfile 생성 및 Swap Space 설정