1. [펀잇] 쿼리 최종 정리 & 인덱스 걸기
인덱스 전
2. 성능 테스트 관련 글 읽기
성능 테스트 가이드
성능 테스트란 1초당 요청이 가장 많은 상황을 기준으로 서비스에서 발생하는 성능, 가용성 관련 문제를 찾아내는 작업
📍 우리 서비스의 최대 트래픽은 얼마나 될까?
이미 오픈된 서비스라면 APM 툴을 이용해 최대 트래픽을 쉽게 알아낼 수 있겠지만,
저희는 아직 오픈하지 않았기 때문에 주요 경쟁사를 살펴보며 추측해보도록 합시다.
이 글 에 따르면 저희의 주요 경쟁사인 '네이버 지도'의 DAU(하루 중 중복 없는 순수 사용자 수)는 500만명입니다. 이 중 약 200만 명이 지하철 서비스를 이용하다고 가정하고 이를 기준으로 최대 트래픽을 예상해보도록 하겠습니다.
1일 총 요청 수
= DAU x 1명당 1일 평균 요청 수
= 200만 x 4(아침,저녁 각 2번 예상) = 800만
1일 평균 rps(request per second)
= 1일 총 요청 수 / 하루 12시간을 초로 환산
= 800만 / 43200 = 185rps
최대 트래픽
= 1일 최대 rps
= 1일 평균 rps x 피크 시간 집중률
= 185 x 5 = 925rps
여기서 피크 시간 집중률은 평균 트래픽보다 트래픽이 집중될 때는 몇 배나 많을지 예상하면 됩니다. 저는 지하철 노선도 서비스이기 때문에 출퇴근 시간에 평소 트래픽보다 5배가 많을 것 같아 5를 넣었습니다.
📍 그래서 목표는?
- 사용자가 1초에 925번의 요청을 하는 상황에서 각 페이지가 132ms, 138ms 안에 제대로 된 응답을 하는지 테스트하고 문제점 찾기.
- 문제가 없다면, 서버의 최대 성능을 알아보기 위해 최대 트래픽을 넘어서는 부하를 주어가며 문제가 발생하는 지점 찾기
📍 시나리오에 따라 테스트 스크립트 작성하기
1. 부하를 줄 가상 사용자 수 (Vuser)
동시 사용자는 사이트를 띄워놓고 콘텐츠를 보고 있는 Concurrent User와, 요청을 보내고 요청 처리를 기다리고 있는 Active User로 나누어 볼 수 있습니다. Vuser는 지속해서 요청을 보내기 때문에 Active User를 묘사한다고 보시면 됩니다.
Vuser 계산 공식
Vuser = 목표rps x (한번의 시나리오를 완료하는데 걸리는 시간) / (시나리오 당 요청수)
Vuser = 목표rps x (요청1 목표 시간 + think time1+ 요청2 목표 시간 + think time2+ .. +N) / N
따라서 Think time을 최대한 현실 상황에 가깝게 잡고 그에 따라 Vuser를 늘리는 것이 좋습니다. 하지만 하나의 K6 서버가 만들어낼 수 있는 부하에는 한계가 있고, Vuser가 증가함에 따라 K6 Agent도 여러대가 필요해 테스트가 복잡해지므로 이번 테스트에서는 Think time을 0으로 잡도록 하겠습니다.
그럼 저희 서비스의 Vuser를 계산해보도록 하겠습니다.
Vuser
= 925rps x (경로 검색 목표 응답 시간 + think time + 경로 검색 결과 목표 응답 시간) / 요청 수
= 925rps x (0.132 + 0 + 0.138) / 2
= 125명
2. 부하 시간
어쩌구 저쩌구
- RPS(Request Per Second) : 1초 동안 서버로 요청되는 수 (=트래픽)
- TPS(Transaction Per Seconds) : 초당 처리된 트랜잭션 수
- 웹 애플리케이션 맥락에서 트랜잭션이란 Request와 Response 한 쌍이 처리됨
- TPS = VirtualUser / AverageResponseTime
- VirtualUser : 가상 유저
- Response Time : 요청 이후 응답이 되돌아오는 시간
- Peak Time : 서버가 순간적으로 가장 부하를 많이 받는 순간
- 이 때 Peak (최고 정점)을 찍는 순간의 동시 사용자 수와 기준 응답 시간을 목표로 성능 목표를 정의 하는 것이 일반적이다.
- maxThreads=200
- 가장 중요한 옵션
- 톰캣내의 쓰레드 수 결정
- active user 수 (= 순간 처리 가능한 Transaction 수)
- 일반적으로 100내외로 설정하는것이 좋음.
- 트랜잭션의 무게에 따라 50~500개 정도로 설정하는게 일반적
- 이 값은 성능 테스트를 통해 튜닝을 하면서 조정해 나가는 것이 좋다
- maxThreads 값이 최대 값인 750을 넘을 경우 두 대의 Tomcat을 이용해 클러스터링 구성을 하는 것이 좋다.
- maxConnection=8192
- 하나의 톰캣인스턴스가 유지할 수 있는 Connection의 수
- 현재 연결되어 있는 실제 Connection의 수가 아니라 현재 사용중인 socket fd (file descriptor)의 수
- acceptCount=10
- Request Queue의 길이 설정
- idle thread가 없을경우(thread 가 full일경우) queue에 쌓여서 idle thread가 생길때까지 대기하게된다.
- queue에 쌓였다는것은 이미 사용가능한 thread 모두 써도 처리를 못하는것이기 때문에 장애일 가능성이 높다.
- 그래서, queue길이는 길게 주는것보다 짧게 주어 에러코드를 내려주어 에러를 처리하는것이 좋다.
- queue길이가 길면 대기하는시간이 길어져 다른 장애로 전파되는 경우가있음.
- 순간 과부화를 막기위해 0보다는 10내외로 짧게 준다.
트렌젝션의 무게에 따라 50~500 개 정도로 설정하는 게 일반적이다. 이 값은 성능 테스트를 통해서 튜닝을 하면서 조정해 나가는 것이 좋다.
성능 테스트 프로세스
기타
크롬의 개발자 도구에 들어가서 Performance Insights에 들어가면
3. [펀잇] 우리팀 톰캣 설정
유사 서비스 : https://pyony.com/
MAU(Monthly Active User)
= 336100 (33만 6천명)
DAU(Daily Active User)
= 336100 / 30
= 11203.3
1일 총 요청 수
= DAU * 1명당 1일 평균 요청 수
= 11203 * 1
= 11203
1일 평균 RPS(Request Per Second)
= 1일 총 요청 수 / 하루 12시간을 초로 환산
= 11203 / 43200 = 0.2593
최대 트래픽
= 1일 최대 RPS
= 1일 평균 RPS * 피크 시간 집중률
= 0.25 * 5
= 1.25RPS