Vercel Speed Insight와 함께하는 RES 성능 개선기

Vercel Speed Insight와 함께하는 RES 성능 개선기

Vercel를 통하여 새로운 서비스가 배포되면서, Speed Insights Tabs을 통하여 P75, P90, P95, P99라는 지표들을 처음 접하게 되었다. 이는 전체 사용자의 75%, 90%, 95%, 99%가 경험하는 성능 구간을 뜻하며, 우리가 제공하는 Real Experience Score(RES)가 전 세계적으로 어떤 분포를 보이는지 쉽게 확인할 수 있도록 도와준다.

또한 Vercel에서는 Virtual Experience Score, Core Web Vitals도 지표로 사용하고 있으며, 이를 점수에 맞춰 색상별로 사용자에게 결과값을 나타내고 있다.

• Real Experience Score(RES)
  사용자 기기에서 수집한 실제 데이터 포인트 사용, 브라우저 성능 API와 연동된 데이터를 종합해 산출된다.
• Virtual Experience Score (VES)
  앱 성능에 대한 변경 사항의 영향을 예상하여 사용자 경험에 퇴보가 없음을 보장하는 예측 성능 지표.
• Core Web Vitals
  Google을 비롯한 Web Performance Working Group에서 정의한 값들로, 웹 어플리케이션의 로딩 속도, 반응성, 시각적 안정성을 평가하는 핵심 지표. 지표 값으로는 LCP, CLS, INP, FCP, FID 등의 기준이 있고, 해당 기준이 목표하는 목표값이 존재한다.

Core Web Vitals 설명

Largest Contentful Paint(LCP)
- 페이지에서 가장 큰 콘텐츠 요소(이미지, 텍스트 블록 등)가 로드되는 시간을 측정한다. 사용자가 페이지의 주요 콘텐츠를 얼마나 빨리 볼 수 있는지 나타내는 로딩 성능 지표이며, 좋은 사용자 경험을 위해 2.5초 이내를 목표한다.

Cumulative Layout Shift (CLS)
- 페이지 로딩 중 요소들이 예기치 않게 이동하는 정도를 측정한다. 낮은 CLS 값은 페이지가 시각적으로 안정적임을 의미하며, 사용자가 실수로 잘못된 요소를 클릭하는 것을 방지한다. 0.1 이하가 좋은 점수다.

Interaction to Next Paint (INP)
- 사용자가 페이지와 상호작용(클릭, 탭, 키 입력 등)한 후 화면이 업데이트될 때까지 걸리는 시간을 측정한다. 페이지의 반응성을 나타내며 200ms 이하가 이상적이며, FID를 대체하는 새로운 지표.

First Contentful Paint (FCP)
- 페이지가 로드되기 시작한 후 텍스트나 이미지와 같은 첫 번째 콘텐츠가 화면에 표시되는 시간을 측정한다. 초기 로딩 경험을 나타내며 1.8초 이하가 좋은 성능이다.

First Input Delay (FID)
- 사용자가 페이지와 처음 상호작용할 때(링크 클릭, 버튼 탭 등) 브라우저가 해당 상호작용에 응답하기까지 걸리는 시간을 측정한다. 100ms 이하가 좋은 사용자 경험을 제공하며, INP로 점차 대체되고 있다.
...

문제 상황

초기에는 사용자 수가 적어 RES P75가 85~95 정도로 양호했지만, 해외 유저가 빠르게 유입되면서 지표가 급격히 하락했다. 원인 분석 결과, 크게 두 가지 문제를 확인했다. (정확히는 사용자가 대한민국 국적인, 우리(개발자)만 접속했기 때문에 좋을 수밖에 없었다.)

 

큰 문제는 두 가지로 정의했다.

첫 째, 글로벌 서비스로서의 인프라 준비 미흡
둘째, Vercel이라는 서버리스 서비스 환경에 대한 준비 부족.

 

왜 두 가지 문제로 정의했는지, 어떻게 해결했는지 살펴보자.

글로벌 서비스?

해외 유저들을 타겟팅하며, 서비스를 모두 영어로 준비한 것에 비해 인프라 환경은 그렇지 못했다.
서버와 데이터베이스 모두 한국을 기반으로 설정했다.

 

첫 마케팅 진행 이후 가장 반응이 많이 온 곳은 유럽, 중동, 파키스탄과 같이 모두 해외에서 반응이 오며 트래픽이 발생했다.
그러다 보니, 유저가 유입되자 통신적으로 절대적인 거리 또는 각 국가별로 통신 인프라가 좋지 않은 국가일수록 성능이 떨어질 수밖에 없었다.

