API 블루그린 배포: 배포 전 필수 테스트 가이드

블루-그린 배포는 다운타임 없는 릴리스를 약속합니다. 서비스의 새 복사본을 생성하고, 일부 트래픽을 보내며, 정상으로 보이는 즉시 전환합니다. 문제는 "정상"이라는 단어입니다. 로드 밸런서 상태 확인은 일반적으로 하나의 엔드포인트를 핑하고 200을 기다립니다. 이는 프로세스가 실행 중임을 알려줄 뿐입니다. 새 빌드가 올바른 JSON을 반환하는지, 동일한 계약을 준수하는지, 또는 이전 버전과 동일한 방식으로 토큰을 인증하는지에 대해서는 아무것도 알려주지 않습니다. 따라서 스위치를 전환하면, 첫 번째 실제 사용자가 상태 확인으로는 발견할 수 없었던 버그를 찾게 됩니다.

이 가이드는 프로덕션 트래픽이 도달하기 전에 사용자가 하는 것처럼 그린 환경을 테스트하는 방법을 안내합니다. 유휴 스택에 대해 전체 API 테스트 스위트를 실행하고, 해당 결과에 따라 전환 여부를 결정하며, 전체 과정을 파이프라인에 연결하여 모든 배포에서 실행되도록 할 것입니다. 데스크톱 앱에서 구축한 동일한 테스트 시나리오를 CI에서 어떤 환경을 가리키든 자동으로 실행할 수 있기 때문에 테스트 계층으로 Apidog와 Apidog CLI를 사용할 것입니다.

이미 블루-그린 배포를 사용하고 있지만 검증 단계를 "잠시 여기저기 클릭하는 것"으로 여기고 있다면, 이 부분은 신뢰할 수 있는 방식으로 전환시켜 줄 것입니다. 두 개의 동일한 환경을 실행하는 전체 목적은 실제 조건에서 그중 하나를 검증하는 것입니다. 상태 확인은 바닥일 뿐, 천장이 아닙니다.

요약

블루-그린 배포는 두 개의 동일한 프로덕션 환경을 실행하고 그 사이에서 라우터를 전환합니다. 블루(현재 운영 중)에서 그린(새 버전)으로 트래픽을 전환하기 전에, 그린 환경에 대해 전체 API 테스트 스위트를 직접 실행하십시오. 스위트의 그린 빌드 결과에 따라 전환 여부를 결정하십시오. Apidog CLI를 사용하여 파이프라인에서 동일한 테스트 시나리오를 그린 환경의 기본 URL로 지정하고, 어떤 단언(assertion)이라도 실패하면 배포를 중단하고, 그 후에야 라우터를 전환하십시오. 상태 확인은 프로세스가 실행 중임을 확인하지만, API 테스트는 계약이 여전히 유효함을 확인합니다.

블루-그린 배포는 실제로 무엇인가요?

블루-그린 배포는 두 개의 프로덕션 수준 환경을 나란히 유지하는 릴리스 패턴입니다. 하나는 실제 트래픽을 처리하고(이를 블루라고 부릅니다), 다른 하나는 유휴 상태로 다음 버전을 받을 준비를 합니다(이를 그린이라고 부릅니다). 새 빌드를 그린에 배포하고, 이를 확인한 다음, 단일 스위치(로드 밸런서 대상, DNS 레코드, Kubernetes 서비스 셀렉터)를 변경하여 모든 트래픽이 이제 그린으로 흐르도록 합니다. 블루는 다음 릴리스를 위한 유휴 대기 상태가 됩니다. 문제가 발생하면 몇 초 만에 블루로 되돌릴 수 있습니다.

매력은 분명합니다. 유지보수 기간이 필요 없고, 전환은 거의 즉각적으로 이루어집니다. 그리고 이전 버전이 여전히 실행 중이고 준비되어 있기 때문에 롤백 비용이 가장 저렴합니다. 이는 인스턴스를 그 자리에서 교체하고 문제가 있는 빌드가 이미 일부 사용자에게 서비스되고 있는 롤링 배포와 비교됩니다.

하지만 이 패턴은 전환 시 그린 환경이 실제로 준비되어 있을 때만 효과를 발휘합니다. 대부분의 팀이 이 준비도 검사에 충분히 투자하지 않습니다. 그들은 그린이 부팅되고 피상적인 /health 핑을 통과하면 전환하고 바라기만 합니다. 블루-그린 배포의 형태는 철저한 검사를 쉽게 만듭니다. 그린은 완전히 배포되어 접근 가능하지만, 공개 트래픽을 받지 않을 뿐이므로 이를 건너뛸 변명의 여지가 없습니다. 테스트를 기다리는 완벽하고 격리된 프로덕션 복사본이 바로 거기 있습니다.

