금일, 대규모 트래픽 상황을 가정하여 약 7,000건의 요청을 1초동안 요청하는 것으로
제이미터 부하테스트를 진행해보았으나 계속 에러율이 30~50%에 달하게 되었다.
문제가 무엇일지에 대해 계속 고민해보며 아래에 있는 사항들을 진행해보았다.
> EC2 서버 Scale-up
> EC2 서버 Auto-Scaling + ALB (Application Load Balancing)
그런데도 에러가 20~30% 발생한다..
혹시몰라 약 3,000건 요청으로 낮은 성능의 EC2(ubuntu t2.micro) 1대를 체크해보니,
CPU부하%는 30%에 불과했으나, 에러율은 이전과 마찬가지로 20~30%가 발생했다.
뭔가 더 근본적인 이유가 있는 상황이였다.
그래서 더 파 본 결과, 아래와 같은 현상을 발견하였다.
> DB 부하율 문제없음
> DB 커넥션 수 낮은 수준으로 진행
현재 사용하고 있는 RDS는 2.micro 모델인데, 최대 연결할 수 있는 커넥션의 수는 아래와 같다.
아래는 서버가 동작되는 방식에 대한 도식인데, 위 사항을 대입해보면 무엇이 문제인지 어느정도 유추해볼 수 있게된 것 같다.
내가 생각하기엔 아무래도 DB의 최대 커넥션 풀이 적어서인 것이라고 생각한다.
대규모 요청이 있을 시, 서버 성능이 아무리 좋아도 DB 성능이 그 트래픽을 받쳐주지 못하면 병목 현상이 발생하니 위와 같은 문제가 발생했을 것이라고 생각한다.
그래서 현재 DB를 스케일업시키는 방향으로 해당 문제를 해결해보려 한다.
이따 아침에 바로 도입해본 뒤, 같은 조건으로 부하테스트를 진행해서 이 생각이 맞는지 입증해봐야겠다.
수없이 많은 테스트로 인해서 매우 고단하고 힘든 하루였다.
그치만 꼭 해결하여 성취감을 느껴보고 싶다.
오늘도 고생한 내 자신에게 칭찬해주자!
프로젝트를 같이 하고 있는 팀원들에게도 감사함을 남긴다.
'★ 프로젝트 + 트러블 슈팅 ★' 카테고리의 다른 글
2022.12.10 TIL (PC 성능에 따른 Jmeter 부하테스트 결과값 상이??) (0) | 2022.12.10 |
---|---|
2022.12.09 TIL (tomcat 서버설정) (0) | 2022.12.09 |
[JAVA] Spring @Scheduled (1) | 2022.11.24 |
Gradle build 오류처리 (0) | 2022.11.21 |
동시성 제어문제 트러블슈팅 2 (0) | 2022.11.18 |
댓글