안녕하세요. E-Market 인프라 시리즈를 이어가는 세 번째 시간입니다. 지난 두 편에서는 Jenkins를 이용한 CI/CD 파이프라인 구축과 Spring Boot Actuator, Prometheus, Grafana를 활용한 모니터링 환경 구축에 대해 다루었습니다. 이번 포스팅에서는 CI/CD 파이프라인의 CD(Continuous Delivery) 부분을 개선하여, Jenkins를 이용한 무중단 배포 설정과 Docker 기반의 서버 실행 방식으로 전환한 내용을 공유하고자 합니다.
기존에는 Jenkins가 빌드된 jar 파일을 EC2 인스턴스에 직접 전달하고, 기존 애플리케이션을 중지한 후 새로운 jar 파일을 실행하는 방식으로 배포를 진행했습니다. 이 방법은 서비스 중단 시간이 발생하고, 배포 과정에서 예상치 못한 문제 발생 시 복구에 어려움이 있었습니다. 따라서 서비스 안정성과 운영 효율성을 높이기 위해 무중단 배포를 구현하고, Docker를 활용하여 더욱 안정적이고 효율적인 배포 시스템을 구축하게 되었습니다.
우선, 무중단 배포를 위해 blue-green deployment 전략을 채택했습니다. 두 개의 동일한 EC2 인스턴스(blue, green)를 준비하고, blue 인스턴스를 운영 서버로 사용합니다. Jenkins는 새로운 애플리케이션을 빌드하여 Docker 이미지로 생성하고, 이 이미지를 green 인스턴스에 배포합니다. 배포 후, 충분한 테스트를 거쳐 green 인스턴스를 운영 서버로 전환하고, blue 인스턴스는 대기 상태로 유지하여 롤백이 필요한 경우 즉시 복구할 수 있도록 준비합니다. 이를 통해 서비스 중단 없이 새로운 버전의 애플리케이션을 배포할 수 있게 되었습니다.
또한, 기존의 jar 파일 기반 배포 방식에서 Docker 이미지 기반 배포 방식으로 변경함으로써, 환경 설정의 일관성을 확보하고, 서버 환경 변화에 따른 재배포 작업을 최소화했습니다. Dockerfile을 통해 애플리케이션 실행에 필요한 모든 의존성을 이미지에 포함시켜, 배포 환경의 차이로 인한 문제 발생을 예방할 수 있었습니다. Jenkins는 Docker 이미지를 생성하고, Docker Registry에 업로드하며, green 인스턴스에 배포하는 과정을 자동화하여 운영 효율성을 크게 향상시켰습니다. 참고로 저희 서비스는 EC2 인스턴스를 infra, Dev, DB 세 개로 분리하여 운영하고 있습니다. 이는 개발, 운영 환경의 분리와 데이터베이스 관리의 효율성을 높이기 위함입니다. 각 인스턴스의 역할과 분리 방식에 대한 자세한 설명은 다음 포스팅에서 다루도록 하겠습니다.
이번 개선을 통해 E-Market 서비스의 안정성과 확장성이 크게 향상되었습니다. 앞으로도 지속적인 모니터링과 개선을 통해 더욱 안정적이고 효율적인 서비스 운영을 위해 노력하겠습니다. 다음 포스팅에서는 Docker Registry 관리 및 더욱 발전된 CI/CD 파이프라인 구성에 대해 이야기하겠습니다. 많은 관심 부탁드립니다.