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

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

부하테스트 두번째 글로 부하테스트를 어떻게 진행했는지 말해보고자 한다.
진행하며 어떠한 문제점이 있었고 어떻게 개선하였는지 작성하고자 하였다.

단일 K6 부하테스트 진행
K6 + InfluxDB + Grafana / 시계열 데이터 분석
K6 + telegraf + InfluxDb + Grafana / 시스템 메트릭 추가

이러한 순서로 진행하였다.

1. 단일 K6 부하테스트 진행

처음으로 진행한 것은 K6를 설치하고 바로 부하 테스트를 진행해본 것이였다.
현재 시스템에서 어느정도 버틸 수 있는지 모르는 것도 있었고 부하테스트에 대한 감을 잡지 못한 상태여서 일단 먼저 부하를 걸어보았다.

vuser : 10 ~ 5000 vus
시간 : 30s ~ 10m
테스트 유형 : 일정 vuser로 시작 또는 0부터 지정한 vuser까지 상승

조건을 계속해서 바꿔가면서 부하를 걸어보는 과정을 거쳤다.

다음은 진행했던 여러 테스트 중 하나의 k6 결과물이다.

█ TOTAL RESULTS 
  checks_total......: 504789 1551.230026/s
  checks_succeeded..: 99.93% 504462 out of 504789
  checks_failed......: 0.06%  327 out of 504789

  ✗ status is 200
    ↳  99% — ✓ 504462 / ✗ 327

  HTTP
  http_req_duration.............: avg=524.24ms min=0s       med=128.67ms max=3.18s  p(90)=1.84s p(95)=2.29s
    { expected_response:true }..: avg=524.58ms min=646.58µs med=129.04ms max=3.18s  p(90)=1.84s p(95)=2.29s
  http_req_failed...............: 0.06%  327 out of 504789
  http_reqs.....................: 504789 1551.230026/s

  EXECUTION
  iteration_duration............: avg=1.54s    min=1s       med=1.13s    max=31.02s p(90)=2.84s p(95)=3.3s 
  iterations....................: 504789 1551.230026/s
  vus...........................: 5      min=5             max=4993
  vus_max.......................: 5000   min=5000          max=5000

  NETWORK
  data_received.................: 237 MB 728 kB/s
  data_sent.....................: 191 MB 588 kB/s

정리하면 다음과 같다.

504462 요청 성공 / 327 요청 실패, 실패율 0.06%
평균 처리시간 524.24ms
p95 처리시간(95%를 포함하는 처리 시간) 2.29s

최대 vuser 5000까지 진행해 보았는데 계속해서 수치를 높혀 진행해도 처리가 되긴 하였다.
다만 p95값이 너무 크게 나오고 실패율이 낮긴하지만 실패가 발생하였다.

vuser 5000이면 RPS 5000이 나온다는 것인데 너무 수치가 높게 나와 무엇인가 잘못되었다고 생각하였다. (사실 처리가 가능한 시스템이였다...)

결론적으로 다음으로 개선이 필요하다고 생각하였다.

테스트 유형을 정하고 진행하자.
내가 필요한 테스트는 무엇일까?라는 생각이 들어 테스트에 대해 찾아보았다.
-> 일정 vuser을 한번에 진행하는 것이 아닌 점차 증가시키는 임계점 테스트 진행
K6 결과물만으로는 원하는 결과를 파악하기 어렵다.
K6 결과물은 일정 목표 수치를 정하고 이를 기반으로 테스트했을때 참고하기 좋은 형식이라고 생각하였다.
예시로 처리시간을 기준으로 이야기하면 전체 평균 처리시간이 결과로 나오기 때문에 임계점 테스트시 user가 적을때의 결과값과 클때의 결과값이 섞여 판단하기 어렵게 된다.
(ex 초기 처리시간 50ms, 후기 처리시간 1s 이라면 결과에서는 200ms로 정상값으로 보일 수 있음)
-> 시계열로 어느 지점에서 수치가 변화하는지 확인할 필요가 있다.