더 넓은 릴리스 전략 용어를 먼저 알고 싶다면, 지속적 배포(continuous delivery) vs 지속적 배포(continuous deployment) vs 지속적 통합(continuous integration)에 대한 저희의 설명이 블루-그린이 어디에 속하는지에 대한 맥락을 설정해 줄 것입니다.

상태 확인이 테스트가 아닌 이유

여기 팀들을 괴롭히는 간극이 있습니다. 일반적인 상태 확인은 다음과 같습니다:

# 로드 밸런서 상태 프로브
GET /health -> 200 OK -> 대상을 정상으로 표시

해당 엔드포인트는 일반적으로 하드코딩된 {"status":"ok"}를 반환합니다. 데이터베이스를 건드리지 않습니다. 인증을 수행하지 않습니다. 실제 리소스를 직렬화하지 않습니다. 모든 비즈니스 엔드포인트가 500, 잘못된 페이로드 또는 어제의 스키마를 반환하는 동안에도 빌드는 이 프로브를 통과할 수 있습니다.

/health 핑이 아무 문제 없이 통과시킬 수 있는 실패 모드를 고려해 보십시오:

마이그레이션이 실행되지 않아 GET /orders/{id}가 누락된 컬럼에 대해 오류를 발생시킵니다.
이름이 바뀐 JSON 필드(user_id가 userId로 변경됨)가 모든 다운스트림 소비자를 중단시킵니다.
모바일 앱이 여전히 발행하는 토큰을 이제 거부하는 인증 변경.
ISO 8601에서 Unix 타임스탬프로 날짜 형식을 변경하는 종속성 버전 업그레이드.
필수 헤더가 새로 추가되어 이를 보내지 않는 모든 클라이언트에 대해 400을 반환합니다.

이 중 어느 것도 프로세스 부팅을 멈추게 하지 않습니다. 그러나 이 모든 것은 트래픽을 전환하는 순간 실제 사용자에게 문제를 일으킵니다. 해결책은 더 스마트한 상태 확인이 아닙니다. 클라이언트가 하는 방식으로 엔드포인트를 호출하고, 상태 코드, 응답 본문, 스키마 및 대기 시간을 단언(assert)하며, 통과 또는 실패를 보고하는 실제 테스트 스위트입니다. 이것이 바로 API 계약 테스트의 배경이 되는 원칙입니다. 즉, 실행 중인 서비스가 소비자가 의존하는 계약과 여전히 일치하는지 확인하는 것입니다.

블루-그린 테스트 워크플로, A부터 Z까지

우리가 구축하려는 순서는 다음과 같습니다. 새로운 단계는 "그린 테스트"이며, 배포와 전환 사이에 위치합니다.

그린에 배포. 새 빌드를 유휴 환경으로 푸시합니다. 예를 들어 https://green.internal.example.com과 같은 내부 주소에서 접근 가능하게 되지만, 아직 공개 트래픽은 받지 않습니다.
그린 스모크 테스트. 그린에 대해 핵심 경로 요청의 빠른 하위 집합을 실행합니다. 로그인, 핵심 리소스 가져오기, 리소스 생성 등이 있습니다. 하나라도 실패하면 여기서 중단합니다. 블루는 여전히 사용자에게 서비스를 제공하며 아무것도 감지하지 못했습니다.
그린에 대해 전체 스위트 실행. 그린 기본 URL을 가리키는 완전한 API 테스트 시나리오(성공 경로, 오류 사례, 인증 흐름, 스키마 단언)를 실행합니다.
전환 결정. 스위트가 통과하면 진행합니다. 뭔가 실패하면 파이프라인이 중단되고 그린은 해체되거나 검사를 위해 남겨집니다. 프로덕션은 건드리지 않습니다.
스위치 전환. 라우터(로드 밸런서, DNS 또는 서비스 셀렉터)를 블루에서 그린으로 다시 지정합니다.
프로덕션에서 검증. 전환 후 실제 URL에 대해 동일한 스모크 테스트를 실행하여 전환이 깔끔하게 적용되었는지 확인합니다.
블루를 준비 상태로 유지. 롤백 기간 동안 이전 환경을 유지합니다. 전환 후 모니터링이 잘못되면 즉시 블루로 되돌립니다.

