JWT와 Session의 성능 차이는 어떻게 될까? – 부하테스트 3

JWT와 Session의 성능 차이는 어떻게 될까?

부하테스트 세번째 글로 부하테스트에 대한 정리 및 회고이다.

지금까지의 경과를 바탕으로 결론을 정리해보고 회고를 간단하게 작성해보고자 하였다.

Session vs JWT

표로 다시 정리해보자면 다음과 같다.
전체적으로 세션이 성능면에서 최소 10% ~ 최대 40% 정도 성능에서 이점이 보인다고 이야기 할 수 있다.

에러 발생의 경우에는 세션이 먼저 발생하였긴 하였지만 에러를 제외한 수치에서 이론적으로 세션이 확실히 이점을 보였다.

특히 CPU 사용률 메트릭에서 수치와 그래프의 형태를 확인하였을때 세션이 이점을 보이는 것을 확인할 수 있었다.

물론 테스트가 잘못되었을 수도 있었고 여러 환경적 요인을 고려했을때 다를 수도 있다.

전체적인 회고

간단하게 생각하고 접근했으나 생각보다 고려할 점이 많은 것이 부하테스트이었다. 라는 것이 핵심 회고 인것 같다.

생각보다 고려해야할 요소가 많다.

시나리오 구성

시나리오를 어떻게 구성하는가에 따라 테스트의 내용이 많이 달라질 수 있다.

사용자가 로그인
(1초대기)
메모작성
(3초대기)
메모 수정

이런식으로도 유저 행동기반 테스트도 진행할 수도 있고, 이에 따라 부하강도도 달라질 것이다.
따라서 테스트 구상시 어떠한 시나리오를 테스트해야할지 고민하여 이를 시나리오에 잘 녹여내는 것도 중요하다고 생각했다.

목표 수치를 잘 정하는 것도 중요함

RPS 기준으로 부하를 걸어보니 다른 수치도 눈에 많이 띄었다. RPS는 정상으로 보이나 레이턴시가 매우 길어지는 현상도 나타남
(RPS는 정상으로 보이나 레이턴시 평균값이 4.08s, max값이 1m이 넘어가는 마법)

다양한 메트릭 뿐만아니라 시스템 메트릭, jvm 수치도 확인하며 이에 대한 기준(목표 수치)를 세워 진행해야 하는 것도 중요하다.

웹서버의 설정도 고려 되어야한다.

내가 빼먹은 것도 있고 동일한 조건이여서 굳이 건들 필요가 없다고 생각한 부분인데 웹서버의 설정값도 고민할 필요가 있어보인다.
Tomcat과 같은 웹서버 설정에 따라 받을 수 있는 임계점이 조금식 달라질 수 있는 요소가 있다.
대기 큐의 크기에 따라서 정상 처리가 되고있는 것처럼 보일 수도 있다는 것이다.

초기 : Queue에 쌓이고 있으며 처리가 되는 것처럼 보임
중기 : 레이턴시가 점점 늘어나기 시작
후기 : 요청이 실패하기 시작, 그래프에서 확인됨

임계점을 찾는데 노이즈가 낄 수 있는 요소가 될 수 있지 않을까 생각하였다.

아직 한발 남았다.(보지못한 메트릭도 많다.)

RPS 그래프를 참고하였을때 수치가 크게 요동치는 부분이나 스파이크 형식으로 급락했다가 회복하는 구간이 있다. 해당 부분에 대해서 JVM 내부 메트릭, 즉 Eden, Survivor , Old영역의 메트릭을 참고한다면 RPS변동에 대한 이유를 분석하는 것도 가능하다.

또한 위에서 넘어간 에러 발생의 경우에도 현재 원인으로 톰캣이나 어플리케이션단의 대기큐가 요청으로 들어오는 수보다 작아 발생하는 것으로 생각하는데 해당 부분에 대해서도 톰캣 또는 어플리케이션단의 메트릭을 확인하면 정확한 이유를 확인할 수 있다.

이러한 이유로, 단순 수치 비교에 그치는 것이 아니라 어디를, 어떻게 개선할 것인가를 논의하는 것이 중요하다고 느꼈다.

성능 개선 관점에서의 부하테스트

다음으로 부하테스트의 목적과 관련된 것인데, 바로 개선에 대한 내용이다. 부하테스트 목적이 정해진 수치를 만족하는가 확인하는 것도 있지만, 그보다 성능이 덜나오게된다면 개선할 요소도 도출해야한다.

어떻게 어디를 개선할지에 대해서 이야기하자면 처리량과 응답시간을 먼저 이야기할 필요가 있다.

처리량 : 초당 처리하는 작업의 수
응답시간 : 시스템이 요청을 받고 응답할 때까지의 시간

처리량은 시스템의 구성요소 중 가장 처리량이 낮은 부분으로 계산할 수 있다.즉 위의 예시에서 처리량이 가장 낮은 DB가 기준으로 전체 처리량은 100RPS이다. 응답시간은 처리되는 모든 시간을 더하여 계산되며 예시의 전체 응답시간은 750ms이다.

위의 데이터를 바탕으로 개선할 구간(병목구간)을 판단할 수 있는데 처리량 기준으로 개선하고자 하면 가장 낮은 처리량을 가지고 있는 구간을 개선하면 병목 구간이 이동하게 되어 처리량이 늘어나게 된다. 다른 부분을 개선할 경우 전체적인 성능 개선이 실패하게 된다. 응답 시간은 어떤 부분을 개선하더라도 총 시스템 응답 시간에 영향을 주게되나 가장 긴 부분부터 어떻게 개선할지 고민한다.

다시 현재까지 진행한 테스트로 돌아와 비교하면 병목구간을 확인하기 위한 구간별 메트릭 파악이 부족한 상태라고 생각한다. 간단하게 AOP 활용하거나 DB메트릭등 구간별 수집을 진행하여 개선할 요소가 있다고 생각한다.

마지막은 새로운 시작

지금까지 세션과 JWT방식을 비교해보는 여정을 마쳤다.

아직 보지 못한 메트릭이 많고, 병목 구간을 정밀하게 분석하기 위한 데이터 수집도 부족한 상태다. AOP나 DB 쿼리 로그, 시스템 내부의 JVM 메트릭 등을 보다 세밀하게 수집하여 병목 구간을 식별하고, 해당 구간을 중심으로 개선 작업을 반복하면서 시스템의 성능을 점진적으로 끌어올리는 것이 앞으로 해봐야할 숙제가 되지않을까 싶다.

이번 테스트를 통해 단순 수치 비교를 넘어서 부하 테스트 자체의 설계, 환경 변수, 메트릭 수집의 중요성 등을 폭넓게 체감할 수 있었다. 다음 단계에서는 더 체계적인 관측과 개선을 통해, 실서비스 환경에서 의미 있는 결과를 도출해보고 싶다.