해결을 위한 접근 1

해외 서버를 증설 및 Replica DB 생성에 대한 논의가 먼저 이루어졌다.
서버의 경우 Vercel에서 제공하는 멀티 리전을 사용하기로 했고, 데이터베이스 같은 경우에는 유입 유저가 많지 않은 상황에서 비용을 더 들여가며 레플리카는 섣부르다는 판단과 함께 마이그레이션을 결정했다.

 

이제 서버를 이전하기 위한 Region을 고민하게 된다.

해외 중 어느 곳을 선택할 것인지에 대해 논의가 진행되었는데, 해저 케이블까지 찾아다니면서 현재 트래픽이 발생하는 미국, 독일, 싱가폴 이렇게 세 곳으로 결정했다.

해결을 위한 접근 2

Vercel은 Serverless다. 서버리스 함수가 사용되지 않고 일정 시간이 지나 인스턴스가 종료된 뒤, 다시 첫 유저가 접속할 때 인스턴스가 새로 가동되는 현상을 말한다. 이로 인해 일반적으로 2~3초가량 추가 지연이 발생할 수 있다.

 

흔히 이야기하는 콜드 스타트(cold start) 문제가 발생한다.

 

AWS Lambda의 경우에는 provisioning 환경을 제공하여 계속해서 서버를 warm 하게 유지해 주면서, 개발자들은 더 이상 신경을 쓰지 않아도 되지만 Vercel의 경우에는 동시성을 보장해주지 않았다. (물론 계속해서 서버를 warm 하게 유지해 주기 때문에 비용이 발생한다 😊)

 

Vercel의 기능 향상을 위해 관련 문서들을 찾아봤는데, 배포되는 Function의 지역 선택, 캐싱 헤더 사용, Next.js 최신 버전 업데이트 등의 내용을 알려주기만 했지 직접적으로 Cold start를 해결하는 문제를 제시하지 않았다.

 

그래서 따로 Vercel에 메일을 보내어 확인받기로 했다.

 

질문 : "Cold Start 문제를 해결하기 위해 Cron job을 실행시키는 경우가 있는데, 해당 내용이 당신들이 제공하는 문서에는 작성되어 있지 않다. 해당 방법을 권장하지 않는 것인가?"

 

답변 : "사용자가 특정 경로에서 콜드 스타트 문제를 겪고 있는 경우 권장하는 방법 중 하나이다."

 

바로 health check용 cron job을 만들어서, 약 3초 정도 지연되었던 콜드 스타트 문제를 해결했다.

최종

조금씩 여러 시도를 하며 성능을 올리고 있던 와중에, 대표님이 새로운 시도를 하셨다.

1. health check를 진행할 때, 우리 서비스의 모든 page route들을 한 번씩 접속한다.
2. 각 Region별로 Cron job을 실행시킨다.

두 과정에서 모두 유의미한 성과를 가지면서 콜드스타트로 인한 페이지 로딩 및 서버 호출에 대한 응답을 즉각적으로 받게 되었는데, 더 유의미한 발견을 하게 되었다.

 

각 Region별로 Cron Job을 실행시키면서 모니터링을 진행한 결과, dub(Dublin) region을 사용할 경우에 multi region을 사용했을 때보다 응답 속도가 엄청나게 빨라지는 것을 확인하게 됐다.

getList in KR ---- vercel multi region
3750ms
3347ms
3724ms
9732ms
3626ms

getList in KR ---- vercel single region (아일랜드 only)
502ms
447ms
494ms
476ms

다른 API들도 테스트를 진행하는데, 아일랜드를 기점으로 했을 때 성능이 월등히 좋아진다는 것을 확인했다.
이로 인하여 멀티리전을 취소하고 DUB 한 곳으로 서버를 올리는 것으로 최종 결정되었다.

 

이후

지금까지는 아일랜드 단일 리전 + Cron job으로 성능을 상당 부분 개선했으나, 최근 브라질 등 또 다른 지역에서 트래픽이 증가하고 있어 다시 글로벌 인프라 문제를 고민해야 할 시점이 왔다.

필요하다면 브라질 근처 리전을 추가하거나, 추후로 미루었던 DB Replica 확대등을 고려해봐야하지 않을까?

참고 문서

Speed Insights Metrics

Speed Insights Overview

 

Submarine Cable Map