핵심은 2단계, 3단계, 6단계가 동일한 테스트 정의를 사용한다는 것입니다. 시나리오를 한 번 구축하고 실행기가 대상으로 하는 기본 URL만 변경합니다. 이것이 우리가 다음으로 설정할 기능입니다.

Apidog에서 테스트 시나리오 구축하기

무엇이든 자동화하기 전에 실행할 가치가 있는 테스트 스위트가 필요합니다. Apidog를 사용하면 이를 시각적으로 구축한 다음, 아무것도 다시 작성할 필요 없이 명령줄에서 실행할 수 있습니다. Apidog를 다운로드하고 배포할 서비스에 대한 프로젝트를 생성하십시오.

프로젝트 내에서 기존 API 엔드포인트로부터 테스트 시나리오를 구성합니다. 시나리오는 단계 사이에 단언(assertions) 및 변수 전달이 있는 순서 있는 요청 세트입니다. 블루-그린 준비 스위트의 경우, 단순한 일회성 핑이 아니라 실제 클라이언트가 하는 작업을 반영하는 시나리오를 원할 것입니다.

주문 서비스에 대한 실용적인 시작 세트:

인증 흐름: 유효한 자격 증명으로 POST /auth/login을 호출하고, 200을 단언(assert)하며, 베어러 토큰을 변수로 추출한 다음, 이후 모든 요청에서 사용합니다.
읽기 경로: 토큰과 함께 GET /orders를 호출하고, 200을 단언하며, 응답이 배열임을 단언하고, 각 항목에 id, status, total이 있음을 단언합니다.
단일 리소스: GET /orders/{id}를 호출하고, 스키마가 OpenAPI 정의와 일치함을 단언하며, total이 0보다 큰 숫자인지 단언합니다.
쓰기 경로: 유효한 본문으로 POST /orders를 호출하고, 201을 단언하며, 반환된 id가 비어 있지 않음을 단언한 다음, 해당 새 id를 다시 GET하여 지속되었는지 확인합니다.
부정적인 경우: 유효하지 않은 토큰으로 GET /orders/{id}를 호출하고, 401을 단언합니다. 필수 필드가 누락된 상태로 POST /orders를 호출하고, 400을 단언합니다.

상태 확인이 놓치는 실패를 잡는 데 가장 중요한 두 가지 기능이 있습니다. 첫째, 스키마 단언(schema assertions): Apidog는 해당 엔드포인트의 JSON 스키마 또는 OpenAPI 정의에 대해 응답을 검증할 수 있으므로, 이름이 변경되거나 타입이 재정의된 필드는 프로덕션으로 넘어가지 않고 테스트에서 실패합니다. 둘째, 특정 값, 헤더 및 응답 시간에 대한 응답 단언(response assertions)을 통해 미묘한 변화를 감지할 수 있습니다: 날짜 형식 변경, 숫자를 예상했던 곳에 null, 지연 시간 회귀 등.

핵심 설계 결정은 환경 처리입니다. 요청에 https://blue.example.com을 하드코딩하지 마십시오. 기본 URL에 대한 환경 변수를 정의하고 모든 곳에서 {{baseUrl}}로 참조하십시오. Apidog에서는 환경(프로덕션, 그린, 로컬)을 설정하고 활성 환경을 전환하거나, CLI에서 런타임에 기본 URL을 재정의할 수 있습니다. 이는 환경 및 비밀 관리 기능을 갖춘 API 클라이언트 가이드에서 다룬 환경 및 비밀 관리 원칙과 동일합니다. 테스트는 블루와 그린 환경에서 동일하게 유지되며, 대상만 변경됩니다.

이러한 시나리오를 단일 실행 단위로 묶고 싶다면, Apidog의 테스트 스위트는 여러 시나리오를 그룹화하여 하나의 명령으로 전체 준비도 확인을 실행할 수 있게 합니다.

명령줄에서 스위트 실행하기

데스크톱 앱은 시나리오를 구축하고 디버깅하는 곳입니다. CLI는 파이프라인에서 그린 환경에 대해 시나리오를 실행하는 도구입니다. npm으로 설치하십시오. Node.js v16 이상이 필요합니다:

npm install -g apidog-cli

