유지 관리 기간 및 교차 손가락을 의미하는 데 사용되는 소프트웨어 출시. 현대 팀은 릴리스를 일상적으로 만드는 전략을 사용하며, 블루-그린 배포와 카나리아 배포 선택은 가장 먼저 직면하게 되는 선택 중 하나입니다. 둘 다 위험을 줄이지만 반대 방식으로 수행합니다. 하나는 전체 교체를 준비하고 다른 하나는 실제 사용자를 대상으로 한 번에 조금씩 테스트합니다.

이 가이드에서는 각각의 작동 방식과 실제 비용을 설명합니다. Python 3.13에서 소규모 사용자 라우팅 및 롤백 예제를 실행했으며 해당 실행에서 출력이 나왔습니다. Kubernetes 샘플은 설명을 위한 것이며 우리는 이를 실행하지 않았습니다. 백분율과 임계값을 적응할 시작 사례로 간주합니다.

짧은 대답

블루-그린 배포를 사용하면 두 개의 동일한 프로덕션 환경을 실행합니다. 하나는 사용자에게 서비스를 제공하고 다른 하나는 새 버전을 배포하고 테스트한 다음 한 번에 모든 트래픽을 전환합니다.

카나리아 배포를 사용하면 새 버전이 이전 버전 옆에서 실행됩니다. 실제 트래픽의 작은 비율을 전송하고, 결과를 비교하고, 모든 사람에게 서비스가 제공될 때까지 공유를 단계적으로 늘립니다. 이 이름은 한때 위험에 대한 조기 경고로 사용되었던 카나리아 광부에서 유래되었습니다.

청록색과 카나리아가 나란히 있는 모습

블루-그린 배포 작동 방식

1. 블루는 실시간이며 모든 트래픽을 제공합니다.
2. 사용자 트래픽을 수신하지 않는 green에 새 버전을 배포합니다.
3. 연기 테스트와 내부 사용자를 사용하여 실제 생산 환경에서 친환경성을 철저하게 테스트합니다.
4. 라우터, 로드 밸런서 또는 DNS를 전환하여 트래픽을 녹색으로 보냅니다.
5. 파란색이 계속 실행되고 준비되어 있는지 자세히 살펴보세요.
6. 문제가 있으면 다시 전환하세요. 모든 것이 괜찮다면 파란색이 다음 유휴 환경이 됩니다.

Kubernetes에서는 서비스 선택기를 변경하여 전환을 수행할 수 있으므로 트래픽은 다르게 라벨이 지정된 Pod로 이동됩니다.

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

강점: 개념적으로 간단합니다. 사용자가 보기 전에 정확한 프로덕션 설정을 테스트할 수 있으며 롤백이 거의 즉각적입니다. 약점: 중복된 인프라는 비용이 많이 들 수 있고, 테스트를 통과하지 못한 버그는 모든 사람에게 동시에 영향을 미치며, 전환 중에 공개 세션과 진행 중인 작업에 주의가 필요합니다. 스위치에 DNS를 사용하는 경우 캐시된 레코드로 인해 스위치가 지연될 수 있습니다. 개념이 처음이신가요? 초보자를 위한 Kubernetes 튜토리얼을 참조하세요.

카나리아 배포 작동 방식

1. 안정적인 버전과 함께 새 버전을 배포합니다.
2. 트래픽의 작은 부분(예: 5%)을 카나리아로 라우팅합니다.
3. 안정적인 버전과 오류율, 대기 시간 및 비즈니스 지표를 비교하세요.
4. 정상이면 25%, 50%, 100%로 증가합니다.
5. 성능이 저하되면 모든 트래픽을 안정적인 버전으로 다시 보내세요.

많은 팀이 내부 직원, 위험도가 낮은 지역, 그리고 더 넓은 대중과 함께 카나리아를 시작합니다.

장점: 잘못된 릴리스는 소규모 그룹에만 영향을 미치며 실제 트래픽을 통해 어떤 테스트 환경도 완전히 재현할 수 없다는 사실을 배웁니다. 약점: 백분율 기반 라우팅 및 버전별 측정항목이 필요하고 출시에 더 오랜 시간이 걸리며 한동안 두 버전이 함께 실행됩니다. 작은 카나리아는 특히 교통량이 적은 시간에 의미 있는 신호를 보내기에는 너무 조용할 수도 있습니다.

안정적인 사용자 라우팅

요청이 있을 때마다 무작위로 버전을 선택하면 사용자가 이전 버전과 새 버전 사이를 오갈 수 있어 혼란스러운 경험을 하게 됩니다. 일반적인 솔루션은 안정적인 사용자 ID를 버킷에 해시하여 각 사용자가 항상 동일한 답변을 얻는 것입니다.

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

실제 점유율은 목표치를 바짝 추종했습니다. 이 방법에는 두 가지 유용한 속성이 더 있으며, 우리의 실행에서는 두 가지를 모두 확인했습니다. 동일한 사용자는 항상 동일한 버전을 받았습니다. 그리고 5% 그룹의 모든 사람은 여전히 ​​25%에 포함되어 있으므로 이미 새 버전을 갖고 있는 사람은 롤아웃이 커짐에 따라 다시 돌아오지 않았습니다.

