의문의 시작점
현재 상황: 프론트엔드 pod와 백엔드 pod를 같은 Cluster에서 운영중
API 요청은 프론트엔드 pod에서 백엔드 pod로만 흐르는데,
왜 1) 백엔드 service에 대한 라우팅 규칙이 ingress에도 올라가고, 2) 백엔드가 ingress 트래픽을 받아야하는가? 에 대한 의문이 생겼다.
그래서 궁금해졌다. 리액트로 만들어진 웹사이트에서 API 요청을 보내면 왜 굳이 IGW를 거쳐야하는지!!
CSR과 SSR에서 등장하는 서버가 대체 뭔데?
이 의문을 풀기 위해서는 CSR과 SSR의 동작 방식에 대한 차이를 알아야한다.
CSR은 웹 브라우저에서 JS를 사용하여 웹페이지를 렌더링하는 방식이다. 사용자의 브라우저가 서버로 부터 데이터를 받아와서 직접 웹사이트를 생성한다.
SSR은 서버에서 HTML을 완성하여 브라우저로 보내는 방식이다.
참고: https://yong-nyong.tistory.com/86
[Web] CSR vs SSR vs SSG vs ISR 각 렌더링 방식 쉽게 알아보기
📖 들어가며 먼저, 웹 렌더링(Web Rendering)이란 웹 페이지를 사용자에게 보여주는 과정을 의미합니다. 이 렌더링 방식에 따라서 로딩 속도, 검색 엔진 최적화(SEO), 사용자 경험 등이 달라집니다.
yong-nyong.tistory.com
CSR에서도 서버가 등장하고, SSR에서도 서버가 등장한다. 여기서 서버란 대체 뭘까??!
내가 정의한 CSR과 SSR 방식의 서버는 다음과 같다.
CSR방식에서는 보통 Nginx를 웹서버로 두고, NodeJS 기반으로 React 이미지를 만든다. 그래서 CSR방식의 서버는 Nginx이다.
SSR 방식의 서버는 Next.js가 작동하는 서버이다. 아마 Node.js가 될것이다.
CSR과 SSR에서 API 요청의 주체는 무엇일까?
CSR에서 API 요청의 주체는 브라우저이다.
프론트엔드 개발자라면 한번쯤은 개발자 도구에서 API 요청이 제대로 흘러갔는지 봤을것이다.
이것을 볼 수 있다는 것 자체가 API 요청의 주체가 브라우저라는 것이다.
브라우저가 요청을 보내기 때문에 백엔드로 이 요청이 들어가려면 IGW를 거칠 수 밖에 없다.
SSR의 경우 API 요청의 주체는 프론트엔드 서버이다. SSR로 Next.js를 쓰고 있다면 주체가 Next.js가 될 것이다.
CSR과 SSR은 백엔드 서버까지 API 요청이 어떻게 흘러갈까?
앞서 [의문의 시작점]에서 봤던 상황으로 되돌아가보자.
프론트엔드 pod과 백엔드 pod이 같은 K8s Cluster에 있다고 가정하고 API 요청을 보내보자.
CSR 방식은
브라우저 → IGW → ALB Ingress → ALB Ingress가 트래픽을 프라이빗 서브넷 안에 있는 K8s Cluster의 백엔드 pod으로 전달
SSR 방식은 프론트엔드 pod → K8s Service(Cluster IP) → 백엔드 pod
결론
CSR방식은 API 요청의 주체가 브라우저이기 때문에 IGW를 거칠 수 밖에 없다.
만약 K8s Cluster안에 프론트엔드 pod와 백엔드 pod가 모두 작동중인데 ALB Ingress를 통해 트래픽을 분산시킨다면 프론트엔드 pod, 백엔드 pod 모두 Ingress 라우팅 규칙에 추가하고, Service타입은 NodePort로 맞춰줘야 브라우저 (외부)에서 오는 트래픽을 받을 수 있다!