실행기는 CI 구성에서 테스트 시나리오를 실행합니다. Apidog에서는 테스트 시나리오에 대한 CI 구성을 생성하며, 이는 액세스 토큰에 연결된 실행 명령을 제공합니다. 기본 형태는 다음과 같습니다:

apidog run "https://api.apidog.com/api/v1/api-test/ci-config/<config-id>/detail?token=<token>" \
  -r html,cli \
  --out-file green-readiness

-r 플래그는 리포터를 선택합니다. cli는 결과를 터미널에 출력하여 파이프라인 로그에 어떤 단언(assertion)이 실패했는지 정확히 보여줍니다. html은 배포를 검토하는 사람들을 위해 빌드 아티팩트로 보관할 수 있는 독립형 보고서를 작성합니다. 결과를 다른 도구로 전달하고 싶을 때를 위한 JSON 리포터도 있습니다. --out-file 플래그는 출력을 명명하여 각 실행을 빌드에 추적할 수 있도록 합니다.

특히 그린 환경을 가리키도록 스위트를 실행할 때, 실행기는 환경 플래그를 받아 동일한 시나리오가 다른 대상을 상대로 실행되도록 합니다:

# 전환 전에 그린(유휴) 환경 테스트
apidog run "<ci-config-url>" \
  --environment <greenEnvironmentId> \
  -r cli,html \
  --out-file green-pre-switch

모든 것을 리포지토리에 보관하고 구성을 가져오기 위한 네트워크 호출을 피하고 싶다면, 내보낸 시나리오 파일에서 실행을 완전히 제어할 수도 있습니다:

apidog run --exported-data ./tests/orders-readiness.json \
  --variables ./tests/green.variables.json \
  -r cli

파이프라인 컨텍스트에서 실행기 및 해당 옵션에 대한 자세한 내용은 CI/CD에서 API 테스트를 자동화하는 방법을 참조하십시오. 블루-그린에 중요한 동작은 종료 코드입니다: 단언(assertion)이 실패하면 CLI는 0이 아닌 값으로 종료됩니다. 이 한 가지 사실이 전환 여부를 결정하게 합니다. 0이 아닌 종료는 전환 단계가 실행되기 전에 파이프라인을 중지시킵니다.

GitHub Actions 파이프라인에 연결하기

다음은 배포 워크플로 내의 검증 단계입니다. 이는 이전 작업에서 이미 빌드를 그린에 배포했고 그린이 실행기에서 접근 가능하다고 가정합니다. 이 작업은 그린을 테스트하며, 통과한 실행만이 다음 작업이 전환을 수행하도록 허용합니다.

name: deploy-blue-green

on:
  push:
    branches: [main]

jobs:
  deploy-green:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 그린 환경에 빌드 배포
        run: ./scripts/deploy-green.sh
      # 이제 그린은 https://green.internal.example.com에서 접근 가능합니다.

  test-green:
    needs: deploy-green
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Apidog CLI 설치
        run: npm install -g apidog-cli
      - name: 그린에 대해 준비도 스위트 실행
        run: |
          apidog run "${{ secrets.APIDOG_CI_CONFIG_URL }}" \
            --environment "${{ vars.GREEN_ENV_ID }}" \
            -r cli,html \
            --out-file green-readiness
      - name: HTML 보고서 보관
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: green-readiness-report
          path: ./green-readiness.html

  switch-traffic:
    needs: test-green        # test-green이 통과한 경우에만 실행됩니다.
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 라우터를 블루에서 그린으로 전환
        run: ./scripts/switch-to-green.sh
      - name: 전환 후 프로덕션 URL 스모크 테스트
        run: |
          npm install -g apidog-cli
          apidog run "${{ secrets.APIDOG_SMOKE_CONFIG_URL }}" \
            --environment "${{ vars.PROD_ENV_ID }}" \
            -r cli

의존성 체인이 게이팅을 대신 수행합니다. switch-traffic은 needs: test-green을 나열하므로, 준비도 스위트가 실패하면 전환 작업은 절대 시작되지 않습니다. 그린은 유휴 상태를 유지하고, 블루는 계속 서비스를 제공하며, 다운스트림의 누구도 영향을 받지 않습니다. 아티팩트 업로드의 if: always()는 실패하더라도 HTML 보고서를 얻을 수 있음을 의미하며, 이는 바로 보고서를 읽고 싶을 때입니다.

