이 편에서 만드는 파일

개념 편입니다. 새로 만들거나 고치는 파일이 없습니다. 09편에서 이 편의 원리를 실제 코드로 재현합니다.

개념 정리

요청이 몰리면 인스턴스가 늘어난다

01편에서 정리한 컴퓨트는 요청을 처리하는 실행 단위입니다. 동시에 들어오는 요청이 적을 때는 인스턴스 하나로 충분하지만, 트래픽이 늘면 Amplify Hosting은 요청을 나눠 처리할 컴퓨트 인스턴스를 추가로 띄웁니다. 정확히 몇 개가 언제 뜨는지는 AWS가 세부 구현으로 공개하지 않지만, 확실한 사실 하나는 남습니다. 동시에 여러 인스턴스가 병렬로 요청을 처리한다는 것입니다.

같은 시각에 보낸 두 요청이 같은 인스턴스로 간다는 보장이 없습니다. CloudFront가 캐시 MISS인 요청을 컴퓨트로 넘길 때마다, 그 요청은 A·B·C 중 어느 인스턴스로든 갈 수 있습니다.

인스턴스마다 격리된 로컬 캐시

각 인스턴스는 자신만의 메모리 공간과 파일시스템을 갖습니다. 코드 안에서 모듈 스코프 변수에 값을 저장하거나, 파일을 직접 읽고 쓰는 방식으로 캐시를 흉내 내면, 그 값은 그 인스턴스 안에서만 유효합니다. 다른 인스턴스는 그 값을 전혀 알지 못합니다.

0608편에서 확인할 데이터 캐시·전체 라우트 캐시·요청 메모이제이션은 기본 설정에서 모두 인스턴스 로컬입니다. 인스턴스 하나만 떠 있을 때는 문제가 드러나지 않습니다. 인스턴스가 여러 개로 늘어나야 비로소 “같은 데이터인데 인스턴스마다 다른 값이 나온다”는 현상이 생깁니다. 이 표의 마지막 행(외부 데이터베이스)이 1213편에서 다룰 해결 방향입니다.

CDN 캐시와 컴퓨트 로컬 캐시의 차이

01편에서 본 CloudFront 캐시는 이 문제와 무관합니다. CloudFront 캐시는 인스턴스 개수와 상관없이 하나의 공유 계층입니다.

09편에서 재현할 문제

09편은 조회수처럼 애플리케이션이 직접 관리하는 상태를, 응답에 인스턴스 식별자(process.pid 등)와 함께 실어 보내는 방식으로 이 현상을 직접 확인합니다. 짧은 시간에 반복 요청을 보냈을 때 식별자 값이 요청마다 바뀐다면, 그 요청들이 서로 다른 인스턴스에서 처리됐다는 뜻입니다. 그 상태에서 각 인스턴스가 응답한 조회수 값을 함께 비교하면, 인스턴스가 바뀔 때마다 값도 따로 늘어나는 것을 눈으로 확인할 수 있습니다.

직접 해보기

자주 하는 실수

확인 문제

참고 자료

• Next.js Docs — Caching and Revalidating (Previous Model)