1117 Spring Boot 배포 전략: 프로파일, 멀티 스테이지 빌드, 무중단 배포
✅ 1. 프로파일 (Profiles): 환경별 설정 분리
-
프로파일은 애플리케이션을 실행하는 환경(Environment)(e.g., 개발, 테스트, 운영)에 따라 서로 다른 설정을 적용할 수 있게 해주는 Spring의 강력한 기능입니다.
-
문제점: 개발 환경에서는 로컬 DB를 사용하고, 운영 환경에서는 실제 운영 DB를 사용해야 합니다. 이러한 환경별 설정 정보(DB 주소, 비밀번호 등)를 하나의 파일에서 관리하거나, 배포 시마다 수동으로 변경하는 것은 매우 비효율적이고 실수가 발생하기 쉽습니다.
-
해결책:
application-{profile}.yml(또는.properties) 형식의 파일을 사용하여 환경별 설정을 분리합니다.application.yml: 모든 환경에서 공통으로 사용될 설정.application-dev.yml: 개발(development) 환경에서만 사용될 설정.application-prod.yml: 운영(production) 환경에서만 사용될 설정.
➕ 프로파일 활성화 방법
- 어떤 프로파일을 활성화할지는
spring.profiles.active속성을 통해 지정합니다.
-
application.yml에 기본값 지정:spring: profiles: active: dev # 기본으로 dev 프로파일 활성화 -
JAR 실행 시 옵션으로 지정 (가장 일반적인 방법):
# dev 프로파일로 실행 java -jar -Dspring.profiles.active=dev my-app.jar # prod 프로파일로 실행 java -jar -Dspring.profiles.active=prod my-app.jar
- 장점: 코드 변경 없이, 실행 시점의 옵션만으로 각기 다른 환경에 맞는 설정을 동적으로 적용할 수 있어 배포의 유연성과 안정성이 크게 향상됩니다.
✅ 2. Docker 멀티 스테이지 빌드 (Multi-stage Builds)
-
문제점:
Dockerfile하나로 소스 코드를 빌드하고, 그 결과물(JAR 파일)을 포함한 최종 이미지를 만들면, 이미지 내에 빌드 과정에서만 필요했던 불필요한 파일들(소스 코드, Gradle/Maven 캐시 등)이 그대로 남아있게 됩니다. 이로 인해 최종 이미지의 크기가 매우 커지고, 보안에 취약해집니다. -
멀티 스테이지 빌드:
Dockerfile내에서 여러 개의FROM명령어를 사용하여, 빌드 단계를 여러 "스테이지(Stage)"로 나누는 기술입니다.
➕ 동작 원리
-
빌드 스테이지 (Build Stage):
- JDK가 포함된 무거운 베이스 이미지 위에서, 소스 코드를 복사하고 Gradle이나 Maven을 사용하여 프로젝트를 빌드합니다. (JAR 파일 생성)
- 이 스테이지는 오직 빌드만을 위한 임시 공간입니다.
-
최종 스테이지 (Final Stage):
- JRE만 포함된 매우 가벼운 베이스 이미지(e.g.,
openjdk:17-jre-slim)에서 시작합니다. COPY --from=[빌드 스테이지 이름]명령어를 사용하여, 빌드 스테이지에서 생성된 JAR 파일만을 이 최종 스테이지로 가져옵니다.- 최종 이미지는 이 가벼운 스테이지를 기반으로 생성됩니다.
# 1. 빌드 스테이지 (as builder 라는 이름 부여) FROM openjdk:17-jdk as builder WORKDIR /app COPY . . RUN ./gradlew build # 2. 최종 스테이지 FROM openjdk:17-jre-slim WORKDIR /app # builder 스테이지에서 생성된 JAR 파일만 복사 COPY --from=builder /app/build/libs/*.jar app.jar ENTRYPOINT ["java", "-jar", "app.jar"] - JRE만 포함된 매우 가벼운 베이스 이미지(e.g.,
- 장점:
- 이미지 크기 최소화: 최종 이미지에는 애플리케이션 실행에 필요한 JRE와 JAR 파일만 포함되어 용량이 크게 줄어듭니다.
- 보안 강화: 소스 코드나 빌드 도구가 최종 이미지에 포함되지 않아 공격에 노출될 위험이 줄어듭니다.
✅ 3. 무중단 배포 (Zero-downtime Deployment)
- 무중단 배포는 새로운 버전의 애플리케이션을 배포하는 동안에도, 사용자가 서비스를 중단 없이 계속 이용할 수 있도록 하는 배포 전략입니다.
➕ 주요 무중단 배포 전략
-
롤링 배포 (Rolling Update):
- 가장 일반적인 전략. 로드 밸런서에 연결된 여러 대의 서버 중, 한 번에 한 대씩(또는 일부씩) 점진적으로 구버전 서버를 새 버전 서버로 교체해나가는 방식입니다.
- 장점: 추가적인 서버 자원이 필요 없고, 배포 과정이 간단합니다.
- 단점: 배포 중에는 일시적으로 구버전과 신버전이 공존하는 상태가 됩니다.
-
블루-그린 배포 (Blue-Green Deployment):
- 구버전 환경(블루)과 신버전 환경(그린)을 똑같이 2세트 준비합니다.
- 현재 서비스 중인 블루 환경을 그대로 둔 채, 그린 환경에 신버전을 완벽하게 배포하고 테스트합니다.
- 테스트가 완료되면, 로드 밸런서(라우터)가 트래픽을 블루에서 그린으로 한 번에 전환합니다.
- 장점: 롤백(Rollback)이 매우 빠르고 안전합니다. (문제가 생기면 트래픽을 다시 블루로 돌리기만 하면 됨)
- 단점: 동일한 환경을 2세트 유지해야 하므로 비용이 더 많이 듭니다.
-
카나리 배포 (Canary Deployment):
- 신버전을 전체 서버가 아닌, 극소수의 서버(카나리)에만 먼저 배포하고, 일부 사용자(e.g., 전체 트래픽의 5%)에게만 새로운 버전을 노출시켜 위험을 감지하는 전략입니다.
- 카나리 서버에서 문제가 없는 것이 확인되면, 점진적으로 신버전 배포를 모든 서버로 확대합니다.
- 장점: 실제 운영 환경에서 실제 사용자를 대상으로 신버전의 안정성을 테스트할 수 있어, 장애의 영향을 최소화할 수 있습니다.
- 단점: 라우팅 기술 등 구현이 복잡합니다.
📌 요약
- 프로파일 기능을 사용하면, 환경별(개발/운영) 설정을 분리하여 배포의 유연성과 안정성을 높일 수 있습니다.
- Docker 멀티 스테이지 빌드는 빌드 환경과 실행 환경을 분리하여, 최종 이미지의 크기를 최소화하고 보안을 강화하는 필수적인 최적화 기법입니다.
- 무중단 배포는 서비스 중단 없이 새로운 버전을 배포하는 전략으로, 롤링(점진적 교체), 블루-그린(동시 운영 후 전환), 카나리(일부 트래픽 선공개) 등 다양한 방법이 있으며, 각 전략의 장단점을 이해하고 상황에 맞게 선택해야 합니다.