2. K6 + InfluxDB + Grafana / 시계열 데이터 분석

테스트 유형을 정하는 한편 시계열 데이터를 저장하기 위한 InfluxDB, 이러한 정보를 시각적으로 표현하기 위해 Grafana를 사용하였다.

influxDB는 prometheus라는 대체제가 있었는데 간단하게 사용할 수 있다고 판단하여 influxDB를 선택했다.

추가적으로 여기서부터는 Docker도 추가하였는데 로컬에 설치하여 사용할 수도 있었으나 Docker-Compose를 사용하여 쉽게 환경을 구성하고도 싶었고 이러한 내용을 Git으로 기록(유지)하고도 싶었기 때문에 사용하였다.

이제 시간대별로 수치가 어떻게 변화하는지 확인할 수 있게 됐다.

시간 : 5m
Vuser : 0 에서 5000까지 vuser 증가

해당 조건으로 각각 session과 jwt 방식으로 진행한 후 분석해 보았다.

추후 시간이 너무 짧지 않은가 싶어 25분으로 증가율을 조정하여 실시했으나 비슷한 양상이였다.

확인한 수치는 RPS, ERROR 발생 시간, P95 응답시간이다.
Vuser수가 동일하게 증가함으로 Vuser를 기준으로 임계지점을 나타내었다.
수치로 최대한 나타내려고 하였으나 임의적으로 나타낼 수 밖에 없는 부분이 많았던 것 같다.

세션 분석

RPS

Vuser 2.20K 부분에서 추세 살짝 완만해짐, 그러나 계속 증가하는 추세
RPS 2.20K로 Vuser 수와 동일
Vuser 2.67K 부분부터 RPS가 요동 치기 시작, 하지만 계속 증가하는 추세
RPS 2.57K로 Vuser보다 미달
Vuser 3.47K 부분에서 RPS가 급격히 요동 치기 시작
RPS 3.47K이나 일시적 Vuser 수
Vuser 4.28K 부분에서 RPS 3.73K으로 최대치 기록

처음 추세가 완만해지는 부분이 빠르나 그 이후 임계점에 늦게 도달함
최대 RPS : 3.73K, 임계점 : 3.47K

ERROR

Vuser 2.67K 부분에서 처음으로 ERROR 9건 발생
RPS 2.58K
이후 산발적으로 발생,

ERROR가 발생하긴하나 특정한 패턴을 찾기 어려움

P95

Vuser 3.00K 부분에서 578ms으로 상승
= 처음으로 500ms 이상으로 상승, 이후 p95 수치 점차 증가

JWT 분석

RPS

Vuser 2.64K 부분에서 상승세 꺽임 = 시스템 임계점 근접
RPS 2.63K로 Vuser 수와 동일
Vuser 2.94K 부분부터 RPS가 요동 치기 시작 = 시스템 임계점 도달
RPS 2.69K로 Vuser보다 미달
이전 단계인 상승세가 꺽인 부분부터 조금의 시간이 흐른 후 임계점 도달
Vuser 3.59K 부분에서 RPS 3.47K으로 최대치 기록

ERROR

Vuser 3.20K 부분에서 처음으로 ERROR 9건 발생
RPS 1.7K / 2.9K 변동 이후 산발적으로 발생

P95

Vuser 2.87K 부분에서 501ms으로 상승
= 처음으로 500ms 이상으로 상승, 이후 p95 수치 점차 증가

수치 분석

전반적인 수치를 바탕으로 분석해보았을때 다음과 같다.

RPS

세션방식(최대 RPS 3.73K), JWT방식(최대 RPS 3.37K), 세션방식이 최대 RPS로 10.7% 더 높음
임계점을 안정적으로 RPS 수치를 내는 지점(RPS가 요동치기전)으로 하였을때
세션방식(최대 RPS 3.47K), JWT방식(최대 RPS 2.94K), 세션방식이 18.8% 더 높음

Error 발생 시점 및 분포

세션방식(Vuser 2.67K), JWT방식(Vuser 3.20K) JWT방식이 오류 발생 시점이 더 늦음

