Reduce initial server response time: TTFB 속도가 너무 느림

[Yelihi]

issue

• closet의 모든 페이지의 TTFB(Time to First Byte) 속도가 너무 느림 (1.5s 이상까지)
• 현재 사용중인 was 는 aws ec2 prettier / aws amplify 에 hosting 중(cloudfront).
• 어쩔 수 없는 prettier 의 한계인지 혹은 next.js 내 최적화 할 수 있는 부분이 있는지 원인 분석이 필요함.

[Yelihi]

https://github.com/aws-amplify/amplify-hosting/issues/2127 https://github.com/vercel/next.js/discussions/38012

• ssr 어플리케이션에 대한 amplify 의 느린 build 속도관련 이슈

[Yelihi]

1. ec2 server 재시동

• 재시동을 하니 전체적으로 TTFB 속도가 줄어들긴 하였다. 하지만 간헐적으로 느려진 현상은 지속되고 있음

[Yelihi]

접근사항

• t2.micro 내 swap 활용 2g free ram 확보 (그럼에도 느림)
• t2.micro -> t3.micro 변경(속도 향상 체감. 다만 번번히 TTFB 가 4~5초 넘어가기도 함)
• t3.micro -> t3.small 변경 (속도 향상 체감. 가끔 느려지긴 하지만 대체적으로 빠름)
• 현재까지의 결과로 봤을 땐 ec2 server 의 하드웨어 성능 문제였다고 판단
• 다만, image 업로드 시간은 여전히 느리고, amplify 에서 cache 를 진행할텐데.. 계속 miss from cache 가 발생
• SSR 은 cache 가 불가능 한것인지 파악할 필요가 있어보임

9/9

• 이상하게 첫 페이지 로딩이 느리다. 이후 접근시 꽤 빠른 페이지로딩을 보여준다.
• 이 현상은 위처럼 EC2 성능을 업데이트 시킨것으로는 해결되지 않고 있다.
• 생각해볼 수 있는 방법은 현재 Amplify 내 호스팅 된 서버를 EC2 로 변경하는 방법밖에는 잘 떠오르지 않고, 설사 변경한다고 해서 해결된다는 보장을 할 수 없겠다

[Yelihi]

https://github.com/vercel/next.js/discussions/32243

• 우선 SSR 의 불필요한 로직은 없는지 검수를 해본다
• Link 를 통한 router 시, SSR 페이지의 경우 서버에서 데이터를 fetch 한 다음, 작업이 마무리 되고 페이지가 생성이 되어서야 navigate 해준다. 이 과정을 끊어버리는 방법에 대하여 고민해보자 (즉, SSR 페이지라도 데이터 Fetch 가 되기전에는 loading 페이지를 보여주기. 실제 app routing 에서는 server component 와 suspense 를 통해 가능하다고 한다)
• 현재 SSR 을 사용하는 주된 이유는 사용자 인증 시 깜박임 현상을 없에기 위함인데, 그게 안된다면 차라리 client 단에서 인증 및 디바이스 변경이 진행 되기 전까지는 Loading 페이지를 보여주는 방식을 고려해보자. (즉 SSR 함수를 삭제하기)

[Yelihi]

9.20

• 위 사항을 먼저 확인하기 전 amplify 의 효용성에 대해 생각해본 결과. 비용적인 부분에서 vercel 보다 유용하긴 하나 현재 나의 어플리케이션에서 유의미한 요금 차이를 고려할 사항은 아니라 판단
• 따라서 우선 vercel 로 호스팅을 변경해본다
• 이후 만일 vercel 역시 SSR 에서 지연된 속도가 발견된다면, 이후에는 2가지를 고려해본다
• SSR을 활용해야하는 이유와 이를 탈피할 수 있는 방법.
• 혹은 SSR 을 유지하되 EC2 인스턴스로 대체하여 성능을 향상시키기

