무중단 배포 시 AWS EC2 프리티어 CPU 사용량 100% 초과

무중단 배포 도입 과정과 배포 전략에 관한 내용은

Nginx , Docker, Github Actions로 무중단배포 진행 를 참고하면 된다.

 

1. 문제 원인 파악

현재 사용중인 서버는 AWS EC2 t2.micro(프리티어)이고, 메모리는 1GB이다. 

배포 전략으로 선택한 Green/Blue 는 green과 blue WAS가 동시에 실행되는 시간이 발생하며 이때 RAM  프리티어 한도인 1GB를 넘어가게 되고, 이로 인해 서버의 작동 불가로 이어졌다.

 

그 이유는

1. 모든 메모리가 사용되면 시스템은 새로운 프로세스나 기존 프로세스를 위한 충분한 메모리를 확보할 수 없게 된다.

2. 이로 인해 여러 프로세스가 제한된 메모리 자원을 놓고 경쟁하게 만들고,

3. 이러한 리소스 경합은 CPU가 효율적으로 프로세스를 처리하지 못하게 하며,

4. CPU는 자원을 효율적으로 관리하기 위한 추가적인 오버헤드를 발생시킨다.

이러한 이유로 메모리가 한도를 초과하는 순간부터 CPU 사용량이 점점 올라갔고, 사용률이 100%를 달성하는 순간, 결국 서버가 아예 멈추는 문제가 발생하였다.

 

사실 이 문제는 이전에도 한 번 겪은 문제였다. 모니터링 도입 시에 Pinpoint를 써보기 위해 ec2 서버에 설치했다가 cpu 사용량을 100을 찍고 서버가 멈췄었다.

그 당시에는 pinpoint까지 설치하기엔 프리티어로는 한계가 있구나 하면서 ec2 서버의 낮은 사양을 핑계로 새로 EC2 서버를 개설하여 지나갔었다.

 

2. 해결 방법

하지만 이번에 동일한 문제를 겪고, 해결방법을 자세히 찾아보게 되었다.

 

나와 같은 문제를 겪은 사람들이 상당히 많았고,

결론부터 말하자면 SWAP 공간을 사용함으로써 해결할 수 있었다.

 

SWAP 공간은 디스크에 위치해 있고, 메모리가 부족할 때 OS가 임시로 데이터를 보관하는 공간이다. 

이를 ec2 서버에 확보 해줌으로써, 메모리가 용량을 초과할 때 임시로 데이터를 디스크에 저장하고 필요할 때 다시 불러오는 것이 가능해져서, 프리티어 한도인 1GB를 넘어도 서버가 죽지 않게 된다.

하지만 Disk I/O작업은 매우 느린 속도를 가지고 있어서, 성능은 어느 정도 포기해야한다. 

실무 환경에서는 RAM을 1GB로 하는 프리티어를 사용하지 않을 것이라 판단했기에 당장의 성능보다는

배포 시 Downtime 시간을 줄이기 위해서 디스크 스왑영역을 사용한 무중단배포를 진행하는 것을 택하였다.

 

일반적으로 권장 스왑 공간은 위와 같다. (정해진 것은 아니고 유동적으로 하되 참고만 하면 된다.)

• 그 이유는 RAM 2GB이하 같은 경우에는 물리적 메모리가 부족할 확률이 높기 때문에 시스템을 안정적으로 운영하기 위해서 2배 정도로 잡고
• 2GB 초과, 32GB 미만은 시스템이 충분한 메모리를 가지고 있는 듯 하면서도 혹시 모를 메모리 초과 예방과 불필요한 스왑 공간 낭비를 제거하기 위해 4GB + (RAM - 2GB)로 잡는다.
• 32GB 이상은, 일반적으로 메모리 집약적인 작업을 처리하는 시스템이다. RAM과 동일한 크기의 스왑 공간을 설정하여 메모리 부족 상황에서 충분한 버퍼를 제공한다.
• 추가적으로 스왑 공간이 32MB 미만이 되지 않아야 하는 이유는 대부분의 OS와 필수 시스템 서비스는 기본적으로 32MB의 최소 스왑 공간을 요구하기 때문이다.

 

구체적인 스왑 공간 생성 방법은 AWS 공식 문서에 자세하게 나와있다.

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

스왑 파일을 사용하여 Amazon EC2 인스턴스에서 메모리를 스왑 스페이스로 할당합니다.