Amazon ECS 블루/그린 배포에 대한 Service Connect 리소스 - Amazon Elastic Container Service
아키텍처 개요트래픽 라우팅 및 테스트Service Connect 블루/그린 배포 워크플로

Amazon ECS 블루/그린 배포에 대한 Service Connect 리소스

블루/그린 배포와 함께 Service Connect를 사용하는 경우 블루 및 그린 서비스 개정 사이에서 트래픽을 적절히 라우팅할 수 있도록 특정 구성 요소를 구성해야 합니다. 이 섹션에서는 필수 구성 요소 및 해당 구성에 대해 설명합니다.

아키텍처 개요

Service Connect는 Amazon ECS 태스크에 자동으로 삽입되는 관리형 사이드카 프록시를 통해 서비스 검색 및 서비스 메시 기능을 모두 빌드합니다. 이러한 프록시는 라우팅 결정, 재시도 및 지표 수집을 처리하는 반면 AWS Cloud Map에서는 서비스 레지스트리 백엔드를 제공합니다. Service Connect가 활성화된 상태로 서비스를 배포하면 서비스가 자체적으로 AWS Cloud Map에 등록되고 클라이언트 서비스가 네임스페이스를 통해 이를 검색합니다.

표준 Service Connect 구현에서 클라이언트 서비스는 논리적 서비스 이름에 연결되고 사이드카 프록시는 실제 서비스 인스턴스로의 라우팅을 처리합니다. 블루/그린 배포의 경우 이 모델은 testTrafficRules 구성을 통한 테스트 트래픽 라우팅을 포함하도록 확장됩니다.

블루/그린 배포 중에 다음 주요 구성 요소가 함께 작동합니다.

  • Service Connect 프록시: 서비스 간 모든 트래픽은 구성을 기반으로 라우팅 결정을 내리는 Service Connect 프록시를 통과합니다.

  • AWS Cloud Map 등록: 블루 및 그린 배포 모두가 AWS Cloud Map에 등록되지만 그린 배포는 처음에 "테스트" 엔드포인트로 등록됩니다.

  • 테스트 트래픽 라우팅: Service Connect 구성의 testTrafficRules는 테스트 트래픽을 식별하고 그린 배포로 라우팅하는 방법을 결정합니다. 이는 요청의 특정 HTTP 헤더가 트래픽을 테스트 개정으로 보내는 헤더 기반 라우팅을 통해 수행됩니다. 기본적으로 Service Connect는 사용자 지정 규칙이 지정되지 않은 경우 HTTP 기반 프로토콜의 x-amzn-ecs-blue-green-test 헤더를 인식합니다.

  • 클라이언트 구성: 네임스페이스의 모든 클라이언트는 프로덕션 및 테스트 경로를 모두 자동으로 수신하지만 테스트 규칙과 일치하는 요청만 그린 배포로 이동합니다.

이 접근 방식이 강력한 이유는 전환 중 서비스 검색의 복잡성을 처리한다는 점 때문입니다. 트래픽이 블루에서 그린 배포로 전환되면 모든 연결 및 검색 메커니즘이 자동으로 업데이트됩니다. DNS 레코드를 업데이트하거나 로드 밸런서를 재구성하거나, 서비스 검색 변경 내용을 별도로 배포할 필요가 없습니다. 서비스 메시가 이 작업을 모두 처리하기 때문입니다.

트래픽 라우팅 및 테스트

Service Connect는 테스트 시나리오에 대한 헤더 기반 라우팅 및 클라이언트 별칭 구성을 포함하여 블루/그린 배포에 대한 고급 트래픽 라우팅 기능을 제공합니다.

테스트 트래픽 헤더 규칙

블루/그린 배포 중에 테스트 목적을 위해 특정 요청을 그린(신규) 서비스 개정으로 라우팅하도록 테스트 트래픽 헤더 규칙을 구성할 수 있습니다. 이렇게 하면 배포를 완료하기 전에 트래픽을 제어하며 새 버전을 검증할 수 있습니다.

Service Connect는 헤더 기반 라우팅을 사용하여 테스트 트래픽을 식별합니다. 기본적으로 Service Connect는 사용자 지정 규칙이 지정되지 않은 경우 HTTP 기반 프로토콜의 x-amzn-ecs-blue-green-test 헤더를 인식합니다. 요청에 이 헤더가 있으면 Service Connect 프록시는 테스트를 위해 요청을 그린 배포로 자동으로 라우팅합니다.