CI 구성 URL과 토큰은 절대 인라인으로 넣지 말고 리포지토리 비밀(secrets)로 저장하십시오. 환경 ID는 민감하지 않으므로 리포지토리 변수(variables)로 둘 수 있습니다. 팀이 GitLab, Jenkins, CircleCI 또는 Azure Pipelines를 사용하는 경우에도 구조는 동일합니다. 즉, 0이 아닌 값으로 종료되는 테스트 단계는 전환 단계를 차단합니다. GitHub Actions에서 API 테스트 자동화하기에 대한 저희 가이드에서 실행기 설정에 대해 더 자세히 다루며, 동일한 패턴이 이러한 모든 플랫폼에 적용됩니다.

스모크 테스트 먼저, 전체 스위트 나중에

그린에 대해 전체 스위트를 실행하는 것이 올바른 게이트이지만, 12분 실행 중 8분째에 완전히 고장 난 빌드를 발견하고 싶지는 않을 것입니다. 검증을 두 단계로 분리하십시오.

스모크 테스트는 핵심 경로를 다루는 3~5개의 요청으로 이루어진 작은 시나리오입니다. 로그인, 하나의 리소스 읽기, 하나 생성, 다시 읽기 등이 포함됩니다. 이를 먼저 실행하십시오. 그린이 이들을 수행할 수 없다면 전체 스위트는 시간 낭비이며 빠르게 실패시켜야 합니다. 이 테스트는 30초 이내로 유지하십시오.

전체 스위트는 스모크 테스트가 통과한 후에만 실행됩니다. 여기에는 모든 엔드포인트, 오류 사례, 엣지 케이스, 모든 응답에 대한 스키마 유효성 검사, 인증 조합, 페이지네이션, 비율 제한 헤더 등 광범위한 내용이 포함됩니다. 더 느리지만 괜찮습니다. 실제 사용자에게 도달하기 전의 마지막 관문이기 때문입니다.

이러한 2단계 접근 방식은 테스트 시나리오 vs 테스트 케이스 사고방식의 동일한 논리입니다. 즉, 스모크 시나리오는 빠른 신뢰 신호이고, 전체 스위트는 포괄적인 커버리지를 제공합니다. 둘 다 동일한 그린 기본 URL을 가리키지만, 커버하는 범위와 실행 시점에만 차이가 있습니다.

테스트 데이터에 대한 참고 사항입니다. 그린은 프로덕션 환경이므로 쓰기 경로 테스트가 생성하는 항목에 대해 신중해야 합니다. 기록을 정리하는 전용 테스트 계정을 사용하거나, 데이터 계층이 승격되기 전에 스테이징 데이터베이스로 지원되는 그린 인스턴스에 대해 쓰기 테스트를 실행하십시오. 목표는 프로덕션 데이터를 오염시키지 않고 동작을 검증하는 것이며, 이는 샌드박스와 실제 프로덕션 테스트 사이의 경계입니다.

핵심을 무너뜨리는 일반적인 실수

팀들은 블루-그린을 채택하고도 여전히 문제가 있는 것을 배포합니다. 보통은 다음 중 하나입니다.

그린 대신 블루 테스트. 스위트가 실제 URL을 가리키면, 릴리스하려는 버전이 아니라 이미 프로덕션에 있는 버전을 테스트하는 것입니다. 전환 전에 항상 그린 기본 URL을 명시적으로 대상으로 지정하십시오.
상태 코드만 확인. 잘못된 본문이 있는 200은 여전히 손상된 응답입니다. HTTP 상태뿐만 아니라 페이로드 형태와 주요 값에 대해 단언(assert)하십시오. 스키마 단언은 필드 이름 변경 및 타입 변경을 잡아냅니다.
부정적인 경우 건너뛰기. 유효하지 않은 토큰에 대해 200을 반환하는 빌드는 성공 경로 테스트로는 절대 잡을 수 없는 보안 회귀입니다. 게이트에 401, 403, 400 사례를 포함하십시오.
롤백 규율 없음. 블루-그린의 초능력은 즉각적인 롤백이지만, 블루를 준비 상태로 유지할 때만 가능합니다. 그린이 가동되는 순간 블루를 해체하지 마십시오. 모니터링 기간 동안 블루를 유지하십시오.
테스트 요청에 하드코딩된 URL. 기본 URL이 요청에 고정되는 순간, 그린과 블루에 대해 동일한 스위트를 실행할 수 있는 능력을 잃게 됩니다. 항상 호스트에 대한 환경 변수를 사용하십시오.
상태 확인을 게이트로 취급. 전체 기사를 한 줄로 요약하자면 이렇습니다. 프로브는 로드 밸런서에게 프로세스가 존재함을 알려줍니다. API 테스트는 계약이 유효함을 알려줍니다.

