이전 포스팅:
- nGrinder와 Pinpoint를 이용한 성능 / 부하 테스트1 - 테스트 계획
- nGrinder와 Pinpoint를 이용한 성능 / 부하 테스트2 - 시나리오 작성
- nGrinder와 Pinpoint를 이용한 성능 / 부하 테스트3 - Smoke 테스트 & Load 테스트
이 포스팅은 개선 방법에 대한 자세한 내용은 다루지 않고, 개선 내용과 개선 결과에 대해서만 다룹니다.
📝 개선 전 결과
최대 트래픽의 load test의 경우입니다.
🌊 Connection pool 조정
최대 트래픽 load test 시 모든 요청이 목표 MTT(50 ~ 100ms)를 넘어버렸습니다. 이 문제는 connection 문제였습니다.
VUser가 22명이었기 때문에, 넉넉잡아 connection pool을 30정도로 늘려봤습니다. 그 후 다시 load test를 돌렸습니다.
그래프만 봐도 일단 시나리오 전체 평균값이긴 하지만 MTT가 많이 줄어든 것을 볼 수 있습니다.
pinpoint를 한번 살펴보겠습니다.
전반적인 요청들은 성능 향상이 있는게 보입니다만 가장 문제였던 리뷰어 목록을 조회하는 요청은 오히려 시간이 더 올라갔네요 흠.. 조회쿼리 개선을 하면 나아질 거라 생각합니다.
우선 connection pool을 조정하면서 얻으려고 했던 이점인 getConnection 비용은 잘 없어진 걸 볼 수 있습니다.
🛠 조회쿼리 개선
1) 로그인 조회 쿼리
로그인 조회 쿼리는 where 절에 oauth_id 칼럼을 사용하여 member를 찾고 있습니다. 따라서 oauth_id 칼럼에 인덱스를 걸어주었습니다.
2) 리뷰어 목록 조회 쿼리
리뷰어 목록 조회 쿼리 이 녀석이 가장 문제입니다. 이 쿼리는 페이지네이션이 적용되어 있습니다.
전체 페이지 수를 알기위한 count 쿼리, 조건에 맞는 리뷰어 목록을 가져오는 쿼리 이 2가지 쿼리를 개선해야했습니다.
인덱스를 걸어 해결해보려 하였으나 잘 적용되지 않았습니다. 따라서 join문을 줄여보기로 했습니다. 기존에는 필터링 조건이 있든 없든 무조건 여러 테이블이 join 되면서 문제가 발생하였습니다. 이를 필터링 조건이 추가될 경우만 join을 추가해주는 식으로 변경하였습니다.
조회 쿼리를 개선하고 나니 평균 테스트 시간이 많이 줄어들었습니다. 리뷰어 목록 요청은 여전히 목표치에는 도달하지 못했습니다.
pinpoint도 살펴보겠습니다.
아직 리뷰어 조회쿼리는 오래걸리지만, 그래도 이전에 비하면 훨씬 좋아진 것을 볼 수 있습니다. 나머지는 모두 목표치에 도달했습니다.
➗ DB replication
하나의 DB를 사용할때에 비해 부하를 줄여보기 위해, DB replication을 진행해보고 테스트를 해보기로 했습니다. 조회쿼리를 담당하는 slave db를 2개 만들어 주었습니다. (각 slave의 connection pool은 15개씩으로 바꿔주었습니다.)
이전보다 좋은 성능을 볼 수 있습니다.
pinpoint를 한 번 보겠습니다.
위의 동그라미 친 부분은 모두 리뷰어 목록 조회 요청입니다. 이전보다 확실히 빨라지긴 했는데, 양극화가 되어 있습니다.
각각 요청을 살펴보니 확실히 차이가 납니다.
DataSource를 살펴보니 slave1과 slave2가 골고루 쓰이지 않은 것을 볼 수 있습니다. 하나의 slave로 리뷰어 목록 조회 요청이 쏠리게 되어 해당 slave에서 처리하는 요청이 상대적으로 오래걸린 것으로 추측됩니다. 나중에 한 번 방법을 생각해봐야겠습니다.🤔
✍🏻 느낀점
결국은 리뷰어 목록 조회 요청은 목표까지 줄이지 못했습니다.😭😭
후에 더 공부한 후에 다시 쿼리 개선을 해보고 싶습니다.
이번에 처음 성능 테스트를 해보면서 제대로 한 것인가 라는 생각이 많이 들었습니다. 지금 제가 이해한것도 틀릴 수도 있다고 생각합니다. 틀린 부분이 있다면 알려주시면 감사하겠습니다.🙏
추가적으로 아래의 생각을 하게 되었습니다.
1) 시나리오는 짧게 가져가거나, api 별로 해보는 게 좋을 것 같다.
2) 페이지네이션이 포함된 요청이 있는 경우 실제로 있을 법한 범위를 잡는 게 좋을 것 같다.
1)의 이유는 시나리오를 길게 잡으니 오래 걸리는 요청에 의해 TPS 값이 api에 상관없이 모두 똑같이 나와 별 의미없는 지표가 되어버렸다는 생각이 들어서 입니다. 어차피 어디서 오래걸리는지를 파악하기 위해서는 각 api가 얼마나 걸리는지를 확인해보는게 더 좋을 것 같습니다.
2)의 이유는 이번에 페이지 30000을 잡아서 테스트를 해봤는데, 실제로 페이지 30000 요청이 있을 것인지에 대한 의문이 들었습니다. 어느 정도 예상 가능한 수치로 테스트 해보는게 더 좋을 것 같습니다.
reference
