Latency 관리

Back-end 개발을 하며 Latency 개선 및 관리 목표를 설정하는 것은 중요합니다.

 

Latency 목표가 없다면 현재 Latency가 적정한 것인지 알 수 없고 개선 방향과 얼마나 노력을 들여야 할 지도 알 수 없습니다.

 

이번에 회사에서 Latency 목표를 정하면서 밟았던 과정을 정리하여 공유드립니다.

Latency 백분위 지표 정하기

목표를 정하기 전 어떤 백분위 지표를 측정 및 개선 목표로 잡을 것인지를 정하는 것이 필요합니다.

 

F/E 에서는 주로 P75를 기준으로 사용합니다.

그 이유는 1) 대부분 사용자의 경험을 대변하면서도 2) 네트워크 통신 이상등에 기인하는 이상 수치에 영향을 받지 않기 때문입니다.

 

자세한 설명은 https://web.dev/i18n/ko/defining-core-web-vitals-thresholds/ 의 백분위수 선택 부분 참고하실 수 있습니다.

 

상황에 따라 다르겠지만 B/E에서는 P90이 더 적절한 수치일 수 있다고 생각합니다.

그 이유는 B/E는 주로 내부망 또는 통제된 상황에서 통신이 이루어지기 때문입니다.

때문에 B/E의 이상 수치 중 개선이 가능한 (또는 개선해야만 하는) 것의 비중이 F/E보다 높을 것입니다.

 

이러한 이유로 B/E의 경우 P90을 사용하면 병목 지점을 효과적으로 감지하고 개선할 수 있게 된다고 봅니다.

 

하지만 프로젝트 차원에서 F/E와 B/E가 다른 수치를 기준으로 삼고 기록한다면 혼란의 여지가 있어,

B/E에서 P75, P90을 함께 적고 관리하는게 좋지 않을까 합니다.

Latency 목표 결정

목표는 아래 2가지를 고려하여 결정됩니다.

    1. 사용하는 측으로부터의 요구

    2. 현재 상황에 따른 목표

 

우선 사용하는 측에서 설정한 목표가 있고 그 목표를 달성하는데 우리 API가 영향을 주고 있다면 이를 기반으로 목표를 정할 수 있습니다.

 

또 현재 상황을 고려하여 목표를 정할 수 있는데 그 때 고려될 수 있는 것은 아래 3가지 입니다.

    1. 다루는 데이터와 제공처

    2. 이상적인 조회 단계와 순서

    3. 각 데이터 제공처의 응답 속도

1) 다루는 데이터와 제공처 확인

어떤 데이터를 다루고 해당 데이터들을 어디에서 공급받고 있는지를 정리합니다.

2 ) 현재 조회 단계 및 순서 확인

각 데이터를 어떤 단계와 순서로 조회하는지 파악합니다. A,B를 비동기로 조회 후 결과를 모두 기다린 후 다음 조회가 일어난다면 같은 단계에 둡니다.

조회 단계	조회 데이터
1단계	A, B, C
2단계	D, E
3단계	F

3) 각 공급처별 응답 속도 확인

각 데이터 공급처(DB 혹은 다른 서비스)의 응답 속도를 파악합니다.

쉽게 확인할 수 있는 평균을 사용할 수 있지만 백분위(P50, P75, P90 등)로 파악해 두는 것이 좋습니다.

 

위 3단계를 거친 후 각 사항을 고려하여 기존 조회 단계를 이상적인 조회 단계와 순서로 재배치합니다.

조회 단계	조회 데이터	P75	P90
1단계	A, B, C, E 조회	12ms	34ms
2단계	E, F 조회	56ms	78ms
합계		68ms	112ms

특정 데이터 때문에 조회 단계를 길어지는 경우가 있습니다.

그렇다면 해당 데이터를 다른 방법으로 조회 받을 수 있는지를 찾아볼 수 있습니다. 없다면 해당 데이터 제공처에 새로운 방법을 요청할 수도 있습니다.

또 특별히 느린 제공처가 있다면 성능 개선 요구를 해볼 수 있는데, 이렇게 타팀의 작업이 필요한 목표는 장기 목표로 둡니다.

Sample Latency 목표

각 단계를 따르면 최종적으로 아래와 같은 단기(팀 내에서 자체적으로 개선 가능), 장기(다른 팀의 도움으로 달성 가능한 목표) Latency 목표를 세울 수 있습니다.

Sample API	단기	장기
P75	43ms	21ms
P90	87ms	65ms