[Spring] 스프링 프로젝트 AWS로 무중단 배포 자동화하기 (Travis CI, CodeDeploy, S3, Nginx)

스프링 프로젝트 AWS로 무중단 배포 자동화하기

해당 스프링 프로젝트 배포 흐름 과정은 추후에 계속해서 보려고 스프링 부트와 AWS로 혼자 구현하는 웹 서비스의 내용을 정리한 글입니다.

 

스프링 프로젝트 AWS로 배포 자동화하기

 

0.  AWS EC2, RDS 인스턴스 생성하기

대게 수많은 프로젝트들은 AWS라는 클라우드 서비스를 이용해 서버 배포를 진행한다. 왜냐하면 외부에서 본인이 만든 서비스를 접근하려면 24시간 작동하는 서버가 필요하기 때문이다. 24시간 작동하는 서버에는 3가지 선택이 있다.

1. 집에 PC를 24시간 구동시킨다.
2. 호스팅 서비스(Cafe 24, 코리아호스팅 등)을 이용한다.
3. 클라우드 서비스(AWS, AZURE, GCP 등)을 이용한다.

일반적으로 비용은 호스팅 서비스나 집 PC를 이용하는 것이 저렴하다. 만약 특정 시간에만 트래픽이 몰린다면 유동적으로 사양을 늘릴 수 있는 클라우드가 유리하다. 클라우드에 대해서 잠깐 이야기 하자면, 클라우드 서비스는 쉽게 말하면 인터넷(클라우드)을 통해 서버, 스토리지(파일 저장소), 데이터베이스 네트워크, 소프트웨어, 모니터링 등의 컴퓨팅 서비스를 제공하는 것이다.

 

[Spring 배포 #0-1] AWS EC2 인스턴스 생성 후 접속하기

[Spring 배포 #0-2] AWS RDS 인스턴스 생성하기 및 EC2와 연동하기

 

1.  AWS EC2 서버에 스프링 프로젝트 수동으로 배포하기

토이 프로젝트로 배포만 한 번 해보고 싶다면 해당 단계까지만 진행해도 무난하다. EC2서버에 스프링 프로젝트를 올려 RDS와 연동 시킨 다음 실제 배포까지 진행한다. 이 단계까지만 진행해도 실제 클라이언트들이 다양한 외부 환경에서 EC2 주소를 통해 나의 서비스에 접속할 수 있다. 그러나 만약 테스트가 아닌 실 서비스 유지를 위해서는 자동 배포화까지 진행해줘야 한다.

 

AWS EC2 서버에 스프링 수동 배포하기

1) EC2 서버에 수동 배포하기

수동 배포란 직접 EC2 서버에서 배포 스크립트를 실행하여 배포를 진행하는 방법을 말한다. 프로젝트에 변경사항이 있으면 Git에 Push한 후 다시 EC2에 접속하여 직접 재배포를 진행해줘야 한다.

 

1-5) RDS(Maria DB)와 EC2 연동하기

로그인이나 게시판과 같은 DB를 사용하는 기능이 있는 프로젝트라면 RDS와 EC2에 연동하는 방법이다. EC2 서버와 연동하기 전에 RDS 인스턴스 생성을 해놓고 로컬에서 미리 DB접속이 되는지 테스트해봐야한다. 

 

[Spring 배포 #1] AWS EC2 서버에 스프링 프로젝트 수동으로 배포하기

 

2.  배포 자동화 준비 : Travis-ci, S3, AWS CodeDeploy 연동

24시간 365일 운영되는 서비스에서 배포 환경 구축은 필수이다. 여러 개발자의 코드가 실시간으로 병합되고, 테스트가 수행되는 환경, master 브랜치가 푸시되면 배포가 자동으로 이루어지는 환경을 구축하지 않으면 실수할 여지가 너무나 많기 때문에 자동화 배포 환경 구성을 해줘야 한다.

 

배포 자동화하기 : Travis-ci, S3, AWS CodeDeploy 연동

CI & CD

코드 버전 관리를 하는 VCS 시스템(Git, SVN 등)에 PUSH되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정을 CI(Continuous Integration - 지속적 통합)라고 하며, 이 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정을 CD(Continuous Deployment - 지속적 배포)라고 한다.

 

1) Travis-ci, S3 생성 및 연동하기

Travis CI는 Git에서 제공하는 무료 CI서비스이다. Jenkins와 같은 CI도구도 있지만 설치형이기 때문에 이를 위한 EC2 인스턴스가 하나 더 필요하다. 초기 서비스에서 배포를 위한 EC2 인스턴스는 부담스럽기 때문에 오픈소스 웹 서비스인 Travis CI를 사용한다.

* AWS CodeBuild도 있지만 빌드 시간만큼 요금이 부과되기 때문에 초기 서비스엔 사용하기 부담스럽다.

 

