[프로젝트 설계] 인프라 아키텍처 구성
주말의집 프로젝트는 "듀얼리" 프로젝트의 ver2로 앞선 프로젝트에서 부족했던 부분을 개선해나가기 위해 기존 프로젝트의 문제점 파악부터 기록하려고 합니다.
듀얼리 프로젝트는 짧은 개발기간과 개발하는 구성원 모두가 대학생 신분인 점을 감안하여 최소한의 리소스를 이용하여 인프라를 구성하였습니다. AWS 플랫폼을 통해 프리티어 계정으로 EC2와 DNS, ALB, RDS, S3를 이용하였습니다. 프로젝트 운영에 필요한 모니터링 시스템과 캐싱 서버를 별도로 구축하기에는 비용 문제에 대한 우려가 있어 하나의 어플리케이션 서버에 도커 컨테이너를 통해 구동시켰습니다.
위와 같은 인프라 구성은 트래픽이 증가하면 금방 서버가 다운될 수 있는 상태입니다. 또한 자동화된 배포는 가능하지만, 무중단 배포는 불가능합니다. 따라서 서버가 CICD를 통해 배포되는 동안에는 일시적으로 서비스 운영이 중단 될 수 있습니다.
모니터링 시스템 ( Promethues와 Grafan )를 없애고 Redis, Ngnix, Spring Boot 만을 구동시키는 구성으로 변경하였습니다. 모니터링 시스템이 주는 이점도 물론 있지만, AWS CloudWatch로도 그 기능을 대체할 수 있기에 구성에서 제외하였습니다.
ver1과 크게 달라진 부분은 Nginx의 도입과 Spring Boot 어플리케이션이 2개라는 점입니다. 이번 구성의 가장 큰 핵심은 무중단 배포와 로드 밸런싱입니다. 서비스의 성격상 한 번에 많은 유저가 유입되는 것이 아닌 차츰 차츰 유입이 될 것으로 예측하고 있으며, 서버를 scale-out 하는 식의 확장을 고려하고 있어 하나의 EC2 서버에 우선적으로 무중단 배포와 로드밸런싱이 가능한지를 테스트하려 합니다.
SSL 인증서를 발급 받았기 때문에 HTTPS 프로토콜 기반으로 서비스가 운영되며 가장 앞단에서 Route 53(DNS)으로 트래픽이 들어오고 Ngnix를 통해 포트 포워딩과 로드 밸런싱을 하도록 구성하였습니다. 무중단 배포 방식은 블루-그린을 선택하였으며, 점진적 배포를 통해 서비스에 예기치 못한 상황이 발생하더라도 기존 버전으로 롤백이 가능한 구성을 하기 위함입니다.
사용기술 : NGINX, AWS - load balancer, certificate manager, ec2
- AWS load balancer 에서 80번 포트를 443 포트로 리다이렉트 시켜준다.
- certificate manager를 통해 발급 받은 ssl 인증서를 443 포트에 적용하였다.
- 443 포트로 접속 시, ec2-instance:80 으로 포워딩 한다.
- nginx를 설치하여 리버스 프록시 서버를 구축하였다.
- /etc/nginx/sites-available 경로의 설정파일을 작성하여, /etc/nginx/sites-enabled 경로로 심볼릭 링크를 설정하였다.
(프론트 정적파일에 대한 프록시는 아직 설정하지 않은 상태이다.)
사용기술 : NGINX, github actions, AWS - s3, code-deploy
- PR(feature -> dev) 시, github actions CI 실행
- merge(dev -> main) 시, github actions CD 실행
- 프로젝트 폴더(zip)을 AWS s3에 업로드한다.
- ec2 내부에 설치된 code-deploy agent에 의해서 s3에 있는 프로젝트 폴더(zip)가 ec2 내부로 배포된다.
- 프로젝트폴더/scripts 내부의 스크립트 파일을 작성하여 code-deploy가 배포할때, 처리할 작업들을 나열하였다.
- appspec.yml 을 작성하여 ec2 내부에 프로젝트 배포 경로를 지정하고, 스크립트 파일(프로젝트폴더/scripts)의 작업 순서를 지정하였다.
- run_new_was.sh -> health_check.sh -> switch.sh
1. (8081 run -> 8082 switch -> 8082 restart) or (8082 run -> 8081 switch -> 8081 restart)
2. switch 되는 포트의 서버 health check
3. NGINX 포워딩 포트 변경