[공감병동 프로젝트] Vercel 배포시 성능이슈 해결 (Vercel -> EC2) -

TTFB가 개발 환경에서 20-50ms인 것이
배포하고 나서부턴 1.5s 가량이 나와서 납득이 잘 안갔다.
결국 해결을 하긴 했지만, 정확한 원인은 아직 파악이 안갔다.
해결하기 위한 삽질기를 순서대로 적어놓으려 한다.

1. 문제 발견

문제점

• 로컬 - 20ms ~ 50ms
  
• 배포 환경 - 1.4s ~ 2.0s
  

이해가 안되는 현상이었다. Vercel로 프론트 서버를 배포하고, AWS로 백 서버를 올렸는데, 같은 페이짐에도 불구하고 둘 간의 TTFB 차이가 엄청 컸다. 1초라는 시간이 이렇게 길었나 싶은 생각이 들만큼 답답했다.

테스트

• Checkly 테스트 결과
  

  ?? 프론트 서버에 요청을 날리고 응답을 받기까지 거의 1초에 해당하는 엄청난 시간이 소요되고 있었다. 이 간극을 내가 줄일 수 있는 방법이 있을까 고민해봐도 방법이 잘 안떠올라 다른 웹사이트 분석 사이트를 들어가보니..

• https://www.webpagetest.org/ 를 통한 테스트
  

  폰트를 다운받는데 어마어마한 시간을 쓰고 있는 것이였다.
  미리 말하지만 저 빨간색에 압도되어서 저 폰트가 문제였구만! 하는 생각을 하게 되었다.
  하지만... 사실 1번에서 하늘색으로 표시된 부분이 checkly에서 확인했던 그 request와 response간의 차이이고, 그게 진짜 해결하기 위한 문제였다는 사실을 뒤늦게 알았다.

2. 폰트 로드의 문제인가?

문제라고 생각한 이유

빨간색에 압도되었다...! 와 css의 @font-face를 모르고 있었다는 점 때문에 나는 폰트 로드가 웹사이트 속도 저하의 중요한 원인이라고 생각했다.
그래도 일정한 소득은 있었는데, next의 font 최적화와 @font-face 속성에 대해 배운 것이 있어서 기록해 놓으려고 한다.

next의 font 최적화

Next.js font Optimiztion

Next.js에서는 구글 폰트를 link 태그를 이용해 가져올 경우 자동으로 font 최적화를 style태그 안의 @font-face로 최적화를 한다고 한다.
즉, 내가 링크를 걸어둔 폰트를 Next.js에서 오히려 빠르게 로드될 수 있도록 작업을 해주고 있었던 것이다. 그렇다면 head 안의 style 태그가 위 사진처럼 왜 이렇게 복잡한 것이냐.. 하면

unicode-range

• MDN | @font-face - CSS at-rule 인 @font-face 를 사용하여 웹페이지의 텍스트에 온라인폰트(online fonts)를 적용할 수 있다. @font-face 를 사용하여 웹페이지 제작자가 원하는 폰트를 사용할 수 있게함으로써, 컴퓨터에 설치된 폰트만을 사용해야했던 제약이 없어지게되었다.

이라고 설명되어 있는데, 이 형식이 왜 Next가 말하는 최적화인가는 네이버 D2코딩 | 웹 폰트 사용과 최적화의 최근 동향에 잘 적혀져 있다. 이 중 중요한 것은, unicode-range라는 속성으로 특정 필요한 글자만 다운받을 수 있다는 것이였다. 내가 필요로 하는 글자만 다운을 받으면서 최적화가 가능하다는 얘기고 그렇기 때문에 저렇게 긴 style 태그가 들어가게 된 것이였다. 나는 오히려 좋은 일을 해주고 있는 친구를 오해하고 없애려 했던 것이다.

3. 서버 리전의 문제인가

vercel과 ec2 모두 같은 리전을 쓰고 있었다

폰트에 대한 오해를 벗고 다시 문제로 돌아와서, 혹시 다른 리젼을 사용하고 있지는 않을까 하는 오해를 해봤지만, 둘다 ap-northeast-2의 서울 리젼을 사용하고 있었다. Vercel은 가끔 ap-northeast-3 오사카 리전을 사용하기는 했지만, 큰 차이가 없을것으로 판단했다.

글 발견

그렇게 답을 찾아 해메던 중 승규님 블로그을 발견했다. 그 분도 나랑 비슷한 문제로 고민하고 계셨고, stackoverflow에서 발견한 글에 따라 서버 배포하고 있는 환경에 프론트 서버를 옮기면서 해결됐다는 내용이었다.

4. 배포 환경 변경

결국 3번에서 찾은 내용대로 기존 서버를 배포하고 있던 EC2에 클라이언트 파일을 실행시켰다.
3000포트로 타겟 그룹을 설정하고, 로드밸런서로 https로 타겟 그룹으로 전달하게끔 리스너를 설정해주고,
해당 로드밸런서를 route53에서 새롭게 만든 레코드에 연결함으로서 배포를 완료했다.
기존에는 해당 레코드에 vercel의 배포 주소가 담겨있었다.

그 결과...

개발환경과 같은 수준의 속도로 TTFB가 나왔고, 사이트가 전체적으로 쾌적해졌다. 정확한 원인은 모르지만 Vercel의 프론트 서버에서 뭔가 문제가 있는 것이라고 판단하기로 했다... (Pro 버전 free trial이 있어서 그것도 해봤는데 같은 문제가 발생했다.) 원인을 알 수 있으면 정말 좋을 것 같은데... 나중에 Vercel에서 프론트 서버를 배포하는 방식을 한번 공부해보면 좋을 것 같다.

Bonus

• EC2 환경에서 pm2로 next 실행하는 법

pm2 start npm --name "next" -- start

pm2 start {npm or yarn} --name {이름} -- {명령}