Travis CI이 해줄 역할은 스프링 프로젝트를 Test, Build, Notify를 해주는 것이다.

• Test : 스프링 프로젝트를 테스트해준다.
• Build : 스프링 프로젝트를 빌드해준다.
• Notify : Build 완료나 에러 결과를 이메일 혹은 Slack과 같은 메신저로 알림을 준다.

 

S3란 AWS에서 제공하는 일종의 파일 서버이다. 이미지 파일을 비롯한 정적 파일들을 관리하거나 지금 진행하는 것처럼 배포 파일들을 관리하는 등의 기능을 지원한다. 보통 이미지 업로드를 구현할 때 S3를 많이 사용한다.

 

실제 배포는 AWS CodeDeploy라는 서비스를 통해서 진행한다. S3연동이 먼저인 이유는 Jar(실행 파일)을 전달하기 위해서이다.

 

2) CodeDeploy 생성 및 Travis-ci, S3, CodeDeploy 연동

이제 AWS 배포 시스템 CodeDeploy를 생성해준다. 해당 과정에서는 총 2개의 IAM(ec2에 필요한 IAM, codeDeploy에 필요한 IAM)을 생성한다. 이제 CodeDeploy를 이에 연동시켜주면 거의 모든게 끝이난다. EC2 환경에 파일을 받을 디렉토리 생성과 몇 가지 설정을 추가해주면 된다.

 

[Spring 배포 #2-1] Travs-ci, S3 생성 및 연동하기

[Spring 배포 #2-2] CodeDeploy 생성 및 연동하기 (Travs-ci, S3)

 

3.  스프링 프로젝트 실제 배포 자동화하기

2번에서는 연동까지만 진행하였다. 연동하는 과정만 빠르게 체크하기 위해서 EC2에 보낸 파일은 스프링 프로젝트 전체를 묶어서 보냈다. 이제 그 파일을 실제 배포에 필요한 파일들로만 구성해서 보내주면 된다.

 

실제 배포 자동화 시키기

1)  스프링 프로젝트 실제 배포 자동화하기

이제 실제 배포 파일 (jar + 기타 설정 파일)을 보내서 배포한다. 그 후 실제로 변경사항을 Git으로 푸시하면 그대로 변경사항이 반영되어 자동 배포되는 과정을 확인할 수 있다.

 

[Spring 배포 #3] 스프링 프로젝트 실제 배포 자동화하기

 

4.  Nginx로 블루-그린 무중단 배포하기

이제 git pull만 해주면 ec2 서버에 자동으로 배포해주는 환경까지 구축을 완료했다. 하지만 새로운 Jar가 실행되기 전까지 기존 Jar를 종료시켜 놓기 때문에  새로운 버전을 배포하는 동안 기존 운영되는 애플리케이션이 종료된다는 문제가 남았다. 그래서 유연한 UX환경을 위해 Nginx를 통해 무중단 배포를 설정해주면 된다.

 

 

1)  Nginx로 스프링 프로젝트 블루-그린 무중단 배포하기

EC2 프리티어 1대로 구성하여 Port를 나눠 블루-그린 배포 방식으로 무중단 배포를 진행한다. 구조는 EC2 혹은 리눅스 서버에 Nginx 1대와 스프링 배포 파일 Jar 2대를 사용하여 각 다른 port를 할당해 사용한다.

 

[Spring 배포 #4] Nginx로 스프링 프로젝트 블루-그린 무중단 배포하기

 

무중단 배포 자동화에 생성한 파일 및 인스턴스 정리

최종으로 파일 및 인스턴스를 정리하면 다음과 같다. step 1~3은 과정에 맞춰 생성한 폴더이고 실제로 무중단 배포 자동화 환경을 구축하기 위해서는 step3 폴더만 필요하다.

 

무중단 배포 자동화에 생성한 파일 및 인스턴스 정리

 

끄적...

스프링 배포를 해보려고 여러 문서를 찾는 데 감사하게도 많은 시행착오들을 공유해주고 있었으나 1-100 모든 과정이 이어진 자료도 찾기 힘들고 믿고 모든 과정을 답습하기에는 리스크도 존재했다.(향로님 블로그 알기 전) 좀 더 찾아보고 그냥 무작정 들이 받아보자고 생각하던 찰나 스프링 부트와 AWS로 혼자 구현하는 웹 서비스라는 책을 접하게 되었고 내가 원하던 내용이 1-100 모든 과정이 잘 정리되어 있었다.  블로그보다 책이나 공식문서가 더 신뢰가 가는 건 어쩔 수 없다. 덕분에 배포 작업에 있어서 큰 도움을 받았다.

 

---

참고

스프링 부트와 AWS로 혼자 구현하는 웹 서비스