테스트 트래픽 헤더 규칙을 사용하면 다음을 수행할 수 있습니다.

  • 특정 헤더가 있는 요청을 그린 서비스 개정으로 라우팅

  • 트래픽 하위 집합을 사용하여 새 기능 테스트

  • 전체 트래픽 전환 전에 서비스 동작 검증

  • 카나리 테스트 전략 구현

  • 프로덕션과 유사한 환경에서 통합 테스트 수행

헤더 기반 라우팅 메커니즘은 기존 애플리케이션 아키텍처에서 원활하게 작동합니다. 클라이언트 서비스는 블루/그린 배포 프로세스를 인식하지 않아도 됩니다. 테스트 요청을 보낼 때 적절한 헤더를 포함하면 Service Connect 프록시가 라우팅 로직을 자동으로 처리합니다.

테스트 트래픽 헤더 규칙을 구성하는 방법에 대한 자세한 내용은 Amazon Elastic Container Service API 참조의 ServiceConnectTestTrafficHeaderRules를 참조하세요.

헤더 일치 규칙

헤더 일치 규칙은 블루/그린 배포 중에 테스트 트래픽을 라우팅하기 위한 기준을 정의합니다. 그린 서비스 개정으로 라우팅되는 요청을 정확하게 제어하기 위해 여러 일치 조건을 구성할 수 있습니다.

헤더 일치에서는 다음을 지원합니다.

  • 정확한 헤더 값 일치

  • 헤더 존재 확인

  • 패턴 기반 일치

  • 여러 헤더 조합

사용 사례 예제에는 테스트를 위해 특정 사용자 에이전트 문자열, API 버전 또는 기능 플래그가 있는 요청을 그린 서비스로 라우팅하는 작업이 포함됩니다.

헤더 일치 구성에 대한 자세한 내용은 Amazon Elastic Container Service API 참조의 ServiceConnectTestTrafficHeaderMatchRules를 참조하세요.

블루/그린 배포에 대한 클라이언트 별칭

클라이언트 별칭은 블루/그린 배포 중 서비스에 안정적인 DNS 엔드포인트를 제공합니다. 이를 통해 클라이언트 애플리케이션이 연결 엔드포인트를 변경하지 않고도 블루 및 그린 서비스 개정 간에 원활한 트래픽 라우팅을 지원합니다.

블루/그린 배포 중에 클라이언트 별칭은 다음과 같은 기능을 수행합니다.

  • 클라이언트 연결을 위해 일관된 DNS 이름 유지 관리

  • 서비스 개정 간 자동 트래픽 전환 활성화

  • 점진적 트래픽 마이그레이션 전략 지원

  • 트래픽을 블루 개정으로 리디렉션하여 롤백 기능 제공

여러 포트 또는 프로토콜에 대해 여러 클라이언트 별칭을 구성하여 배포 중에 복잡한 서비스 아키텍처에서 연결을 유지할 수 있습니다.

클라이언트 별칭 구성에 대한 자세한 내용은 Amazon Elastic Container Service API 참조의 ServiceConnectClientAlias를 참조하세요.

트래픽 라우팅 모범 사례

Service Connect를 사용하는 블루/그린 배포에 대한 트래픽 라우팅을 구현하는 경우 다음 모범 사례를 고려하세요.

  • 헤더 기반 테스트로 시작: 테스트 트래픽 헤더 규칙을 사용하여 모든 트래픽을 전환하기 전에 트래픽을 제어하며 그린 서비스를 검증합니다.

  • 상태 확인 구성: 블루 및 그린 서비스 모두에서 비정상 인스턴스로 트래픽을 라우팅하지 않도록 적절한 상태 확인이 구성되어 있는지 확인합니다.

  • 서비스 지표 모니터링: 배포 중에 두 서비스 개정에 대한 주요 성능 지표를 추적하여 문제를 조기에 식별합니다.

  • 롤백 전략 계획: 문제가 감지되면 블루 서비스로 빠르게 롤백할 수 있도록 클라이언트 별칭 및 라우팅 규칙을 구성합니다.

  • 헤더 일치 로직 테스트: 프로덕션 배포에 적용하기 전에 비프로덕션 환경에서 헤더 일치 규칙을 검증합니다.

Service Connect 블루/그린 배포 워크플로

Service Connect가 블루/그린 배포 프로세스를 관리하는 방법을 이해하면 배포를 효과적으로 구현하고 문제를 해결하는 데 도움이 됩니다. 다음 워크플로는 배포의 각 단계에서 서로 다른 구성 요소가 상호 작용하는 방식을 보여줍니다.

