데이터독 모니터링과 함께 성능 개선하기

사내에 데이터독이 들어오면서 데이터독 관련 세미나를 들었다. 세미나에서 들었던 내용을 바탕으로 실무에 적용하여 개선해 보았다.

 

용어

TTI (Time To Interactive)

• 웹 페이지가 사용자 입력(클릭, 스크롤 등)에 즉시 반응할 수 있을 만큼 완전히 로드된 시점까지 걸린 시간
• 즉, 페이지가 시각적으로 보이기 시작한 후, 완전히 "쓸 수 있는 상태"가 될 때까지 걸리는 시간

Percentile (퍼센타일)

• 전체 응답 시간(또는 성능 데이터)을 정렬한 후, 특정 백분위 위치에 있는 값
• P95 → 95%의 요청은 이 시간보다 빠르고, 나머지 5%는 더 느리다는 의미
• P99 → 가장 느린 상위 1% 요청의 기준점
• p99=500ms이면 99%요청은 500ms이하로 처리된다는 의미

기준

• 최적: 1초 미만
• 양호: 1~3초
• 보통: 3~5초
• 개선 필요: 5초 ~

API하나가 3초를 넘어가는것도 사실 개선이 필요해보이긴 하다.

적용하기

일주일간 p95지표를 확인하면 도메인 특성상 트래픽이 많아지는 점심시간에 p95속도가 느려집니다. 이러한 문제를 개선하고자 했습니다. 요청량이 많은 api중 p95 Latencey가 높은 API를 선정했습니다.

p95 지표

해당 API의 로직을 확인했을때, 병목이 생길만한 쿼리를 찾았고 데이터독의 DBM을 통해서 확인했습니다.

병목 쿼리

개선하기

해당 쿼리는 고객들이 매장에 재방문하는 주기를 계산하는 쿼리입니다. 매장을 방문했던 고객들의 모든 이력을 기반으로 계산하는 쿼리이기에 무거울 수 있습니다만 인덱스를 태우기때문에 왠만한 규모의 매장에서는 빠르게 응답을 내려줄 수 있습니다.

하지만 5%정도의 규모가 큰 매장의 경우 위의 지표처럼 안좋은 사용자 경험을 주고 있습니다.

 

이를 개선하기 위해서 캐시를 적용하여 매장 재방문 간격을 캐시에 pre-loading하도록 개선하였습니다. 이를통해 성능 개선을 경험할 수 있었습니다. 

배포후 Latency 지표