AWS EC2 메모리 부족에 의한 서버 다운 문제 해결하기

EC2 서버 다운

EC2 컴퓨팅은 여러 가지 원인으로 다운될 수 있다.
코드에 에러가 있다든지 서버 설정의 문제일 수 있다. 아니면 의존성 패키지의 문제일 수도 있다.

다양한 경우가 있지만 만약 특별히 에러 로그가 확인되지 않고 트래픽이 몰리면서 에러가 발생한다면 메모리 부족일 확률이 높다.
이럴 때 AWS EC2의 모니터링을 확인해 보자. 메모리가 부족해서 서버가 다운될 때 CPU 사용률이 급격히 증가한다.

서버 다운은 서비스가 중단되는 최악의 상황이니 메모리 사용을 최적화하는 것은 굉장히 중요한 일이다.

여유 메모리 용량 확인

$ free -h

위 free 명령어를 통해서 ubuntu의 메모리 상태를 조회할 수 있다.
실질적으로 남은 메모리 용량은 available을 확인하면 된다.

메모리의 상태는 실시간으로 변한다.
서버 구동방식이나 트래픽에 따라 여유 메모리가 다를 수 있으니 여러 케이스에 따라 조회해 보자.

프로세스 별 메모리 사용량 확인

$ top -o %MEM

위 top 명령어로 현재 실행 중인 프로세스를 메모리 사용량으로 정렬해 조회할 수 있다.
어떤 프로세스가 메모리를 많이 쓰고 있는지 한눈에 보여 전체적인 맥락 파악이 가능하다.

메모리 부족 해결책 6가지

메모리 부족 해결에는 여러 가지 방법이 있다. 효율성을 고려하여 먼저 검토하면 좋을 순서대로 정리했다.

1. top 명령어를 통한 프로세스 확인

위에서 언급한 top 명령어로 우선 현재 메모리의 사용 상태를 파악하는 게 중요하다.
불필요한 프로세스가 돌아가고 있는 건 없는지 체크하고 내가 잘 모르는 프로세스가 있는지 확인해 보자.
만약 특정 프로세스가 메모리를 과하게 쓰고 있다면 해당 프로세스를 상세하게 점검해 봐야 한다.

2. 사용하지 않는 캐시 데이터 삭제

레디스 등 불필요한 캐시 데이터가 남아있다면 삭제한다.

3. 애플리케이션 내 사용하지 않는 소스코드 제거

애플리케이션 서버를 운영 중에 있다면 해당 서버가 가장 많은 메모리를 차지할 것이다.
소스코드 중 지금은 사용하지 않는 기능인데 서버 실행 시 포함되는 부분이 있을 수 있다.
나의 경우 Django Server의 사용하지 않는 Admin 및 Router Url을 주석 처리함으로써 메모리를 200M 가량 확보했다.

4. Swap Memory 사용

스왑 메모리(Swap Memory)는 메모리가 부족할 때 사용하는 보조 메모리다.
하드 디스크(HDD)를 마치 메모리(RAM)처럼 사용하는 방식이다.
아무래도 하드 디스크는 메모리에 비해 속도는 느리지만 최악의 상황은 막아주니 설정해 주면 좋다.
스왑 메모리는 특수한 경우를 대비해서 사용하는 비상용 보조 메모리로 볼 수 있다.
만약 스왑 메모리가 자주 사용된다면 정상적인 상황은 아니니 다른 추가적인 해결책이 필요하다.

스왑 메모리 설정 방법은 아래 블로그를 참고했다.
https://sundries-in-myidea.tistory.com/102

5. 메모리 많이 쓰는 코드 리팩토링

만약 평소에는 메모리가 충분한데 특정 기능이 요청될 때 메모리 부족이 생길 수도 있다.
이런 경우는 해당 기능에서 과하게 메모리를 사용하고 있을 확률이 높다.
리팩토링을 하면서 코드 최적화가 필요한 상황이다.

6. EC2 Scale-Up & Scale-Out

마지막 방법이다.
위에 방법들을 모두 시도해 봤지만 메모리가 부족하다면 어쩔 수 없다.
비용이 증가하더라도 사양을 올려야 한다.
스케일업(Scale-Up)을 통해 EC2의 메모리를 증가시키거나, 스케일아웃(Scale-Out)을 통해 컴퓨팅 수를 늘려 트래픽을 분산시킨다.