SPA 기능을 구현하는 웹 페이지의 CI/CD Pipeline

여태까지 소개했던 배포 방식은 순수하게 Spring boot를 통해

WAS나 정적 페이지 혹은 어떻게 API를 구축하고 배포할지에 대한 내용이었다.

 

이제 여기에 프론트엔드의 작업물인 CSR 웹 페이지를 반환하고,

여기에 API 까지 같이 구축하는 CI/CD 다이어그램를 구축해보면 아래의 그림과 같다.

 

 

 

기본적인 CI/CD의 흐름은 지난번 글들에서 소개한 Github Action을 사용한 CI/CD 파이프라인을 구축한 것과

동일한데, 몇 가지 추가 사항 및 변동 사항이 있다.

 

1. AWS S3의 사용

AWS는 정적 데이터를 제공하는 S3라는 서비스를 제공한다.

이를 통해 HTML, CSS, JS, 이미지, 영상, 폰트 등을 제공할 수 있다.

React로 만들어낸 CSR페이지와 같은 경우에도, npm run build, 즉 빌드를 하게 되면

하나의 번들링된 HTML, CSS, JS파일을 얻을 수 있다. 이렇게 번들링을 한 3개의 파일을 S3에 올려놓으면

유저들에게 SPA기능을 제공하는 페이지를 제공 할 수 있다.

 

2. Docker의 부분적 사용

S3를 사용할 경우, 자바처럼 굳이 실행환경이 필요하지 않으므로 Docker를 사용할 필요가 없다.

그렇기 때문에 Docker Hub에 push 또는 pull을 할 필요가 없다. (즉, Registry도 필요 없어 진다.)

BE의 빌드파일만 이미지화 한 뒤 docker에 올리면 된다.

 

 

 

Spring Boot가 CSR 정적 페이지를 배포하는 것도 가능한가?

➡️ 가능하다. 아래의 그림과 같이 구축하면 된다.

 

이와 같은 방식으로 하게 됐을 경우, 특이할만한 점은

 

1. HTML, CSS, JS가 번들링된 build 가 먼저 진행되어야 하고,

2. 그 진행된 build 파일들을 받아서 이를 포함한 상태의 Tomcat 서버를 build해 JAR파일을 생성해야 한다는 것이다.

3. 그리고 S3를 통한 정적 데이터 반환을 하지 않고, 서버가 페이지의 반환까지 전부해주어야 한다.

 

즉, EC2의 Tomcat 서버가 정적 페이지 반환 및 API 호출까지 모두 해줘야 하기 때문에

트래픽이 많아지는 것은 어쩔 수 없지만 이렇게 하는 것 또한 가능하다.

 

그렇게 될 경우 트래픽 분산을 위한 로드밸런서(AWS의 경우, ELB를 사용한다.)의 사용을 생각해 볼 수 있다.