영어회화 스터디 서비스를 개발하면서 부하 테스트를 위해 클라우드 환경에 필요한 서비스들을 컨테이너 환경으로 실행했다.
클라우드 서비스는 Naver cloud platform의 서비스들을 이용했다.
🛠️ 테스트 환경 & 시나리오
- 서버 스펙
- CPU -> 2EA
- Memory -> 8GB
- nGrinder로 테스트
- 전체 모임 조회 API 호출 -> 50만 건의 데이터
- Vuser 1 부터 늘려가며 테스트
- Run count는 1로 고정
📌 Vuser 1로 테스트
50만 건의 데이터를 조회하는 데 몇 번 테스트한 결과 평균적으로 7,000ms 정도가 걸렸다.
📌 Vuser 4로 테스트
동일하게 몇 번 테스트 해본 결과 평균적으로 29,000ms 정도가 걸렸다.
📌 Vuser 10으로 테스트
Vuser를 10으로 테스트하니 Ngrinder로 실행한 테스트가 실패했다.
🧑💻 원인 분석
클라우드 로그를 확인해보니 힙 메모리 영역에 OOM이 발생한 것을 확인할 수 있었다.
DB로부터 가져오는 데이터는 Java 객체로 변환이 되는데, 이는 JVM의 힙 메모리 영역에 적재가 된다.
50만 건의 데이터를 10명의 유저가 요청하게 되면서 한 번에 너무 많은 양의 데이터가 힙 메모리에 적재되면서 OOM을 발생시킨 것이다.
🧑💻 고찰
vuser를 10으로 했을 때, OOM이 발생한 것을 보고 vuser를 6으로 하고 테스트를 실행해봤는데 OOM이 동일하게 발생한 것을 확인할 수 있었다.
생각해보니 존재하는 데이터를 모두 가져오는 API를 호출하는 것 자체가 OOM이 발생할 수 밖에 없는 상황이었다.
그리고, 실무에서는 모든 데이터를 조회하는 findAll()
메서드를 사용하면 안 된다고 한다. 생각해보면 대규모 서비스에서 findAll()
메서드를 하면 말도 안 되는 것이었다 🤔
6명의 유저가 데이터를 조회했는데 터지는 서비스라니 ㅎㅎ…
이를 해결하기 위해 offset과 pageSize를 정해 데이터를 일부씩 가져와 메모리에 적재시키는 방식으로 수정하여 테스트를 해보고자 했다.
offset과 pageSize를 조절해 테스트를 하니 에러 없이 정상적으로 테스트를 통과하는 것을 확인할 수 있었는데, 이에 대해서는 다음 포스팅에서 이야기해보겠다.
'TIL' 카테고리의 다른 글
서버 진화 ~~~ (서버 스케일업) (0) | 2025.01.07 |
---|---|
[hikaricp connection is not available] - 테이블은 많지만 회전율은 낮은.. (0) | 2025.01.07 |
Subnet 이해하기 (0) | 2024.12.21 |
VPC 이해하기 (1) | 2024.12.14 |
Stream API 이해하기 (0) | 2024.11.24 |