https://stackoverflow.com/questions/73700854/nextjs-amplify-slow-server-response https://www.reddit.com/r/aws/comments/q15t5c/aws_amplify_vs_vercel_for_nextjs_ssr_hosting/

[Yelihi]

10.16

• 원인이 아마 gssp 에 의한 server response time 증가라고 판단된다
• gssp 를 amplify 내 호스팅 할 경우, serverless function 으로서 lambda 를 호출하게 된다
• serverless function 의 경우 origin server 에 직접 접근해야하기에 TTFB 가 오래걸릴 수 있다
• 허나 현재 난 amplify 의 origin 이 seoul 이며 이렇기에 origin 이 큰 문제가 된다고 판단할 수 없다
• 현재 amplify 내에서도 현 issue 가 최우선적으로 진행되고 있고, 이에 대한 피드백은 현재까지 없는 상태이다(몇 달이 지났는데도..)
• 일시적인 방안으로는 이러한 serverless function 의 cold start 를 warm 하게 만들어 주는 방안을 떠올려야 한다
• 가장 대중적인 방법으로는 지속적인 lambda 호출을 통해 warm 상태를 유지하는 방안이 있다.
• 이는 Route53 의 Health check 를 통해 지속적인 URL 상태 점검으로 진행이 가능하다고 한다
• 즉, 도메인에 접근하면 이에 따라 gssp 가 실행이 되고, 이를 유지하여 warm 상태로 만든다는 의미
• 다만 문제가 있는것이, login page 를 설사 warm 하게 하였다 한들, 나머지 페이지의 gssp 는 어떻게 해야할지 아직 의문이다
• 또한 호출 비용을 고려하면 가장 단순한 코드를 호출하는것이 비용이 적게 드는데, 이를 위해 dummy page 인 api/health 를 생성한 뒤 실행시킬 때의 실행 API 는 gssp 와의 별개의 lambda 라는 말이 있어서 결국 이것도 효용이 없는 듯 하다.

[Yelihi]

https://blog.gushwork.ai/post/how-to-fix-cold-start-problem-for-next-js-ssr-websites-hosted-on-aws-amplify

이것도 참고해보자

[Yelihi]

10.17

• 모바일 환경과 데스크탑 환경에서 첫 userLogin 페이지 접근 시 health check 를 해주지 않았을 때보다는 server response 가 더 짧아진 느낌이 든다
• 기존 : 3~4 s
• 현재 : 600ms~ 1.2s (약간의 편차가 있다)
• 다만 아쉬운 점은 store page 나 add page 의 경우 아직까지 만족할만한 속도를 보여주진 않는다.
• 모바일 환경은 생각보다 store, add 등 gssp 실행 페이지에서도 400ms 이하 수준의 속도를 보여주었음

[Yelihi]

10.21

• 모바일과 데스크탑의 userAgent 를 활용하여 레이아웃을 변경하려 하였으나 amplify 의 경우 자동으로 amazon amplify 로 파싱하는 문제가 있었고, Link tag 을 통한 빠른 이동시 gssp 의 props 가 {} 를 반환하는 문제도 있고, health check 를 해주고 있지만 그럼에도 여전히 느린 속도까지 더해 더 이상 amplify hosting 을 이어가야할 이유를 얻지 못해 vercel 로 변경하게 되었다
• vercel 변경 후 여전히 속도가 느리다가, 지역을 한국으로 변경한 다음 속도가 좀 더 빨라짐을 확인할 수 있었다
• 다만 모바일 환경 내에서는 여전히 초기 cold start 가 문제가 되긴 하였다
• velcel 로의 이동의 또하나의 목적은 edge runtime 을 활용하여 cold start 를 대폭적으로 감소시키고자 하는 의도가 있었다
• 다만 현재 edge runtime 은 axios 내 오류, 폰트 이슈 등이 있어서 좀 더 테스트를 해보고 도입하고자 한다