프로젝트 리뷰 외에 개발 일지를 기록해보려고 합니다.
러프하게 수행했던 작업을 기록해보겠습니다.
최종적으로 사용한 배포 구조
들어가며
AWS EC2와 RDS를 환경 설정을 마치고 배포를 진행해봤습니다. 팀원들과 여러 배포 방식을 시도해보고 논의 끝에 최종적으로 위 사진과 같은 배포 방식으로 진행하였습니다. IntelliJ에서 깃으로 Push하면 CI/CD를 통해 EC2에서 배포가 이루어지도록 하였습니다. AWS S3와 CodeDeploy, Nginx를 통해 무중단 배포는 추가적으로 도입해보려고 합니다.
공식 문서를 통해 교차 검증을 해본 것은 아니지만 처음으로 배포를 하며 느낀점은 결국 gradle 통해 만든 *.jar 파일을 언제 서버에서 실행시키는 지가 중요하다고 생각했습니다. s3와 codedeploy를 사용할 때 필요한 파일인 appspec.yml 과 deploy.sh에서도 결국 *.jar 파일을 언제 어떻게 구동할지 서버에 지침을 내려주는 설명서라고 생각하니 배포 과정을 제 나름대로 정리할 수 있었습니다.
또한 배포 과정에서 docker의 사용 시점을 결정하는 것도 결국 .jar 파일을 언제 이미지로 만들어, 구동시킬지 결정하는 것이라고 생각했습니다. docker로 컨테이너를 구동할 경우 image 파일을 만들어야 합니다. 추후 CodeDeploy를 활용한 무중단 배포 과정에서는 .jar 파일을 EC2 상에서 직접 Docker를 통해 image를 만들 계획입니다. Docker image가 용량이 꽤 크기 때문에 위 그림의 방식처럼 docker hub에서 image를 pull 하는 대신 EC2에서 image를 build해 바로사용한다면 서버에 가해지는 부하를 조금 더 줄일 수 있지 않을까 생각합니다.
CI/CD 도구
CI/CD 도구로는 Jenkins, TravisCI, GitHub Actions 등이 있습니다. Jenkins는 설정에 많은 시간이 드는 관계로 시도해 보지 않았습니다. Travis CI와 GitHub Actions 중에서는 Traivs CI가 구현하기 쉽다는 장점이 있었지만 일정 횟수 이상으로는 유료로 사용해야만 하기 때문에 추후 사용까지 고려해서 무료인 GitHub Actions를 사용하였습니다. 그리고 이번 프로젝트 용량이 크지 않음에도 Travis CI에 비해 GitHub Actions의 속도가 월등히 빠르다는 것을 느꼈습니다.
Docker Container의 사용
배포를 찾아보며 배포 방식의 변화에 대해 알게되었습니다. 배포는 로컬 환경에서 물리적으로 서버를 구축하는 것부터 시작해 VM(Virtual Machine)을 활용한 가상화된 배포 방식에서 docker 등의 컨테이너를 활용한 배포까지 발전 했습니다.
컨테이너 방식의 배포를 통해 다음과 같은 장점을 얻을 수 있다고 합니다.
(그림 왼: 기존 VM 배포 방식) (그림 오: 컨테이너를 활용한 배포 방식)
- 가벼운 애플리케이션의 생성과 배포
- 지속적인 개발, 통합 및 배포
- 클라우드 및 OS 간의 이식성
- 리소스 격리
(출처:백엔드 개발자 장원익의 기술 블로그)
따라서 현업에서는 Docker를 통한 배포를 대부분 진행하고 있다고 합니다. 저는 아직 Docker 배포의 이점이 명확하게 와닿지는 않지만 차차 더 살을 채워가며 알아가보려고 합니다.
마치며
오늘은 배포 방식을 결정하며 생각했던 점을 간단히 기록해보았습니다. 다음 번에는 실제 어떻게 코드를 구현했는지 작성해보겠습니다.