블루-그린 vs 카나리: 테스트가 적합한 곳

블루-그린만이 유일한 다운타임 없는 전략은 아니며, 테스트 접근 방식은 각 전략에 따라 달라집니다.

전략	트래픽 이동 방식	API 테스트 적합성
블루-그린	한 번에 전체 트래픽, 블루에서 그린으로	전환 전에 그린에 대해 전체 스위트 실행; 게이트는 전환 전
카나리	점진적으로, 소량의 %를 새 버전으로	카나리 슬라이스에 대한 지속적인 단언; 깔끔한 지표를 기반으로 승격
롤링	인스턴스별로, 제자리에서	인스턴스별 스모크 체크; 롤아웃이 이미 진행 중이므로 게이팅하기 어려움
재생성	이전 버전 중지, 새 버전 시작 (다운타임 발생)	지정된 기간 동안 스위트 실행; 다운타임은 트레이드오프

블루-그린은 네 가지 전략 중 가장 깔끔한 게이트를 제공합니다. 그린은 테스트 시 완전히 배포되고 완전히 격리되어 있기 때문입니다. 사용자 노출 없이 검증할 수 있는 완벽한 프로덕션 복제본과 단일 원자적 스위치를 얻을 수 있습니다. 카나리는 그 깔끔한 게이트를 점진적인 노출과 실시간 모니터링에 더 의존하는 방식으로 교환합니다. 대부분의 API 기반 서비스의 경우, 블루-그린과 전환 전 스위트 조합이 유지보수 기간 없이 높은 신뢰도를 얻는 가장 간단한 방법입니다.

실제 적용 사례

결제 API를 운영하는 핀테크 팀은 모든 릴리스에 블루-그린을 사용합니다. 잘못된 배포가 단순한 시각적 버그가 아니라 실패한 트랜잭션이기 때문입니다. 이들의 게이트는 인증, 멱등성 키, 통화 반올림, 웹훅 서명을 다루는 그린에 대한 40개 시나리오 스위트입니다. 전체 실행은 약 6분이 소요됩니다. 모든 것이 완전히 그린 상태가 되기 전에는 아무것도 프로덕션에 도달하지 않으며, 감사 추적을 위해 모든 배포에 HTML 보고서가 첨부됩니다.

공개 API를 사용하는 SaaS 팀은 더 간소화된 버전을 실행합니다. 그린에 대한 12개 시나리오 스모크 게이트를 실행한 다음 전환하고, 이후 라이브 URL에 대해 전환 후 스모크 테스트를 실행합니다. 필드 형태가 변경될 때 서드파티 통합이 크게 중단될 수 있으므로, 이들의 우선순위는 스키마 드리프트를 감지하는 것입니다. 모든 응답에 대한 스키마 단언이 이들의 게이트의 핵심입니다.

두 팀 모두 Apidog에서 시나리오를 한 번 구축하고, 모든 푸시에서 CLI를 통해 자동으로 실행합니다. 데스크톱 앱은 엔지니어가 시나리오를 디버깅하고 확장하는 장소로 유지되며, 파이프라인은 동일한 시나리오가 릴리스 게이트가 되는 곳입니다.

결론

블루-그린 배포는 모든 릴리스 전에 유휴 상태로 대기하는 프로덕션의 무료, 완전 배포된 복사본을 제공합니다. 얕은 상태 프로브만 확인하여 이를 낭비하는 것은 팀이 다운타임 없는 전략으로 문제를 배포하는 가장 흔한 방법입니다. 해결책은 스위치를 전환하기 전에 사용자처럼 그린 환경을 테스트하는 것입니다.

구성 요소:

Apidog에서 실제 테스트 시나리오(인증, 읽기, 쓰기, 부정적인 경우, 스키마 단언)를 한 번 구축합니다.
기본 URL에 환경 변수를 사용하여 동일한 스위트가 그린과 블루 환경에서 변경 없이 실행되도록 합니다.
빠른 스모크 테스트를 먼저 실행한 다음, 그린 환경을 가리키는 전체 스위트를 실행합니다.
파이프라인에서 스위트의 종료 코드로 전환 여부를 결정하여 실패 시 스위치를 차단합니다.
모니터링 기간 동안 블루를 준비 상태로 유지하여 즉각적인 롤백을 가능하게 합니다.

