💡 gatling 실험 결과는 📊 결과의 상세내용에서 아래와 같이 직접 확인하실 수 있습니다.
1️⃣ 테스트 시나리오
2️⃣ 아키텍처
3️⃣ 컨테이너 스펙
4️⃣ 기술 스택
5️⃣ 결과
6️⃣ 정리
7️⃣ 얻게 된 것
8️⃣ 관련 링크
1️⃣ 로그인 시나리오
유저는 로그인을 시도한다.
2️⃣ 단순 요청 시나리오
유저는 로그인을 시도한다.
유저는 비즈니스 로직을 호출한다.(여기서는 단순 문자열만을 반환하는 로직을 비즈니스 로직이라 가정하였습니다.)
스프링의 인터셉터를 이용하여 구현하였을때의 아키텍처
스프링 시큐리티의 세션과 jwt를 이용하여 구현하였을때의 아키텍처
- Ram 1GB
- Cpu 1Core
- Jdk17
- Spring Boot 3
- Redis
- MariaDB(테스트 환경)
- H2(개발 환경)
- Docker
- Prometheus
- Grafana
- Gatling
| 시나리오 | 구현 방법 | CPU 사용량 | JVM 사용량(1.5GB 기준) | DB 커넥션(최대 10) | 톰캣 스레드 | 요청당 평균 응답속도 | 서버가 감당할 수 있는 최대 요청수 | 요청 처리 용량(Throughput) |
|---|---|---|---|---|---|---|---|---|
| 로그인 시나리오 | 인터셉터 | 약 1% | 346MB | 100% | 100% | 5335ms | 7129 | 1336.2 |
| 시큐리티(세션) | 약 1% | 190MB | 22.5% | 93.8% | 13132ms | 194 | 14.7 | |
| 시큐리티(jwt) | 약 0.93% | 261.8MB | 42% | 64.1% | 1781ms | 3155 | 1771.4 | |
| 단순 요청 시나리오 | 인터셉터 | 약 1% | 365.6MB | 약 98% | 98% | 5126ms | 9629 | 1878.4 |
| 시큐리티(세션) | 약 1% | 213MB | 20% | 98.25% | 9418ms | 216 | 22.9 | |
| 시큐리티(jwt) | 약 1% | 365MB | 96% | 100% | 6535ms | 9990 | 1528.6 |
상세내용
펼치기/접기
| 시나리오 | 구현 방법 | 첫번째 시도 | 두번째 시도 | 세번째 시도 | 네번째 시도 | 다섯번째 시도 |
|---|---|---|---|---|---|---|
| 로그인 시나리오 | 인터셉터 | 링크 | 링크 | 링크 | 링크 | 링크 |
| 시큐리티(세션) | 링크 | 링크 | 링크 | 링크 | 링크 | |
| 시큐리티(jwt) | 링크 | 링크 | 링크 | 링크 | 링크 | |
| 단순 요청 시나리오 | 인터셉터 | 링크 | 링크 | 링크 | 링크 | 링크 |
| 시큐리티(세션) | 링크 | 링크 | 링크 | 링크 | 링크 | |
| 시큐리티(jwt) | 링크 | 링크 | 링크 | 링크 | 링크 |
- 구현 방식에 따라 응답속도, 감당할 수 있는 최대 요청수의 큰 차이가 존재하는 것을 확인할 수 있었습니다.
- jwt를 이용한 구현 방식이 session에 비해 최대 요청수와 평균 응답속도, 요청 처리 용량을 압도하는 것을 확인할 수 있었습니다.
- jwt를 사용하더라도 토큰 발급은 컨트롤러에서 하고 인증을 시큐리티의 사용자 정의 필터에서 한다면 , 인터셉터와 비슷한 수준의, 압도적인 성능을 뽑아낼 수 있음을 확인할 수 있었고 요청대비 리소스를 아낄 수 있음을 확인할 수 있었습니다.
- security의 session방식보다 security의 jwt방식이 로그인만 하는 상황에선 약 120배 , 로그인과 단순 요청을 하는 상황에선 약 60배 가량 더 높은 Throughput을 확인할 수 있었습니다.
- 로그인 방식별 장단점을 직접 데이터로 확인하며 비교할 수 있었습니다.
- 상황에 맞는 로그인 방식을 저만의 기준을 통해 선택할 수 있게 되었습니다.
