https://if.kakao.com/2022/session/35
Kakao T 사용자의 계정 서비스 내에 있던 성능 이슈 해결에 대해
TPS 요청이 높은 서비스중 하나.
Transaction Per Second(TPS)는 초당 트랜잭션의 개수입니다. 실제 계산하는 방식은 일정 기간 동안 실행된 트랜잭션의 개수를 구하고 다시 1초 구간에 대한 값으로 변경합니다. 와탭의 경우 5초 구간으로 값을 수집하기 때문에 단위시간 동안 집계된 트랜잭션의 수를 5로 나눈 값이 표시됩니다.
자바의 프로그램 실행 과정
Key
latency 이슈
계정서비스 트래픽이 증가중
응답 지연 이슈
쿠버네티스
롤링 업데이트
tps 3800 ~ 4000
많은 서버에 영향을 줌
지연이 시간이 흐르면 해소됨
배포까지 충분한 준비가 되지 않은것 같은 서버느낌
응답 지연 원인 분석 시작
리소스 분석
-> CPU 10퍼 이하
-> MEM 60% 이하
-> Network bandwidth 노드당 10 ~ 20mb
-> tps
대부분이 여유있었다.
문제없네?
어플리케이션 모니터링을 위한 APM에서 지연을 확인해보니
외부 DB는 문제 x
대부분 지연은 어플리케이션 영역
tomcat web 앱 스레드
10 ~ 8192 설정
시작 후 200여개로 늘어나는 것을 확인 조정필요
RDB 커넥션 풀 20
JVM WARM UP을 확인 할 차례
최초에는 Readiness probes 요청에 대해 400 응답 코드
Application Ready 이벤트가 발생 후 3초의 지연을 주게 되는데 그 이후부터는
Readiness probs 요청에 200 응답을 반환한다.
Traffic In
기존 슈도 코드
warmer가 실제 api 요청이 아니라 앱내 단순 질의, 단순 조회라 효과적이지 않을거라 판단
분석을 요약하자면
스레시 시작 개수를 256개로 확장
웜업을 실제 api와 유사한 요청으로 변경
개선 후 로직
외부 트래픽 차단을 위해 readniss probe 요청에 대한 400응답 (웜업전에는)
이전에는 3초 지연 후 트래픽을 허용했다면 지금은 웜업이 완료된 이후에 200응답.
각 pod 마다 로컬호스트에서 GET API 요청
결과
그러나 2달 후
지연 포착
JIT 문젠가??
- GralJIT 도입 해봤지만 효과 없었다.
- AOT 도입 보류
- Redis Conection poll 도입 효과 x
- warm up count 증가 ! 해결
JVM 옵션으로
코드 캐시 사이즈를 변경 가능
샘플 코드
250회 동작했을때 로그 확인이 가능했다.
1000회 동작했을때 C2 컴파일러 확인 가능
각 warm up count별 컴파일 횟수 결과
250이 가장 효율적이라고 채택
현재까지 안정적 서비스 유지중