배포 단계

Service Connect 블루/그린 배포는 다음과 같은 여러 개별 단계를 통해 진행됩니다.

  1. 초기 상태: 블루 서비스가 프로덕션 트래픽의 100%를 처리합니다. 네임스페이스의 모든 클라이언트 서비스는 Service Connect에 구성된 논리적 서비스 이름을 통해 블루 서비스에 연결됩니다.

  2. 그린 서비스 등록: 그린 배포가 시작되면 AWS Cloud Map에 '테스트' 엔드포인트로 등록됩니다. 클라이언트 서비스의 Service Connect 프록시는 프로덕션 및 테스트 라우팅 구성을 모두 자동으로 수신합니다.

  3. 테스트 트래픽 라우팅: 테스트 트래픽 헤더(예: x-amzn-ecs-blue-green-test)가 포함된 요청이 Service Connect 프록시에 의해 자동으로 그린 서비스로 라우팅됩니다. 프로덕션 트래픽은 계속해서 블루 서비스로 흐릅니다.

  4. 트래픽 전환 준비: 테스트에 성공하면 배포 프로세스가 프로덕션 트래픽 전환을 준비합니다. 블루 및 그린 서비스는 모두 등록되고 정상 상태로 유지됩니다.

  5. 프로덕션 트래픽 전환: 프로덕션 트래픽을 그린 서비스로 라우팅하도록 Service Connect 구성이 업데이트됩니다. 이는 클라이언트 서비스 업데이트 또는 DNS 변경 없이 자동으로 수행됩니다.

  6. 베이크 소요 시간(기간): 프로덕션 트래픽이 전환된 후 블루 및 그린 서비스 개정이 동시에 실행되는 기간.

  7. 블루 서비스 등록 취소: 트래픽 이동 및 검증에 성공하면 블루 서비스가 AWS Cloud Map에서 등록 취소되고 종료되며 배포가 완료됩니다.

Service Connect 프록시 동작

Service Connect 프록시는 블루/그린 배포 중에 트래픽을 관리하는 데 중요한 역할을 합니다. 이 동작을 이해하면 효과적인 테스트 및 배포 전략을 설계하는 데 도움이 됩니다.

블루/그린 배포 중 주요 프록시 동작:

  • 자동 경로 검색: 프록시는 애플리케이션을 다시 시작하거나 구성을 변경할 필요 없이 AWS Cloud Map에서 프로덕션 및 테스트 경로를 모두 자동으로 검색합니다.

  • 헤더 기반 라우팅: 프록시는 수신 요청 헤더를 검사하고 구성된 테스트 트래픽 규칙에 따라 트래픽을 적절한 서비스 개정으로 라우팅합니다.

  • 상태 확인 통합: 프록시는 정상 서비스 인스턴스로만 트래픽을 라우팅하며, 라우팅 풀에서 비정상 태스크를 자동으로 제외합니다.

  • 재시도 및 회로 차단: 프록시는 기본 제공 재시도 로직 및 회로 차단 기능을 제공하며 이를 통해 배포 중 복원력을 개선합니다.

  • 지표 수집: 프록시는 블루 및 그린 서비스 모두에 대한 자세한 지표를 수집하여 배포 중에 포괄적인 모니터링을 지원합니다.

서비스 검색 업데이트

블루/그린 배포에 Service Connect를 사용하는 경우 주요 이점 중 하나는 서비스 검색 업데이트의 자동 처리입니다. 기존 블루/그린 배포에는 복잡한 DNS 업데이트 또는 로드 밸런서 재구성이 필요한 경우가 많지만 Service Connect는 이러한 변경 내용을 투명하게 관리합니다.

배포 중에 Service Connect는 다음을 처리합니다.

  • 네임스페이스 업데이트: Service Connect 네임스페이스는 적절한 라우팅 규칙과 함께 블루 및 그린 서비스 엔드포인트를 모두 자동으로 포함합니다.

  • 클라이언트 구성: 네임스페이스의 모든 클라이언트 서비스는 다시 시작하거나 재배포할 필요 없이 업데이트된 라우팅 정보를 자동으로 수신합니다.

  • 점진적 전환: 서비스 검색 업데이트가 점진적으로 안전하게 수행되므로 진행 중인 요청이 중단되지 않습니다.

  • 롤백 지원: 롤백이 필요한 경우 Service Connect는 서비스 검색 구성을 빠르게 되돌려 트래픽을 블루 서비스로 다시 라우팅할 수 있습니다.