응답시간

전체 평균 응답시간
세션방식(315.35ms), JWT방식(524.31ms) 세션방식이 전체 응답시간이 39.84% 빠름
P95 응답시간
세션방식(1.31s), JWT방식(2.30s) 세션방식이 P95 응답시간이 43.04% 빠름
P95 기준 임계점(500ms 초과 시점)
세션방식(Vuser 3.00K), JWT방식(Vuser 2.87K) 세션방식이 초과 시점이 늦음

정리하자면 RPS 기준 10.7% ~ 18.8%, 응답시간 기준 약 40% 정도 세션방식이 빠른것으로 말할 수 있다.

다음으로는?

변화하는 수치를 보면서 CPU사용량등과 같이 시스템 메트릭 또한 참고해야하지 않을까 생각하였다.
RPS뿐만아니라 다양한 수치를 확인하고 이를 기준으로 임계점을 찾아보았는데 시스템 메트릭 또한 임계점에 대한 기준으로 파악할 수 있을 뿐만 아니라 개선점을 찾기위한 필수적인 메트릭으로 생각하였기 때문이다.

3. K6 + telegraf + InfluxDb + Grafana / 시스템 메트릭 추가

기존 구조에서 telegraf가 추가되었다.

프로메테우스 환경에서는 Node exporter를 사용하는 것 같고, 도커 내부에 시스템 메트릭을 보내주는 도구가 있다고는 들었는데
현재 로컬에서 서버를 사용하는 구조, influxDB를 사용하는 상황상 telegraf가 맞다고 생각하였다.

주로 확인한 메트릭은 CPU 사용률,메모레 사용률, 디스크 사용률이다.
기존과 동일한 상황에 시스템 메트릭만 추가하였다.

세션 분석

CPU 사용률

Vuser 3.00K 부분에서 94.6%으로 처음으로 90% 도달, 시스템 임계점 근접
이후 90% 초반대로 점차 증가
Vuser 3.70K 부분부터 98.1%로 이전까지는 90%후반 진입

메모리 사용률

시작 64%에서 종료까지 점차 74%로 상승하였지만 특이사항 없음

디스크 사용률

시작 48%에서 종료까지 점차 48.46으로 상승하였지만 특이사항 없음

JWT 분석

CPU 사용률

Vuser 1.97K 부분에서 92.8%으로 처음으로 90% 도달, 시스템 임계점 근접
이후 90% 초반대로 점차 증가
Vuser 2.80K 부분부터 98.2%로 이전까지는 90%초 였지만 100%대를 찍기시작

CPU 사용률이 전체적으로 강한 스파이크 형태를 보임

메모리 사용률

시작 70%에서 종료까지 점차 76%로 상승하였지만 특이사항 없음

디스크 사용률

시작 48.46%에서 종료까지 점차 48.52%으로 상승하였지만 특이사항 없음

수치 분석

CPU 사용률

90% 초과 진입 시점
세션 방식 Vuser 3.00K (94.6%), JWT방식 Vuser 1.97K (92.8%)
JWT가 더 빠르게 CPU 임계점에 도달함 - 1.03K 차이
98% 이상 진입 시점 세션 방식 Vuser 3.70K (98.1%), JWT 방식 Vuser 2.80K (98.2%) JWT가 더 이른 시점에 한계 도달 - 0.9K 차이는

메모리 사용률 분석

두 방식 모두 안정적인 사용패턴을 보이며 특이사항없음

디스크 사용률 분석

두 방식 모두 안정적인 사용패턴을 보이며 특이사항없음

확실히 CPU 사용량을 파악하니 성능차이가 더욱 도드라지게 보였다.
서명검증 및 디코딩등 연산이 많이 필요한 JWT방식에서 CPU사용량 임계점이 빨리 도달하였고 사용량의 안정성(스파이크)또한 JWT 방식이 더 낮았다.

지금까지 진행했던 부분을 시간순서대로 작성하다보니 양이 많아진 것 같다.
다음 글에서는 간단한 정리 및 회고로 끝내보고자 한다.