개요
유니버설 렌더링
웹 애플리케이션에서 초기 로딩은 서버에서 완성된 HTML을 렌더링하여 빠르게 처리하고, 이후 상호작용은 클라이언트(브라우저)에서 렌더링하여 빠른 페이지 이동을 가능하게 하는 하이브리드 방식으로 대표적인 프레임워크로 Next, Nuxt가 있다.
내가 담당하고 있는 서비스 대부분 유니버설 렌더링 방식을 사용하고 있다. HTML에 포함된 정적 자원을 CDN을 통해 서비스하고 있는데 관련해 개선하면 좋을 것 같은 부분이 있어 정리했다.
CDN 기존 구조
정적 자원을 서빙하기 위한 별도 Static 서비스를 구성했다. 어떤 흐름으로 동작하는지 나열하면,
1) HTML(페이지) 요청 흐름 - SSR
- 브라우저가 서비스 도메인으로 접속
- 요청이 ALB로 전달됨
- ALB가 EKS Pod(서비스)로 라우팅
- Pod 안의 웹 서버 컨테이너가 서버 사이드 렌더링(SSR)을 수행해서 완성된 HTML을 생성
- HTML을 브라우저로 응답
2) 정적 자원 요청 흐름 - CloudFront 캐시
- 브라우저는 받은 HTML을 파싱하면서
<script>,<link>,<img>같은 정적 자원을 CDN 도메인으로 요청 - Cache Hit → 바로 응답
Cache Miss → 원본(Origin)인 서비스 도메인에서 다시 가져온 후 캐시하고 브라우저에 응답
위의 “2) 정적 자원 요청 흐름”으로 동작하기 위해 Nuxt, Next build 옵션 중 관련 설정값을 찾아 입력한다. Nuxt의 경우 publicPath에 CDN URL을 입력한다. 그러면 빌드 시 <script>, <link>, <img> 의 src나 href에 CDN URL이 Prefix 형태로 붙는다.
위 구성에서의 단점?
서비스 도메인, 정적 자원용 CDN 별도 도메인 두 개를 관리해야 하며 결과적으로 운영 복잡도가 증가한다.
CDN 개선 구조
서비스 도메인이 ALB에 직접 붙는 형식이 아니라, CloudFront를 통해 접근하는 형태로 특정 경로 별(예, /_nuxt/*)에 각각 캐시 전략을 부여할 수 있다. 이때, 사용자별 동적으로 생성되는 데이터는 캐시 되지 않도록 주의해서 경로별 캐시 설정을 진행해야 한다.
위 개선으로 얻을 수 있는 이점?
관리해야 할 도메인, 인증서가 2개에서 1개로 줄어들면서 아키텍처 구조가 단순해지고 단일 도메인을 사용하기 때문에 별도 보안 설정(CORS 등)이 필요 없다.