[AreYouTravelers] 시스템 아키텍처

 

✨ 아키텍처 흐름

🔔 배포 흐름

코드 수정 후 깃허브에 push하면 Github Actions 트리거가 동작하여 빌드 및 DockerFile, deploy.sh, application.yaml 등을 포함하여 zip 파일을 생성한다.
생성된 zip파일은 S3에 업로드되고 CodeDeploy에 배포 요청을 보내면 S3에 업로드 된 zip파일을 EC2에 배포한다. 
EC2 인스턴스에서 DockerFile을 통해 이미지가 만들어지고 Docker 컨테이너에 애플리케이션과 Redis가 띄워진다.
Spring Boot 애플리케이션과 Redis는 동일한 Docker 네트워크에 연결되어 실행된다.
 
 
우리 서비스는 처음에는 MVC로 구현되었다가 Rest API로 리팩토링을 하였는데 모든 도메인이 리팩토링이 되지 않았기 때문에 mvc와 Rest API가 섞여있어 사용자 <-> 프론트 <-> 백엔드 흐름이 2가지로 나뉜다.
 
 

🔔 사용자 ↔ 프론트 ↔ 백엔드 흐름

Model을 사용하여 구현된 부분의 흐름은 다음과 같다.
Client로부터 요청이 들어오면 Route 53에서 해당 요청을 ALB로 라우팅을 하는데, 이 과정에서 Client가 HTTPS 요청을 한 경우 ALB용 SSL 인증서로 인증을 한다. ALB는 EC2로 연결되며 동적으로 생성된 페이지를 클라이언트에게 반환한다. 이때, 이 페이지에 필요한 정적 파일은 링크로 포함되어 전달된다.
클라이언트는 EC2로부터 받은 페이지를 해석하고, 필요한 정적 파일을 다시 요청하며 이 요청은 다시 Route 53으로 들어간다. Route 53은 정적 파일에 대한 요청을 CloudFront로 라우팅하며 이때도 HTTPS 요청인 경우 CloudFront용 SSL 인증서로 요청을 처리한다. CloudFront에 캐시된 정적 파일이 있는 경우 캐시된 파일을 반환하며, 캐시된 정적 파일이 없는 경우 S3에서 정적 파일을 직접 받아와 클라이언트에게 반환한다.
 
Rest API로 구현된 부분의 흐름은 다음과 같다.
Client로부터 요청이 들어오면 Route 53에서 해당 요청을 CloudFront로 라우팅한다. 이때 HTTPS 요청의 경우 SSL 인증서로 요청을 처리하는 과정은 동일하다. 마찬가지로 CloudFront가 정적 파일을 반환하는 과정도 동일하다. 정적 파일만을 반환받은 클라이언트의 JS (ex. Fetch API)가 특정 데이터를 가져오기 위해 API에 요청을 보낸다. 이 요청은 Route 53으로 전달되어 ALB로 라우팅된다. 이때도 HTTPS 요청인 경우 인증하는 과정은 같다. ALB는 요청을 수신하고 해당 요청을 백엔드 서버의 컨트롤러로 전달한다. 컨트롤러가 요청을 처리하고 요청받은 데이터를 JSON 형식으로 클라이언트에게 반환한다. 그리고 클라이언트는 반환받은 JSON 데이터를 통해 화면을 동적으로 업데이트한다.