실제 시스템에서는 일반적으로 서비스 메시, 로드 밸런서 또는 Argo Rollouts나 Flagger와 같은 도구가 이 라우팅을 처리하므로 직접 작성할 필요가 없습니다. 그들이 무엇을 하고 있는지 이해하는 것은 여전히 ​​도움이 됩니다.

결정 자동화

카나리아는 누군가가 실제로 버전을 비교하는 경우에만 작동합니다. 사람이 그래프를 보는 것보다 자동 점검이 더 신뢰성이 높습니다. 다음은 카나리아의 오류율을 안정 버전의 오류율과 비교하는 핵심 아이디어입니다.

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

첫 번째 경우에 주목하세요. 오류율이 높아 보이지만 요청이 100개에 불과해 아직 증거가 충분하지 않습니다. 실제 도구는 보다 신중한 통계를 적용하고 여러 신호를 함께 살펴봅니다.

데이터베이스 문제

애플리케이션 코드는 몇 초 안에 교체될 수 있지만 데이터는 그렇지 않습니다. 두 전략 모두 일반적으로 하나의 데이터베이스를 공유하므로 롤아웃 중과 롤백 후에 이전 버전과 새 버전이 모두 동일한 스키마에서 작동해야 합니다.

표준적인 대답은 확장 및 축소 패턴입니다. name의 이름을 full_name으로 바꾸고 싶다고 가정해 보겠습니다.

1. 확장: 새 열을 추가합니다. 이전 코드는 영향을 받지 않습니다.
2. 이전: 두 열 모두에 쓰고 이전 행을 채우는 릴리스 코드입니다.
3. 스위치: 새 열에서 읽는 릴리스 코드입니다.
4. 계약: 기존 열을 사용하는 항목이 없으면 이후 릴리스에서 이를 제거하세요.

여러 번의 릴리스가 필요하지만 모든 단계를 안전하게 롤백할 수 있습니다. RENAME COLUMN을 한 번에 실행하면 다른 이름이 필요한 버전이 손상됩니다. 장기 실행 스키마 변경에도 잠금이 걸릴 수 있으므로 주의하세요. 이에 대한 자세한 내용은 SQL 트랜잭션을 참조하세요.

롤링 및 기타 전략

Kubernetes 배포는 기본적으로 많은 서비스에 적합한 롤링 업데이트를 수행합니다. 롤링 업데이트도 점진적으로 이동하지만 해당 공유는 인스턴스 수와 연결되어 있으며 자체적으로 결과를 분석하거나 잘못된 측정 항목에서 일시 중지되지 않습니다.

기능 플래그는 어떻습니까?

배포는 서버에 코드를 추가하고 릴리스는 사용자가 기능을 사용할 수 있도록 합니다. 기능 플래그는 아무것도 배포하지 않고도 선택한 사용자에 대해 기능을 켤 수 있도록 하여 이를 별도로 유지합니다. 두 전략 모두 매우 잘 작동합니다. 플래그를 끈 상태로 배포한 다음 점차적으로 활성화합니다. 플래그는 시작 시 충돌이 발생하는 릴리스로부터 사용자를 보호할 수 없기 때문에 이러한 전략을 대체하지 않습니다. 오래된 플래그는 기술적 부채로 쌓이므로 제거하는 것을 잊지 마세요.

선택 방법

또한 결합할 수도 있습니다. 일부 팀은 친환경 환경을 배포한 다음 점진적으로 트래픽을 해당 환경으로 이동하여 깨끗한 환경과 제한된 폭발 반경을 얻습니다. 무엇을 선택하든 GitHub 작업 가이드에서 설명하는 대로 CI/CD 파이프라인을 통해 자동화하세요.

일반적인 실수

• 브레이킹 스키마 변경. 이전 코드가 데이터를 읽을 수 없으면 롤백이 도움이 되지 않습니다.
• 롤백 기준이 없습니다. 사고 발생 중이 아니라 릴리스가 시작되기 전에 “나쁜”이 무엇을 의미하는지 결정하십시오.
• 환경을 표류하게 합니다. 녹색이 파란색과 다르면 테스트 결과가 덜한 것입니다. 인프라를 코드로 사용하여 두 가지를 모두 정의합니다.
• 기술적 측정항목만 측정합니다. 릴리스에는 오류가 없고 결제가 중단될 수 있습니다.
• 롤백을 절대 연습하지 마세요. 압박감을 느낄 때 작동하도록 연습하세요.
• 백그라운드 작업을 잊어버립니다. 작업자와 예약된 작업에도 전환 중에 계획이 필요합니다.

마무리

청록색은 깨끗하고 빠른 전환을 제공합니다. Canary는 작고 측정된 노출을 제공합니다. 모니터링이 여전히 기본이라면 롤링 업데이트 또는 청록색으로 시작하고 카나리아를 시도하기 전에 버전별 측정항목에 투자하세요. 그런 다음 데이터베이스를 포함하여 다음 릴리스에 대한 롤백을 연습해 보세요. 그 단 하나의 연습은 실제로 수정이 필요한 것이 무엇인지 드러내는 경향이 있습니다.

자주 묻는 질문

계속 학습하세요