이것을 한 번 설정하면 모든 배포가 자동으로 동일한 게이트를 거치게 됩니다. Apidog를 다운로드하여 준비도 스위트를 구축하고, CI 구성을 생성하고, 전환 단계 전에 apidog run 단계를 파이프라인에 추가하십시오. 첫 번째 실제 사용자가 첫 번째 실제 테스트가 되어서는 안 됩니다.

다운로드 버튼

자주 묻는 질문

블루-그린 배포란 무엇인가요? 두 개의 동일한 프로덕션 환경을 실행하고 그 사이에서 모든 트래픽을 전환하는 것입니다. 하나(블루)는 실제 사용자에게 서비스를 제공하고 다른 하나(그린)는 새 버전을 받습니다. 그린을 테스트한 다음 단일 스위치를 전환하여 그린이 라이브가 되도록 합니다. 블루는 즉각적인 롤백 대상으로 유지됩니다.

트래픽을 전환하기 전에 그린 환경을 어떻게 테스트하나요? 전환 단계 전에 그린 환경의 기본 URL을 가리키도록 API 테스트 스위트를 설정하고 파이프라인에서 실행하십시오. Apidog CLI를 사용하여 apidog run으로 그린 환경에 대해 시나리오를 실행하고, 어떤 단언(assertion)이라도 실패하면 배포를 중단하고, 스위트가 통과하는 경우에만 트래픽을 전환하십시오.

블루-그린에 로드 밸런서 상태 확인만으로는 충분하지 않은 이유는 무엇인가요? 상태 확인은 일반적으로 하나의 엔드포인트를 핑하고 200을 확인하며, 이는 프로세스가 실행 중임을 증명할 뿐입니다. 이름이 변경된 JSON 필드, 실패한 마이그레이션, 손상된 인증 흐름 또는 스키마 변경을 감지하지 못합니다. 실제 API 테스트 스위트는 응답 본문, 스키마 및 오류 사례에 대해 단언하므로, 상태 프로브가 놓치는 실패를 잡아냅니다.

데스크톱 앱에서 구축한 동일한 API 테스트를 CI에서 실행할 수 있나요? 네, 가능합니다. Apidog에서 시각적으로 구축한 시나리오는 Apidog CLI에서 변경 없이 실행됩니다. 시나리오에 대한 CI 구성을 생성한 다음, GitHub Actions, GitLab CI, Jenkins 또는 모든 파이프라인에서 해당 구성으로 apidog run을 호출합니다. CLI는 실패 시 0이 아닌 값으로 종료되며, 이를 통해 배포를 제어할 수 있습니다.

블루-그린 배포와 카나리 배포의 테스트 방식 차이는 무엇인가요? 블루-그린은 완전히 배포된 그린 환경을 테스트한 후 모든 트래픽을 한 번에 전환하므로, 게이트는 전환 전에 있습니다. 카나리는 트래픽을 작은 부분으로 점진적으로 이동시키고 해당 부분의 실시간 모니터링에 의존합니다. 블루-그린은 더 깔끔한 릴리스 전 테스트 게이트를 제공하며, 카나리는 점진적인 실제 환경 노출을 제공합니다.

그린 프로덕션 환경에 대해 쓰기 경로 테스트를 실행해야 하나요? 데이터에 주의하십시오. 기록을 정리하는 전용 테스트 계정을 사용하거나, 데이터 계층을 승격하기 전에 스테이징 데이터베이스로 지원되는 그린 인스턴스에 대해 쓰기 테스트를 실행하십시오. 목표는 프로덕션 데이터를 오염시키지 않고 동작을 검증하는 것이며, 이는 샌드박스와 실제 프로덕션 테스트 사이의 경계입니다.

전환 전 테스트 게이트는 얼마나 빨라야 하나요? 나누십시오. 30초 이내에 3~5개의 핵심 경로 요청으로 구성된 스모크 테스트를 실행하여 빠르게 실패를 감지하고, 스모크 테스트가 통과하는 경우에만 전체 스위트(모든 엔드포인트, 오류 사례, 스키마 확인)를 실행하십시오. 수십 개의 시나리오로 구성된 완전한 게이트는 보통 몇 분 안에 완료되며, 이는 릴리스 게이트로서 허용 가능한 시간입니다.