느린 게시글 목록 조회 트러블 슈팅

문제 상황

DailyBlog 내 게시글 목록을 새로 고침하면 0.5초 정도 지연되는 현상을 발견했다.

개발자 도구로 응답 시간을 확인해보니 사용자가 충분히 체감할 수 있는 400~900ms로 측정되었다.

블로그 서비스에서 게시글 목록이 늦게 로딩되는 현상은 사용자 경험을 크게 해칠 수 있기 때문에 이를 해결해보기로 했다.

 

시도한 것

우선 개발자도구-네트워크 탭 내 Waterfall 항목을 확인해보았다.

요청 시간 817ms 중 서버 응답 시간의 비율이 97%(807ms)였다.

 

​

다음으로는 django 애플리케이션 로그를 확인해보았다.

 

django 애플리케이션에서는 별도로 구현한 LoggingMiddleWare를 통해 요청의 진입~탈출까지의 시간을 duration이라는 필드로 로그에 기록하고 있다.

 

해당 요청 로그의 duration을 확인해보면 6.7 ms 정도 걸린 것을 확인할 수 있었다.

 

따라서 코드 최적화나 데이터베이스 병목과는 관련이 없다는 것을 확인할 수 있었다.

 

다음으로는 동일 ec2 에 위치한 nginx의 access 로그를 확인해보았다.

정상 수치인 8ms가 기록되었기에 nginx까지는 병목 원인이 존재하지 않는다는 것을 알 수 있었다. 

 

(만약 nginx 로그에서 응답 지연이 발견되었다면 nginx와 django 애플리케이션 사이에 위치한 애플리케이션 서버 gunicorn의 로그와 설정을 살펴보면 좋을 것 같다.)

 

해결 방법

브라우저 응답 시간(~800ms)과 nginx 로그(8ms) 사이의 큰 차이를 보아,

지연은 백엔드가 아닌 클라이언트와 서버 사이 어딘가에서 발생하고 있다고 판단했다.

 

다시 원점으로 돌아가 지연된 응답의 헤더를 살펴보았다.

 

현재 프론트엔드 빌드 산출물이 Vercel을 통해 배포가 되어있어 Vercel 관련 내용들이 담겨있는 것을 확인할 수 있었다.

구글에 검색해보니 icn1은 서울 리전, iad1은 미국 리전을 의미하고 icn1::iad1은 현재 실행되는 함수가 iad1(미국 리전)에 위치해있다는 의미였다.

바로 여기서 응답 지연이 발생한 것이라고 유추할 수 있었다. 

 

가설 확인과 해결을 위해 프론트엔드 동료 개발자분께 문제 상황과 함께 확인 및 변경을 요청 드렸다.

 

 

확인해보니 미국 리전이 맞았고, 서울 리전으로 변경했다는 답변을 받았다.

 

다시 개발자 도구를 확인해보니 X-Vercel-Id 의 값이 icn1::icn1으로 변경되고,

응답 시간이 70ms 이하로 개선된 것을 확인했다.

icn1::icn1로 변경. 요청이 더 이상 미국을 갔다 오지 않음.

 

 

느낀 점

백엔드 단의 문제가 아니었음에도 끝까지 원인을 쫓아 팀원과 함께 해결할 수 있었던 좋은 경험이었다. 

또한 로그를 통해 지연이 발생하는 구간을 명확히 할 수 있었기에, 로깅의 중요성을 한 번 더 체감할 수 있었다.