앞선 글에서 세운 전략을 검증하기 위해 톰캣 스레드 개수와 DB Connection Pool 개수를 20부터 50까지 늘려가며 스트레스 테스트를 진행했다.
이때 운영 가능한 시스템인지를 판단하기 위해 과부하 임계값을 설정했다(기준은 google 검색 결과를 바탕으로 잡았다).
운영 가용성 판단 기준 (2 vCPU 기준)
- CPU Usage: 70% 초과 시 과부하 (돌발 트래픽 대응을 위한 여유 자원 확보)
- Load Average: 4.0 초과 시 과부하 (코어 당 대기열 2배수 제한)
테스트 결과, 성능과 시스템 안정성 사이에 트레이드오프가 나타났다. 다음 표는 T(Tomcat max-thread) 와 H(HikariCP max-connection)을 기준으로 한, warm 테스트 결과에 대한 주요 지표이다.
| 설정 (T/H) | 테스트 상태 | TPS | CPU Usage (Max) | Load Avg (Max) |
|---|---|---|---|---|
| 20 / 20 | Warm-up | 335 | 60 % | 2.49 |
| 30 / 30 | Warm-up | 466 | 69 % | 4.92 |
| 40 / 40 | Warm-up | 848 | 94 % | 13.0 |
| 50 / 50 | Warm-up | 996 | 99 % | 19.6 |
50/50
위 결과의 50/50 전략은 임계점을 상당히 많이 초과했다.
996 TPS라는 극한의 성능을 보여줬지만, Load Average 19.6는 2개의 CPU 코어가 감당하기에는 너무 불안정한 상태이다.
1:1 매핑으로 DB 대기는 없앴지만, 2개의 CPU 코어가 runnable 스레드를 스위칭하는 비용(Context Switching)을 감당하지 못해 시스템이 마비 직전까지 간 것으로 보인다. 이 상태가 지속된다면 서비스에 장애가 날 확률이 매우매우 높아진다고 판단해, 해당 전략은 폐기하기로 결정했다.