웹서버를 사용한 배포와 serverless로 배포하는 방식을 다룹니다.

1. 박명호
요즘 웹 배포 방식

2. 오늘 다루는 것과 다루지 않는 것
오늘 다루는 것
- 웹을 배포하는 수많은 방식들 중 2가지를 소개합니다
- 2가지를 비교하며 장, 단점을 비교해봅니다.
오늘 다루지 않는것
- 배포하는 법
알아 가셨으면 하는 것
- 웹을 만들고 난 이후 (코딩을 한 이후) 유저에게 어떤식으로 전달 되는지
- 현업 개발자들은 배포할때 어떠한 것까지 고려하고 있는지 곁눈질 👀
오늘 설명에서 나오는 것들
- AWS의 서비스들
- Next.js Framework 기반 빌드 결과물의 폴더 구조

3. 일반적인 Next.js 배포/동작
배포/동작 인프라
도메인
로드밸런서

4. 일반적인 작동 방식
컴퓨터 (EC2, Container 등)에 Next.js Server가 뜨고 모든 요청은 (로드밸런서가 중간에서 분산해주긴 하
지만) 단일 WAS (Web Application Server)가 담당합니다.
예를 들어 Static file serving, api, Server side render 등등 모두 WAS에서 처리하여 response

5. 일반적인 Next.js 배포 방식에서의 확장

6. 위에서 설명한 시스템의 단점
기존의 프로세스 기반 아키텍처를 사용하면 이와 같은 확장이 가능하지만 상당한 단점과 과제가 있습니다.
- Auto scaling 알고리즘은 CPU 또는 메모리 사용량과 같은 상위 수준 메트릭을 기반으로 합니다. 너무 일찍부터
확장하거나, 충분히 빠르게 확장하지 않을 수 있으므로 일부 트래픽을 처리하지 못할 수 있습니다.
- 개발자는 위에서 언급한 메트릭스가 매우 동적이기 때문에 소프트웨어가 어떻게 확장되는지 정확히 이해하고 예측
하기 힘듭니다.
- 개발자는 시뮬레이션을 신중하게 실행하고 메트릭 대시보드를 설정하고 알고리즘을 미세 조정하는데 많은 시간과
리소스를 써야 할 수 있습니다.
일반적으로 서버, 워커, 컨테이너, 프로세스를 생성할 때 요청은 모두 하나의 프로세스로 결합되어 여러 코어와 컴퓨
터에 생성됩니다.

7. Serverless Component / Next.js
배포/동작 인프라

8. Serverless Component의 확장

9. Serverless Component의 장점
Next.js의 거의 모든 기능이 동작하도록 인프라 설계가 되어있다.
https://github.com/serverless-nextjs/serverless-next.js#features
- 정말로 사용하는 것 만큼만 돈을 내면 된다 (EC2나 Container가 더 저렴 할 수 있음 잘 측정해야됨)
- 가용성(서비스가 정상적으로 사용가능한 정도)/확장성(scalable)이 용이하다
- 모든 지역에서 지연시간이 매우 짧다 (lambda@edge를 사용하므로 Edge location이 있어서)
- 완전 관리형 서비스들을 이용하기때문에 서버 자체를 관리할 필요가 없다
(개발팀이 신경써야될 것이 줄어들기 때문에 개발에 더 집중할 수 있게 도와준다)
- 오버헤드 관리가 쉽다 (서버 사양을 지나치게 높게 쓰고있다던가)

10. Serverless Component의 단점
AWS Lambda를 사용하기때문에 이에대한 제약이 있다.
- Cold Start Time
- Lambda가 15분 이상 실행될 수 없다 (하나의 요청이 15분 이상 못돌아감)
- 메모리 제한
- 람다에 배포하는 패키지 크기 제한