-
Notifications
You must be signed in to change notification settings - Fork 0
KR_IT_Deploy
한 줄 답: 새 버전을 어떻게 교체하느냐의 전략 — Rolling(점진 교체)·Blue-Green(전체 전환)·Canary(일부 트래픽 검증)로 다운타임과 리스크를 조절한다.
배포 전략(Deployment Strategy) 은 새 버전의 애플리케이션을 운영 환경으로 내보낼 때, 기존 버전을 어떤 방식으로 교체할 것인지를 정의하는 패턴이다. 어떤 전략을 선택하느냐에 따라 다운타임, 롤백 속도, 리소스 비용, 그리고 사용자가 감수하는 위험 수준이 달라진다. 단일 정답은 없으며, 서비스의 SLO·트래픽 특성·인프라 비용 여력에 맞춰 선택한다.
핵심은 "배포 중에 사용자가 영향을 받는가" 와 "문제가 생겼을 때 얼마나 빨리 되돌릴 수 있는가" 의 트레이드오프이다. 다운타임을 줄이고 롤백을 빠르게 하려면 보통 더 많은 리소스(구버전·신버전 동시 가동)가 필요하다.
기존 버전을 전부 내린 뒤 새 버전을 올리는 가장 단순한 방식이다.
- 동작 방식: 구버전 인스턴스를 모두 종료 → 신버전 인스턴스를 기동
- 다운타임: 있음 (구버전 종료 ~ 신버전 기동 사이 서비스 중단)
- 롤백 속도: 느림 (다시 구버전을 재생성해야 함)
- 리소스 비용: 낮음 (동시에 한 버전만 가동)
- 위험: 다운타임을 감수해야 하므로 사용자 영향이 크지만, 구버전·신버전이 동시에 떠서 생기는 호환성 문제는 없음
- 적합한 경우: 다운타임이 허용되는 내부 도구, 배치 작업, 구·신 버전 동시 가동이 불가능한 경우(DB 스키마 비호환 등)
인스턴스를 한 번에 하나(또는 몇 개)씩 점진적으로 교체하는 방식이다. Kubernetes Deployment 의 기본 전략이다.
- 동작 방식: 신버전 Pod 를 일부 띄우고 → 정상 확인 후 구버전 Pod 를 일부 제거 → 전체가 교체될 때까지 반복
- 다운타임: 없음 (항상 일정 수의 인스턴스가 트래픽 처리)
- 롤백 속도: 중간 (역방향 롤링으로 되돌려야 하므로 즉시는 아님)
-
리소스 비용: 낮음~중간 (
maxSurge만큼만 추가 리소스 필요) - 위험: 배포 중 구·신 버전이 공존하므로 하위 호환성이 필요. 문제를 늦게 발견하면 이미 상당수가 교체된 상태
- 적합한 경우: 무중단이 필요한 대부분의 stateless 웹 서비스
구버전(Blue)과 신버전(Green) 환경을 동시에 완전히 구성한 뒤, 라우팅을 한 번에 전환하는 방식이다.
- 동작 방식: Green(신버전) 환경을 별도로 완전 구성 → 검증 → 로드밸런서/라우터를 Green 으로 전환 → Blue 는 잠시 대기시켰다가 정리
- 다운타임: 없음 (전환은 라우팅 스위치 한 번)
- 롤백 속도: 매우 빠름 (라우팅을 다시 Blue 로 되돌리면 끝)
- 리소스 비용: 높음 (두 환경을 동시에 풀로 가동 → 일시적으로 2배)
- 위험: 낮음 (전환 전 Green 을 충분히 검증 가능, 롤백 즉시). 단 DB 마이그레이션 같은 stateful 요소는 별도 고려 필요
- 적합한 경우: 빠른 롤백과 사전 검증이 중요한 서비스, 리소스 여력이 있는 경우
신버전을 소수의 사용자/트래픽에만 먼저 노출하고, 문제가 없으면 점진적으로 비중을 늘리는 방식이다. 이름은 탄광의 카나리아(위험 조기 경보)에서 유래했다.
- 동작 방식: 트래픽의 5% → 신버전으로 → 지표 정상 확인 → 25% → 50% → 100% 단계적 확대
- 다운타임: 없음
- 롤백 속도: 빠름 (카나리 비중을 0% 로 되돌리면 영향 즉시 차단)
- 리소스 비용: 중간 (구·신 버전 병행, 단 신버전은 일부만)
- 위험: 매우 낮음 (문제가 생겨도 소수 사용자만 영향). 단 트래픽 분할·지표 관찰 인프라가 필요
- 적합한 경우: 사용자 영향 위험을 최소화하면서 실제 운영 트래픽으로 검증하고 싶을 때
두 버전(A, B)을 동시에 운영하되, 기술적 안정성 검증이 아니라 비즈니스 지표(전환율·클릭률 등) 비교 가 목적인 방식이다.
- 동작 방식: 사용자 세그먼트(쿠키·지역·디바이스 등)에 따라 A 또는 B 버전으로 라우팅 → 지표를 통계적으로 비교
- Canary 와의 차이: Canary 는 "신버전이 안전한가"(기술적), A/B 는 "어느 버전이 더 좋은 결과를 내는가"(비즈니스). 라우팅 기준도 Canary 는 보통 무작위 %, A/B 는 사용자 속성 기반
- 리소스 비용: 중간 (두 버전 병행)
- 위험: 낮음 (둘 다 검증된 버전인 경우가 많음)
- 적합한 경우: 기능·UI 변경의 비즈니스 효과를 데이터로 검증할 때
| 전략 | 다운타임 | 롤백 속도 | 리소스 비용 | 위험 | 대표 사용처 |
|---|---|---|---|---|---|
| Recreate | 있음 | 느림 | 낮음 | 높음(중단) | 내부 도구, 배치, 동시 가동 불가 |
| Rolling Update | 없음 | 중간 | 낮음~중간 | 중간 | 무중단 stateless 웹 서비스 |
| Blue-Green | 없음 | 매우 빠름 | 높음(2배) | 낮음 | 빠른 롤백·사전 검증 중시 |
| Canary | 없음 | 빠름 | 중간 | 매우 낮음 | 운영 트래픽 점진 검증 |
| A/B Testing | 없음 | 빠름 | 중간 | 낮음 | 비즈니스 지표 비교 |
Kubernetes Deployment 의 기본 전략은 RollingUpdate 이며, maxSurge 와 maxUnavailable 로 교체 속도와 가용성을 제어한다.
-
maxSurge: 원하는 replica 수를 초과해 추가로 띄울 수 있는 Pod 수(또는 %). 클수록 빨리 교체되지만 추가 리소스를 더 쓴다. -
maxUnavailable: 업데이트 중 사용 불가 상태가 될 수 있는 Pod 수(또는 %).0으로 두면 항상 원하는 수의 가용 Pod 가 유지된다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% # 최대 12.5대까지 일시 증가
maxUnavailable: 0 # 가용 Pod 수를 절대 줄이지 않음(무중단)
template:
spec:
containers:
- name: web
image: registry.example.com/web:v2기본 Deployment 는 Recreate / RollingUpdate 만 지원한다. Blue-Green 이나 Canary 는 Service 라우팅 전환, Ingress 가중치, 또는 Argo Rollouts · Flagger 같은 별도 컨트롤러로 구현한다.
한 줄 답: 코드 배포와 기능 활성화를 분리해 배포된 코드의 특정 기능을 런타임 토글로 켜고 끄는 기법으로, 점진 롤아웃·A/B 테스트·즉시 롤백을 가능하게 한다.
기능 플래그(Feature Flag), 또는 Feature Toggle 은 코드 변경 없이 런타임에 특정 기능을 켜고 끌 수 있게 하는 조건 분기 메커니즘이다. 핵심 가치는 배포(Deploy)와 릴리스(Release)의 분리 이다. 코드를 운영에 배포해도 플래그가 꺼져 있으면 사용자에게는 노출되지 않으므로, "코드를 내보내는 시점"과 "기능을 켜는 시점"을 독립적으로 결정할 수 있다.
if feature_flags.is_enabled("new_checkout", user=current_user):
return render_new_checkout()
else:
return render_legacy_checkout()Martin Fowler 의 분류에 따라 플래그는 생애주기와 변경 빈도가 다르며, 그에 따라 관리 방식도 달라진다.
| 종류 | 목적 | 수명 | 변경 빈도 |
|---|---|---|---|
| Release Toggle (릴리스 토글) | 미완성/검증 중인 기능을 운영에서 숨김 | 짧음(기능 안정화 후 제거) | 낮음 |
| Ops Toggle (운영 토글) | 부하 시 무거운 기능을 끄는 등 운영 제어(킬 스위치) | 길거나 영구 | 상황에 따라 |
| Experiment Toggle (실험/A-B 토글) | A/B 테스트로 사용자 세그먼트별 분기 | 실험 기간 동안 | 자동/빈번 |
| Permission Toggle (권한 토글) | 특정 사용자·플랜에만 기능 노출(프리미엄 등) | 장기/영구 | 사용자 단위 |
플래그 값은 코드 배포 없이 외부 설정(플래그 관리 서비스·설정 저장소)에서 실시간으로 변경된다. 운영 중 장애가 의심되는 신기능을 재배포 없이 즉시 끌 수 있다는 점(킬 스위치) 이 운영 측면의 큰 이점이다.
- 비율 기반(% rollout): 전체 사용자의 1% → 10% → 50% → 100% 로 단계적으로 활성화하며 지표를 관찰
- 세그먼트 기반(user segment): 내부 직원 → 베타 사용자 → 특정 지역/플랜 순으로 노출 범위 확대
- 기능 플래그 기반 점진적 롤아웃은 인프라 레벨 Canary 와 달리, 애플리케이션 레벨에서 사용자 단위로 세밀하게 제어할 수 있다.
플래그는 본질적으로 코드 내 조건 분기이므로, 수명이 다한 플래그를 방치하면 코드 복잡도와 테스트 경우의 수가 폭증한다. 이를 플래그 부채(Flag Debt) 라고 한다.
- 규율: Release Toggle 은 기능이 안정화되면 반드시 제거 (플래그 + 죽은 분기 코드 삭제)
- 플래그에 생성일·담당자·만료 예정일을 메타데이터로 부여하고 주기적으로 정리
- 오래된 플래그를 자동 탐지/경고하는 도구나 린트 규칙 활용
- LaunchDarkly: 대표적인 상용 SaaS. 정교한 타게팅·실험·감사 기능
- Unleash: 오픈소스(셀프 호스팅 가능), 다양한 SDK 지원
- Flagsmith: 오픈소스/SaaS 겸용, REST API 중심
한 줄 답: Git 저장소를 단일 진실 공급원(SSOT)으로 삼아 선언적으로 상태를 정의하고, 컨트롤러가 실제 상태를 Git 상태로 지속 수렴시키는 운영 모델이다.
GitOps 는 Git 저장소를 시스템의 단일 진실 공급원(Single Source of Truth)으로 삼아, 인프라와 애플리케이션의 원하는 상태(desired state)를 선언적으로 관리하고, 그 상태를 실제 환경에 자동으로 동기화하는 운영 모델이다. "원하는 상태는 Git 에 있고, 클러스터는 그 상태로 수렴한다" 가 한 줄 요약이다.
CNCF 의 OpenGitOps 프로젝트는 GitOps 를 네 가지 원칙으로 정의한다.
- 선언적(Declarative): 시스템의 원하는 상태를 명령형 절차가 아니라 선언적으로 기술한다(예: Kubernetes manifest, Helm, Kustomize).
- 버전 관리·불변(Versioned and Immutable): 원하는 상태는 버전 관리(Git)에 저장되어 변경 이력이 남고, 각 상태는 불변(immutable)하게 보존된다.
- 자동으로 풀(Pulled Automatically): 소프트웨어 에이전트가 원하는 상태를 자동으로 가져온다(외부에서 밀어 넣지 않음).
- 지속적으로 조정(Continuously Reconciled): 에이전트가 실제 상태를 지속적으로 관찰하여 원하는 상태와 일치하도록 끊임없이 조정한다.
모든 변경이 Git 커밋(보통 Pull Request)을 거치므로, 누가·언제·무엇을·왜 바꿨는지가 자동으로 기록되고 리뷰·승인·감사가 가능하다. 롤백은 단순히 이전 커밋으로 git revert 하는 것이다.
| 구분 | Push 모델 | Pull 모델 (GitOps) |
|---|---|---|
| 동작 | CI 가 외부에서 클러스터로 kubectl apply 등을 밀어 넣음 |
클러스터 내부 에이전트가 Git 을 폴링/감시하여 스스로 적용 |
| 자격증명 | CI 가 클러스터 admin 권한을 보유(외부에 노출) | 자격증명이 클러스터 내부에 머무름(외부 노출 최소) |
| 드리프트 대응 | 별도 감지 필요 | 에이전트가 항상 조정하므로 자동 교정 |
| 안전성 | 상대적으로 낮음 | 더 안전(자격증명 비노출 + 자동 조정) |
Pull 모델이 더 안전한 이유는, 강력한 클러스터 자격증명을 외부 CI 시스템에 노출하지 않고 클러스터 내부에 가둬 두기 때문이다. 또한 에이전트가 항상 원하는 상태로 조정하므로 수동 변경에 의한 드리프트도 자동으로 되돌린다.
-
드리프트(Drift): 누군가
kubectl edit으로 직접 바꾸는 등, 실제 상태가 Git 의 원하는 상태에서 벗어난 상황 - GitOps 컨트롤러는 실제 상태와 Git 을 지속 비교하여 차이를 표시하고, 자동 동기화(auto-sync) 설정 시 Git 상태로 강제 복원(self-heal)한다.
| 항목 | ArgoCD | Flux |
|---|---|---|
| 출신/거버넌스 | CNCF Graduated (Intuit 시작) | CNCF Graduated (Weaveworks 시작) |
| UI | 강력한 내장 웹 UI·앱 그래프 | 내장 UI 없음(Weave GitOps 등 별도) |
| 구성 단위 |
Application CRD |
GitRepository + Kustomization/HelmRelease 등 |
| 멀티테넌시 | Projects 기반 | 네임스페이스/RBAC 기반 |
| 특징 | 시각화·운영 친화적, 대시보드 중심 | 경량·모듈형, GitOps Toolkit 컴포넌트 조합 |
GitOps 는 IaC(Infrastructure as Code)의 원칙(선언적·버전 관리)을 이어받되, 한 걸음 더 나아가 지속적 조정(Continuous Reconciliation) 을 추가한다. IaC 는 보통 terraform apply 처럼 사람이 트리거하는 반면, GitOps 는 에이전트가 Git 을 지속 감시하여 자동으로 수렴시킨다. 즉 "Git = 원하는 상태, 에이전트 = 그 상태로 끊임없이 맞추는 루프" 이다.
한 줄 답: Canary·Feature Flag를 기반으로 트래픽을 점진적으로 늘리며 메트릭으로 자동 검증·롤백하는, 배포 전략의 진화형이다.
점진적 전달(Progressive Delivery) 은 Canary 배포에 자동화된 지표 분석(Automated Metric Analysis) 과 자동 롤백 을 결합한 진화된 배포 방식이다. 단순히 트래픽을 조금씩 늘리는 것을 넘어, 각 단계마다 실시간 지표를 자동으로 평가하여 통과하면 다음 단계로 진행하고, 이상이 감지되면 사람 개입 없이 즉시 되돌린다.
한 줄로 요약하면 "Canary + 자동 분석 + 자동 롤백" 이다. Progressive Delivery 는 Canary 라는 방식 위에, 단계 진행 여부를 사람이 판단하던 부분을 지표 기반 자동 판단 으로 대체한 것이다.
각 카나리 단계에서 신버전의 상태가 정상인지를 정량 지표로 평가한다.
- 성공률(Success Rate): 정상 응답(2xx/3xx) 비율
- 지연시간(Latency): p95 / p99 응답 시간
- 오류율(Error Rate): 5xx 비율, 예외 발생률
이 지표들을 분석 윈도우(analysis window) 동안 수집하여 임계값과 비교한다. 임계값을 통과하면 트래픽 비중을 올리고, 회귀(regression)가 감지되면 자동으로 롤백 한다.
Recreate / Rolling
↓ (점진적 노출 추가)
Canary ─── 사람이 지표 보고 수동 판단
↓ (자동 분석 + 자동 롤백 추가)
Progressive Delivery ─── 지표 기반 자동 승급/롤백
-
Argo Rollouts: Kubernetes
Deployment를 대체하는RolloutCRD 를 제공. Canary/Blue-Green 단계와 분석을 선언적으로 정의하고, Prometheus 등 지표를AnalysisTemplate으로 평가하여 자동 승급/롤백한다. - Flagger: Flux 생태계의 Progressive Delivery 컨트롤러. 기존 Deployment 를 감싸 Canary 분석을 수행하며 service mesh/Ingress(Istio, Linkerd, NGINX 등)와 연동한다.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: web
spec:
strategy:
canary:
steps:
- setWeight: 20 # 트래픽 20% 를 신버전으로
- pause: { duration: 5m } # 5분간 지표 관찰
- analysis: # 자동 분석 통과해야 진행
templates:
- templateName: success-rate
- setWeight: 50
- pause: { duration: 5m }
- setWeight: 100자동 지표 분석의 임계값을 SLO(서비스 수준 목표) 와 연동하면, 배포가 SLO 를 위협하는 순간 자동으로 차단·롤백할 수 있다. 또한 Error Budget(오류 예산) 이 충분할 때만 배포를 진행하고, 예산이 고갈되면 배포를 멈추는 식의 게이팅(gating) 을 자동화할 수 있다. 이로써 배포 속도와 신뢰성의 균형을 사람의 직관이 아니라 지표를 기반으로 자동으로 의사결정할 수 있다.