[Performance] 🟢 TPS 185%, Error rate 0%, MTTFB 변동률 2422% Improved by - HPA, ReadinessProbe, CPU limit, EKS NodeGroup AutoScaling, Caching, 톰켓 최적화 GET /api-chat/rooms

[ghkdqhrbals]

로드 테스트 설정

• Thread : 296
• URL : GET /rooms
• Duration : 10min
• HPA max node : 3

결과 미리 관찰

• Total Test : 142,805
• Success : 133,416
• Error : 9,389 (6.6%)
• AVG TPS : 226.1
• AVG MTTFB : 1352.82ms

중간중간 TPS 가 감소하는 모습을 확 위의 그래프에서 확인할 수 있습니다. 역시 VUSER 가 100명일 때와 300일 때는 많이 다르네요 :( TPS 감소 이유는 아래의 그래프에서 원인을 파악할 수 있습니다.

MTTFB 가 중간중간 5초가 넘습니다. 그리고 이런 피크를 보일 때 마다 오류또한 증가합니다. 마찬가지로 TPS 또한 같이 감소하는 것을 확인할 수 있었습니다. 저는 채팅서버의 로드가 중간중간 증가해서 헬스체크의 타임아웃이 발생했고, 서비스가 로드밸런싱을 다시 수행하면서 TPS 가 감소했다고 생각했어요. 한번 확인해보겠습니다.

채팅서버의 Deployment 의 readinessProbe 헬스체크 timeoutSeconds는 1초로 설정되어 있었습니다.

deploy 로그를 확인했더니 역시 health 타임아웃 오류가 발생했었습니다.

그렇다면 타임아웃을 10초로 설정하면 견딜 수 있겠죠?

[ghkdqhrbals]

Readiness 타임아웃 1초 -> 10초

Readiness.timeout 10 초로 설정해도 큰 차이가 없었습니다 ㅜㅜ.

조금의 차이점이라면 빈번하게 발생하던 헬스체크 타임아웃 문제가 조금은 완화되었다는 점이 존재했어요.

중간중간 TPS 가 감소하는 오류또한 여전히 존재했습니다.

Readiness 타임아웃 10초 -> 60초

Readiness.timeout 을 그러면 60초로 바꿔볼까요?

중간중간 MTTFB 피크가 거의 4000ms 로 치솟으면서 서버가 안정적으로 동작하지 않는 것을 확인할 수 있죠? 그리고 이에 맞추어 TPS 또한 떨어지고, 오류도 중간에 발생하는 것을 확인할 수 있습니다. 그래도 Error 는 0.0% 로 비교적 에러없이 동작하는 것을 확인할 수 있었습니다. TPS 는 여전히 낮고 MTTFB 또한 불안정하지만요!

• Total Test : 138,487
• Success : 138,462
• Error : 25 (0.0%)
• AVG TPS : 233.3
• AVG MTTFB : 1239.99ms

내장 tomcat 10.1.7 max-threads 크기 10개 -> 100개

뭔가 타임아웃은 10초도 충분한것 같죠? 그렇다면 이번엔 Spring boot 내장 톰켓 서버의 max-threads-size 를 늘려봅시다. 이유는 채팅서버의 cpu 사용량이 생각보다 작기 때문입니다. 많은 스레드를 돌리거나 요청을 많이 받을 수 있어야지 cpu 사용률도 올라가니 이 부분에 문제가 있다고 판단하고 스레드 풀 사이즈를 늘리는 방향을 설정하였습니다.

확실히 오류가 줄었죠? 그런데 아직 생각보다 cpu 리소스를 제대로 활용하지 못하는 모습을 볼 수 있습니다. 빨간선은 request 이며 노란선은 limit 입니다. y-grid 는 0.5 cpu 를 의미합니다.

그래서 최종적으로 관찰한 결과는 아래와 같아요.

• Total Test : 134,988
• Success : 134,953
• Error : 35
• AVG TPS : 228.4
• AVG MTTFB : 1200ms

[ghkdqhrbals]

만약 vuser 300 명을 HPA 파드 오토 스케일 아웃 없이 단일 파드로만 핸들링할 때 어떤 결과가 나올지 궁금하지 않나요?

그래서 실험해보았고 아래와 같은 결과가 나왔습니다. 실험 중 오류가 너무 많이 발생되서 자동으로 중지될 정도로 많은 오류를 반환합니다.

• Total Test : 40,228
• Success : 19,668
• Error : 20,560 (51.1%)
• AVG TPS : 108.1
• AVG MTTFB : 1200.81ms

10분동안 실행하도록 지시했지만 03:10 에 높은 에러율로 인한 종료

[ghkdqhrbals]

내장 tomcat 최적화

PR #334 에서 적용된 톰켓 최적화 설정을 아래에 풀어볼게요.

• 대기 큐 크기(accept-count) 100 -> 100
  • 유지
• 동시 연결 개수(max-connections) 100 -> 8192
  • 현재 vuser 300 의 동시 연결 요청을 전송하기때문에 이를 고려하여 default 개수까지 증량
• 최대 스레드 풀 크기(max-threads) 100 -> 150
  • 채팅서버 vcpu limit 1500m 이기때문에 각 코어당 * 100 하여 처리 1.5 * 100 = 150
  • 현재 대부분의 API 요청에서 i/o 작업을 하기 때문에 왠만하면 스레드를 늘리는 것이 좋습니다. 만약 cpu 소모량이 많다고 한다면 줄이는 것이 좋다고 합니다. 괜한 context switch 를 줄이는 것이 효율적이기 때문입니다.
• 연결 타임아웃(connection-timeout) 10s -> 60s
  • 현재 readinessProbe 타임아웃 설정이 60s 로 설정되어 있습니다. 이에 맞추어 오류를 줄이기 위해 60s 로 설정하는 것이 올바르다고 생각해서 변경하게 되었습니다.
• 항상 유지되는 최소 스레드 크기(min-spare-threads) 30 -> 30
  • 유지

그래서 결과는요!!!

• Total Test : 181,050
• Success : 181,050
• Error : 0 (0.0%)
• AVG TPS : 308.4
• AVG MTTFB : 1200.88ms

정말 신기하지 않나요? 동시 요청 스레드 300 을 우리는 에러없이 견딜 수 있는 서버를 만들어낸거에요! 그리고 MTTFB 가 꽤 안정적으로 수평을 이루고 있는 부분이 안정적인 서비스라는 뜻이겠죠? 저는 이 결과를 통해 병목이 걸리는 곳이 내장 톰켓이였다는 것을 확인할 수 있었습니다.

그럼 이제 현재까지의 모든 테스트들을 요약하여 시작과 끝의 성능지표를 비교해보겠습니다.

• HPA X, 단일 파드 톰켓 최적화 미적용 채팅 서버 VUSER 300 로드테스트 결과

  • Total Test : 40,228
  • Success : 19,668
  • Error : 20,560 (51.1%)
  • AVG TPS : 108.1
  • AVG MTTFB : 1200.81ms

• HPA O(max 3), ReadinessProbe O, CPU limit O, EKS NodeGroup AutoScaling O(CPU usage 50%), Caching, 톰켓 최적화 O 채팅 서버 VUSER 300 로드테스트 결과

  • Total Test : 181,050
  • Success : 181,050
  • Error : 0 (0.0%)
  • AVG TPS : 308.4
  • AVG MTTFB : 1200.88ms

• 결과 비교

  • 에러율 51.1% -> 0.0 % 로 서버 안전성 증가
  • TPS 185.29% 성능 증가
  • MTTFB 평균 변동 퍼센트 : 8.17% -> 0.21%