📚 서론
지난주 부터 스프링부트 JAVA 프로젝트와 리엑트 프로젝트를 클론하고 deploy 하여 서버로 사용중이던 EC2 에 문제가 발생했다. 처음 그냥 접속하면 괜찮은데 build 나 test 를 하려고 하면 아래 이미지와 같이 로딩이 엄청 길어지는 문제가 생긴 것이다. 이러면 중단도 불가능하고 이 지연문제가 자연스레 해결되기까지 ec2 에 접속도 할 수 없다. 다행히 비슷한 사례를 찾아서 이를 해결해보는 과정을 정리하고자 한다.
ec2 인스턴스 자체를 재시작하면 된다고 한다
📘 과정
실제로 나도 용량 문제가 먼저 떠올랐다. 한이음 측에서 클라우드 서버 비용을 지원받아 사용중이었으나 이전에 AWS 를 처음 사용해볼때 개인적으로 학습후 과금요소를 모두 종료한 줄 알았는데 인스턴스, 탄력적 IP, EBS 가 켜져있었고 그 결과 한달간의 서버 비용이 나도 모르는 사이 부과되어 약 40여만원의 청구서가 날라온 적이 있었다. 3주정도의 시간동안 AWS 측의 서비스 지원팀과 메일을 주고받아 다행히 환불을 받을 수 있었으나 그 당시 기억이 있어 과금이 될만한 요지가 될 수 있는 부분에 해당하는 용량을 되도록이면 줄여 최소한으로 선택했었다.
📗 모니터링 - CloudWatch 경보 관리
아래로 내리다 보면 CPU 사용률이 보인다. 역시 배포를 하려던 8/2 ~ 8/3 사이에 CPU 사용률이 하늘을 뚫고 빨간 영역을 치솟았다. 용량이 그렇게 많나 싶기도 하지만 프리티어 t2.micro 의 메모리가 고작 1GB라서 그런것 같기도 하다.
그런데 알고보니 저 옆의 숫자가 % 단위로 고작 6.97% CPU 를 사용했다는 표시였다.
free : 메모리 확인
Swap : 스왑 영역은 메모리가 부족할 때 사용되는 보조 저장소, 메모리가 가득 차서 더 이상 데이터를 저장할 공간이 없을때 사용하지 않는 메모리 내용을 스왑 영역에 임시로 저장하고 필요할 때 다시 꺼내서 사용한다.
Mem : 현재 사용중인 실제 메모리 양
음.. 가설로는 CPU 사용률이 100% 로 치솟고 CPU 크레딧 사용량이 소진되어 속도가 됭장히 느려졌으리라 생각했는데 그정도는 아니었던 것 같다.
지금 사용중인 인스턴스가 t2.micro 인스턴스이니 크레딧이 모두 소진되어서 그런 것도 아니다.
Java 프로젝트는 빌드에 gradle 을 사용중인데 이런 경우를 찾아보니 스왑파일을 사용하여 메모리를 할당하는 방법으로 해결을 한 것으로 보인다.
t2.micro 가 1GB 이니 스왑 메모리는 두 배의 메모리인 2GB를 할당해보자
다음은 AWS 의 swap 메모리 생성 과정을 안내하는 docs 의 내용을 따라해보는 과정이다. 링크
2GB swap file 생성
$ sudo dd if=/dev/zero of=/swapfile bs=128M count=16
스왑 파일의 읽기, 쓰기 권한 업데이트
- 파일 소유자에게 읽기(4), 쓰기(2) 권한을 부여해서 600 이다.
sudo chmod 600 /swapfile리눅스 스왑 영역 설정
sudo mkswap /swapfile
스왑 공간에 스왑 파일을 추가하여 즉시 사용
sudo swapon /swapfile프로시저의 상태 확인
sudo swapon -s
vi 편집기로 해당 파일을 열고 다음 내용 추가
sudo vi /etc/fstab/swapfile swap swap defaults 0 0
📗 swap 메모리 생성 결과
스왑 메모리가 정상적으로 생성되었다.
그럼 이제 배포되해보자. 참고로 java 프로젝트는 GitLab 을 통한 CI/CD 를 구축하고자 .gitlab-ci.yml 을 생성해 main 이 merge 되면 CI 까지 build, test 가 자동화되도록 설정했지만 CD 에 해당하는 deploy 에서 GitLab 을 통해 ssh 의 키페어를 전달하는 부분이 해결되지 않아서 지금은 ec2 에 직접 접속해서 미리 만들어둔 배포용 셸 스크립트인 deploy.sh 를 실행해줘야 한다.
미쳤다.. 10초 걸렸나 바로 배포되었다.
이번에 이 지연이 발생하는 문제도 있었는데 테스트코드의 도움을 크게 받았다.
무슨 말이냐면 공모전에서 협업시 팀원분께 backend API에서 POST method 를 사용중인데 @RequestParams 를 쓰고 있어서 @RequestBody 를 사용하는 것으로 변경해달라고 요청했다. 그러면서 로컬에서조차 서버가 실행이 안되는 문제가 발생했는데 미리 짜뒀던 테스트코드를 보고 문제가 발생한 지점을 바로 찾을 수 있었다.
지금 백엔드, 프론트엔드, ec2 서버 관리와 CI/CD 자동화 부분에 작업을 하느라 이곳저곳 돌아다녀서 백엔드에서 직접 만들었던 회원가입과 관련된 API 에만 테스트코드를 짜둔게 아쉽다. 나머지 API 들도 TDD 원칙에 따라 테스트코드를 먼저 짜고 API 개발을 하고 싶으나 현실적으로 초심자 개발자에게 어려운 것 같다. API 를 돌아가게 만드는 것만으로도 벅찰때가 많다... 그래도 이번에 문제를 빠르게 해결할 수 있게 하고 나 역시 내가 짰던 API 만큼은 테스트코드를 짜뒀기에 무슨 문제가 생겨도 이 부분만큼은 자신감을 갖고 원인을 찾을 수 있었다.
📔 레퍼런스
docs
AWS - create swap memeory
blog
shawnhansh - AWS EC2 램 늘리기 (swap)
