배포 과정에서 있었던 일들

메모리 부족으로 인한 장애

ec2엔 다양한 스펙을 설정할 수 있다.

프로젝트 배포 전이었고 테스트 단계였기에 당연히 t2.small로 잡아두었다. 하지만 서버를 실행한 뒤 시간이 지나면 어느샌가 ec2가 뻗어있었다. 이유는 메모리 문제였다. 현재 사용중인 메모리 양을 확인해 봤더니 거의 모든 메모리를 잡아먹고 있었다.

하지만 그렇게 크지도 않은 서버 하나를 실행했다고 1GB 의 메모리를 다 잡아먹는게 의아했고 여러 사람들한테 물어봤지만 로직이 문제인거 아니냐는 답변을 많이 듣게 됐다. 

 

 

메모리 누수 의심

메모리 누수가 되는 부분이 있는가 해서 JAVA GC에 대해 알아보기도 했지만 내 상황에 해당하진 않았다. GC에 소멸되지 않는 여러 상황들이 많았지만 그 중 내가 실수할 수도 있겠다 하는 부분은 Map 부분이었다.  Map을 사용할 때 Key값으로 커스텀한 객체를 사용할 때 Java에서 제공하는 GC에 소멸되지 않는다고 한다. 또한 Map에는 강력한 참조가 있어서, 내부 객체가 사용되지 않을 때도 GC 대상이 되지 않는다. 이를 해결하기 위해선 WeakHashMap을 사용할 수 있다. 

 

 

[ec2 JVM 메모리 누수 체크]

https://dgjinsu.tistory.com/24

[Colony] JAVA 메모리 누수 체크 및 JVM 모니터링

 

 

메모리를 많이 잡아먹었던 이유

colony 프로젝트는 프론트 개발자 2명, 백엔드 개발자 2명이서 진행했지만 나 제외 모든 인원이 프로젝트가 처음이었기에 리액트를 사용하는덴 무리가 있었다. 리액트는 나도 잘 모르기에 도움을 줄 수 없었다. 그래서 이미 사용해본 타임리프를 사용해 view를 구성하였다. 결국 서버에 view 데이터까지 전부 올라가게 되고 자연스럽게 무거워질 수 밖에 없었다. 정말 메모리 문제가 맞는지 확인하기 위해서 swap메모리를 잡고 며칠 지켜보았다. 스왑메모리를 잡아두다보니 느리긴 했지만 더이상 뻗진 않았다.

 

정리하자면 t2.small의 1G의 RAM은 view 까지 갖고 있는 서버를 견디지 못 했던 것이었다.

 

 

이미지 리소스 로딩 속도 개선

 

로직적으로 성능을 개선할 수 있는 부분을 최대한 찾아봤다. JPA 쿼리 같은 부분은 로직을 하나하나 따라가며 예상치 못한 쿼리가 발생하지 않도록 꼼꼼히 살폈기에 문제 없었다. 하지만 생각지도 못 했던 부분에서 성능개선을 할 수 있었다.

질문 상세 페이지를 로딩할 때 리소스 요청을 살펴보았는데, 다른 요청들에 비해 static에 저장해뒀던 이미지를 가져오는데 많은 시간이 들었다. 정적 이미지에 대해서도 s3 bucket에 넣어 이미지를 가져오니 속도가 눈에 뛰게 개선됐다.

 

 

추가로 cloud front 란 기술에 대해 알게되었다. CloudFront는 AWS에서 제공하는 CDN 서비스다. 캐싱을 통해 사용자에게 좀 더 빠른 전송 속도를 제공함을 목적으로 한다. CloudFront는 전 세계 이곳저곳에 Edge Server(Location)을 두고 Client에 가장 가까운 Edge Server를 찾아 Latency를 최소화시켜 빠른 데이터를 제공한다. 여기서 Latency 는 사용자가 본 처리 시간이다. 

하지만 colony 프로젝트엔 정적 이미지를 많이 사용하지 않았기에 오버스펙이라 생각되어 배제하였다. 

 

 

부하테스트

부하테스트란 임계값 한게에 도달할 때까지 시스템의 부하를 지속적으로 꾸준히 증가시켜 시스템을 테스트하는 것이다. 부하 테스트 툴로는 Jmeter을 사용하였다. 

 

사실 동아리에서 커뮤니티 사이트로 사용할 목적이었기에 사실 부하테스트까진 큰 의미 없다 생각했다. 그냥 2GB (t4.small)로 스펙 잡아두고 운영해도 되는지 테스트 하기 위한 목적이 컸다.

초당 50건의 요청이 있을 때 응답까지 평균 2초가량 소모되는걸 확인했고 t4.small로 결정했다. t4.small을 사용하게되면 한달에 17000원 정도의 요금이 나왔다.