배포 전략

트래픽이 옛 버전에서 새 버전으로 어떻게 넘어가나

변경의 위험도와 실패를 얼마나 빨리 탐지할 수 있는지에 따라 배포 전략을 선택해. 대표적인 세 가지 방식이 있어:

Recreate (다운타임 배포)

옛 버전을 멈추고 새 버전을 띄워. 짧은 다운타임이 생겨.
이해하기가 제일 쉬워. 개인 프로젝트나 트래픽이 적은 서비스의 기본값이야.
단점은 사용자가 있는 모든 순간에 영향을 준다는 거야.

Rolling

인스턴스를 N개씩 교체해. 배포 중간에는 옛 버전과 새 버전이 나란히 돌아.
Kubernetes deployment나 ECS rolling 같은 방식의 기본값이야.
주의할 점: 옛 인스턴스가 새 스키마를 읽거나 그 반대의 상황이 생기면 스키마 변경이 깨질 수 있어.

Blue/Green

운영 환경의 전체 복사본 두 개(blue + green)를 둬. 비활성 쪽에 배포하고, 스모크 테스트를 돌린 뒤 트래픽을 넘기고 옛 버전은 폐기해.
로드 밸런서를 다시 돌리면 즉시 롤백할 수 있어.
비용은 배포 동안 인프라가 2배로 든다는 거야.

Canary

트래픽의 1 → 5 → 25 → 100%로 시간을 두고 배포해.
각 단계마다 에러율과 지연 시간을 모니터링해. 수치가 튀면 자동으로 롤백해.
가장 이상적인 방식이야. 좋은 관측 가능성과 피처 플래그, 또는 가중치 기반 라우터가 필요해.

파이프라인 모양이 전략을 반영해

카나리 파이프라인은 롤링(큰 배포 하나)보다 작업이 더 많아(트래픽 단계마다 하나씩). 선택한 전략이 YAML 모양과 롤백의 복잡도를 결정해.

Code

카나리 배포 3 트래픽 단계·yaml

jobs:
  deploy-canary-5:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./deploy.sh --weight 5
      - run: ./check-health.sh --duration 5m

  deploy-canary-25:
    needs: deploy-canary-5
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./deploy.sh --weight 25
      - run: ./check-health.sh --duration 10m

  deploy-full:
    needs: deploy-canary-25
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./deploy.sh --weight 100

  rollback-on-fail:
    needs: [deploy-canary-5, deploy-canary-25, deploy-full]
    if: failure()
    runs-on: ubuntu-latest
    steps:
      - run: ./rollback.sh

트래픽이 옛 버전에서 새 버전으로 어떻게 넘어가나

Recreate (다운타임 배포)

Rolling

Blue/Green

Canary

파이프라인 모양이 전략을 반영해

Code

External links

Exercise

Progress

댓글 0