가상 메모리를 통한 EC2 t2.micro 서버 다운 현상 해결

서론

---

인턴십 온보딩 기간 동안 간단한 사내 프로젝트를 수행했습니다.

 

프로젝트의 배포는 EC2 t2.micro 위에 Docker Compose로 next.js, NestJS, PostgreSQL을 하나의 서비스로 정의해 컨테이너 묶음으로 관리했습니다.

 

컨테이너를 올리는 것까지는 정상적으로 동작했지만 컨테이너를 올린 뒤, 몇초가 지나면 EC2 서버가 다운되는 현상이 지속되었기에 이를 해결해보겠습니다.

 

 

 

Scouter 적용

---

보통 EC2의 t2.micro는 일반 컴퓨터에 비해서 사양이 매우 낮기 때문에 과도한 CPU 버스트가 일어나거나, 할당할 수 있는 메모리가 없는 경우에 다운됩니다.

 

이를 확인해보기 위해 두가지 방법을 생각했습니다.

 

1. SSH로 EC2에 접근한 뒤, 명령어를 통해 CPU와 메모리 사용률을 측정한다.

2. Scouter를 이용해 로컬 PC에서 EC2의 CPU와 메모리 사용률을 측정한다.

 

두가지 방법 모두 CPU와 메모리 사용률을 측정할 수 있지만, Scouter를 이용하면 GUI를 통해 좀 더 가독성있는 분석이 가능하기 때문에 Scouter를 이용해 분석해보겠습니다.

 

 

 

CPU, Memory 사용률 측정

---

로컬에서 EC2의 성능을 모니터링할 것이기 때문에 Scouter Agent와 Server를 EC2에서, 클라이언트를 로컬 PC에서 구동 시키겠습니다.

 

scouter server 실행

 

scouter agent 실행

 

 

 

이제 EC2에서 컨테이너를 올린 뒤 성능을 측정해보겠습니다.

 

CPU 사용률은 100%가 되어도 정상 동작하는 것을 볼 수 있습니다.

 

 

하지만 메모리 사용률이 90%에서 95% 이상으로 올라가는 동안 서버가 다운되어 메모리 사용률 수집이 안되는 것을 볼 수 있습니다.

 

이를 통해 메모리 부족으로 인해 서버가 다운된다는 것을 알 수 있습니다.

 

 

 

가상 메모리 적용

---

메모리 부족 문제를 해결하기 위해 HDD 일부를 스왑 메모리로 지정해 메모리 가용 공간을 증가시켜 보겠습니다.

 

스왑 메모리 설정 과정은 아래와 같습니다.

 

// 스왑 파일 생성
$ sudo dd if=/dev/zero of=/swapfile bs=128M count=32

// 스왑 파일의 권한 업데이트
$ sudo chmod 600 /swapfile


// 스왑 영역 설정
$ sudo mkswap /swapfile

// 스왑 공간에 스왑 파일 추가
$ sudo swapon /swapfile

// 정상적으로 추가됐는지 확인
$ sudo swapon -s

// vi로 스왑파일 연 후 마지막줄에 아래 명령어 추가
$ sudo vi /etc/fstab

/swapfile swap swap defaults 0 0

 

 

스왑 메모리 설정이 끝났으니 다시 컨테이너를 올려 성능을 측정해보겠습니다.

 

 

HDD를 스왑 메모리로 설정하기 전에는 95%를 넘겼던 메모리 사용률이 70~80%대가 되었고 서버도 다운되지 않는것을 확인할 수 있습니다.

 

 

 

결론

---

가상 메모리는 메모리 공간 부족 문제를 해결해준다는 장점이 있지만, 그에 따른 단점이 있습니다.

 

스왑핑 오버헤드로 인한 성능 저하, 가상 메모리 관리를 위한 페이지 테이블 생성 과정에서 생기는 메모리 오버헤드 등의 문제가 발생할 수 있습니다.

 

스케일 업 비용이 부담된다면 어쩔 수 없는 선택이겠지만, 그렇지 않을 경우엔 스케일 업을 통해 메모리가 많은 인스턴스를 사용하는것이 좋지 않을까 생각됩니다.

 

 

References

https://repost.aws/knowledge-center/ec2-memory-swap-file

Use swap file to allocate memory as swap space in Amazon EC2 instance