우기의 알 블로그 저자 한승욱이라고 합니다.
스스로 알을 깨고 나오는 새처럼
언젠가 알을 깨고 온전한 나 자신이 되었을 때, 그때를 기다리며 제 속에서 솟아 나오는 것을 글로써 표현하고자 합니다.
'개발 기술블로그'를 위주로 저 한승욱의 다양한 관심사, 생각, 철학 등을 포스팅합니다.
현재 본인의 경우 테스트 서버용으로 AWS에서 EC2 t3a.small 인스턴스를 구동하고 있다.
CPU 2코어, 메모리 2GB 정도면 테스트 배포를 구성하기에 충분할 것이라고 생각했다.
Mysql
Express
React
Nginx-proxy
Letsencrypt
대략 이정도의 컨테이너를 띄우고자 했다.
구체적으로 각 컨테이너들이 리소스를 얼마나 먹는지 계산한 뒤, 이를 토대로 인스턴스 유형을 정하기보다는, 감으로 때려박은 경향이 있다.
역시나 내 감은 틀렸었다.
Mysql, Express 2개만 띄웠을 때는 크게 문제 없었지만 나머지 컨테이너도 함께 띄운 순간, 갑자기 서버가 먹통이 되어 버렸다.
이후에 다시 ssh 접속했을 때는 timeout.....
예전에도 이러한 상황을 겪어봤기에, 인스턴스 리소스 문제 라는 것을 단번에 알아차렸다.
100% 확신하긴 했지만, 근거가 없기 전까지는 가설이기에, 해당 가설을 검증해보았다.
검증
우선적으로 시스템 로그에 분명히 해당 정보가 나와있을 것이라는 생각으로 EC2의 시스템 로그 확인법을 찾아보았다.
인스턴스에 직접 들어가서 /var/log 에 있는 로그들도 찍어보고 했지만, 보다 더 간단한 방법이 있었다.
내 인스턴스에서
작업 → 모니터링 및 문제 해결 → 시스템 로그 가져오기
해당 버튼을 클릭하기만 하면 되는 것이었다.
메모리 부족 오류
인스턴스의 시스템 로그에 ‘Out of memory: kill process(메모리 부족: 프로세스 중지)’ 오류가 표시되면 인스턴스의 메모리가 소진된 것입니다. 메모리가 모두 소진되면 메모리가 부족하여 커널이 실행되지 않으며 메모리를 확보하기 위해 다른 프로세스가 종료됩니다.
EC2가 갑자기 멈춘다면?(swap 메모리)
배경
현재 본인의 경우 테스트 서버용으로 AWS에서 EC2 t3a.small 인스턴스를 구동하고 있다.
CPU 2코어, 메모리 2GB 정도면 테스트 배포를 구성하기에 충분할 것이라고 생각했다.
대략 이정도의 컨테이너를 띄우고자 했다.
구체적으로 각 컨테이너들이 리소스를 얼마나 먹는지 계산한 뒤, 이를 토대로 인스턴스 유형을 정하기보다는, 감으로 때려박은 경향이 있다.
역시나 내 감은 틀렸었다.
Mysql, Express 2개만 띄웠을 때는 크게 문제 없었지만 나머지 컨테이너도 함께 띄운 순간, 갑자기 서버가 먹통이 되어 버렸다.
이후에 다시 ssh 접속했을 때는 timeout.....
예전에도 이러한 상황을 겪어봤기에,
인스턴스 리소스 문제라는 것을 단번에 알아차렸다.100% 확신하긴 했지만, 근거가 없기 전까지는 가설이기에, 해당 가설을 검증해보았다.
검증
우선적으로 시스템 로그에 분명히 해당 정보가 나와있을 것이라는 생각으로 EC2의 시스템 로그 확인법을 찾아보았다.
인스턴스에 직접 들어가서 /var/log 에 있는 로그들도 찍어보고 했지만, 보다 더 간단한 방법이 있었다.
내 인스턴스에서
해당 버튼을 클릭하기만 하면 되는 것이었다.
메모리 부족 오류
참고:
특히 docker 컨테이너는 마운트된 메모리를 이용하게 되는데,우선 인스턴스를 중지하고 다시 시작한 후에, 아래의 명령어를 입력해보았다.
역시는 역시 Swap 메모리가 0이다.
스왑이란 쉽게 말하면 내 하드디스크(또는 ssd)의 공간을 빌려서 가상 메모리로 사용하는 것이다.
사실 스왑 파티션이라는 것은 옛날에 물리적인 메모리가 부족하던 시절에 하드 디스크를 메모리처럼 사용하려고 만들어진 것이라고 한다.
(요새 시대에는 메모리가 넘쳐난다... 이 글을 작성하는 내 로컬 머신도 16GB, 32GB이기에...)
하지만 AWS 인스턴스에는 프로덕션 배포가 아닌 이상 그만큼의 고성능 컴퓨터를 빌릴 수 없기에, 다시 과거로 회귀하게 되었다.
AWS 공식 문서 기준으로 메모리 크기에 따라 스왑 메모리의 크기를 아래와 같이 권장하고 있다.
본인의 인스턴스의 RAM은 2GB이고 첫번째 로우를 기준으로 하여 스왑을 4GB 잡아주기로 결정했다.
참고:
해결
전체적으로 아래의 AWS 공식 문서를 참고했다.
참고:
1)
dd 명령을 사용하여 루트 파일 시스템에 스왑 파일을 생성한다.
bs는 블록 크기, count는 블록 수 인데, 이 두 수를 곱한 값으로 스왑 파일의 크기를 결정한다.
당연하게도 지정한 블록 크기는 내 인스턴스에서 사용 가능한 메모리보다 작아야 한다.
여기서 스왑 파일은 4GB(128MB x 32) 이고, 해당 예제가 내 현재 인스턴스의 상황에 적절하다고 생각해서 그대로 진행했다.
2)
스왑 파일의 읽기 및 쓰기 권한을 업데이트한다.
600 = rw———-
3)
리눅스 스왑 영역을 설정한다.
4)
스왑 공간에 스왑 파일을 추가하여 스왑 파일을 즉시 사용할 수 있도록 한다.
5)
위에서 진행한 절차가 성공했는지 확인한다.
6)
/etc/fstab 파일을 편집하여 부팅 시 스왑 파일을 활성화할 수 있게 한다.
(vi 입력기 안에서)
파일 끝에 다음 줄을 새로 추가하고 파일을 저장한다.
이때 저장할때는 esc → :wq! 해주면 된다.
결과
이제 스왑 메모리가 할당된 것을 확인 가능하다!
컨테이너를 1개 더 띄우기까지 했는데도 딱히 멈춤 없이 잘 돌아갔다! (하지만 cpu 스펙업은 해줘야할듯....)
'기술개발 > AWS' 카테고리의 다른 글