Amazon ECS blue/green, linear, canary 배포용 Service Connect 리소스

blue/green 배포와 함께 Service Connect를 사용할 때는 blue와 green 서비스 리비전 사이의 올바른 트래픽 라우팅을 활성화하기 위해 특정 구성 요소를 구성해야 해요. 이 섹션은 필요한 구성 요소와 그 구성을 설명합니다.

출처: 문서

본문

아키텍처 개요

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

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

blue/green 배포 중 다음 핵심 구성 요소가 함께 작동합니다:

Service Connect 프록시 – 서비스 간의 모든 트래픽이 Service Connect 프록시를 통과하며, 프록시가 구성에 따라 라우팅 결정을 내려요.
AWS Cloud Map 등록 – blue와 green 배포가 둘 다 AWS Cloud Map에 등록하지만, green 배포는 처음에 "test" 엔드포인트로 등록합니다.
테스트 트래픽 라우팅 – Service Connect 구성의 testTrafficRules가 테스트 트래픽을 식별하고 green 배포로 라우팅하는 방법을 결정해요. 이는 요청의 특정 HTTP 헤더가 트래픽을 테스트 리비전으로 보내는 헤더 기반 라우팅(header-based routing)을 통해 이루어집니다. 기본적으로 사용자 지정 규칙이 지정되지 않으면 Service Connect는 HTTP 기반 프로토콜에 대해 x-amzn-ecs-blue-green-test 헤더를 인식합니다.
클라이언트 구성 – 네임스페이스의 모든 클라이언트는 프로덕션 및 테스트 라우트를 모두 자동으로 받지만, 테스트 규칙과 일치하는 요청만 green 배포로 전달됩니다.

이 접근 방식을 강력하게 만드는 것은 전환 중에 서비스 검색의 복잡성을 처리한다는 점입니다. 트래픽이 blue에서 green 배포로 이동할 때 모든 연결성과 검색 메커니즘이 자동으로 업데이트됩니다. 서비스 메시가 모든 것을 처리하므로 DNS 레코드를 업데이트하거나, 로드 밸런서를 재구성하거나, 서비스 검색 변경을 별도로 배포할 필요가 없어요.

트래픽 라우팅 및 테스트

Service Connect는 blue/green 배포를 위한 고급 트래픽 라우팅 기능을 제공합니다. 여기에는 헤더 기반 라우팅과 테스트 시나리오를 위한 클라이언트 별칭 구성이 포함됩니다.

테스트 트래픽 헤더 규칙

blue/green 배포 중에는 특정 요청을 테스트 목적으로 green(새) 서비스 리비전으로 라우팅하도록 테스트 트래픽 헤더 규칙을 구성할 수 있어요. 이렇게 하면 배포를 완료하기 전에 통제된 트래픽으로 새 버전을 검증할 수 있습니다.

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

테스트 트래픽 헤더 규칙으로 다음을 할 수 있어요:

특정 헤더가 있는 요청을 green 서비스 리비전으로 라우팅
트래픽의 일부로 새 기능 테스트
전체 트래픽 전환 전에 서비스 동작 검증
카나리아(canary) 테스트 전략 구현
프로덕션과 유사한 환경에서 통합 테스트 수행

헤더 기반 라우팅 메커니즘은 기존 애플리케이션 아키텍처와 원활하게 작동합니다. 클라이언트 서비스는 blue/green 배포 프로세스를 알 필요가 없습니다. 테스트 요청을 보낼 때 적절한 헤더를 포함하기만 하면 Service Connect 프록시가 라우팅 로직을 자동으로 처리합니다.

중요: 테스트 트래픽 헤더 규칙은 Service Connect 서비스 포트 매핑의 appProtocol이 http, http2 또는 grpc로 설정되어 있어야 해요. 서비스가 애플리케이션 계층 프로토콜 없이 일반 TCP를 사용한다면(appProtocol이 설정되지 않음), blue/green 배포에 헤더 기반 testTrafficRules를 사용할 수 없습니다. 이 경우 포트 기반 테스트 트래픽 라우팅을 사용하세요.

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

헤더 일치 규칙

헤더 일치 규칙은 blue/green 배포 중 테스트 트래픽 라우팅의 기준을 정의해요. green 서비스 리비전으로 라우팅되는 요청을 정밀하게 제어하기 위해 여러 일치 조건을 구성할 수 있습니다.

헤더 일치는 다음을 지원합니다:

정확한 헤더 값 일치
헤더 존재 확인
패턴 기반 일치
여러 헤더 조합

사용 사례 예시로는 특정 사용자 에이전트 문자열, API 버전 또는 기능 플래그가 있는 요청을 테스트를 위해 green 서비스로 라우팅하는 것입니다.

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

blue/green 배포용 클라이언트 별칭

클라이언트 별칭(client aliases)은 blue/green 배포 중 서비스에 대한 안정적인 DNS 엔드포인트를 제공해요. 클라이언트 애플리케이션이 연결 엔드포인트를 변경할 필요 없이 blue와 green 서비스 리비전 사이의 원활한 트래픽 라우팅을 활성화합니다.

blue/green 배포 중 클라이언트 별칭은:

클라이언트 연결에 대해 일관된 DNS 이름 유지
서비스 리비전 사이의 자동 트래픽 전환 활성화
점진적 트래픽 마이그레이션 전략 지원
트래픽을 blue 리비전으로 리다이렉트해 롤백 기능 제공

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

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

트래픽 라우팅 모범 사례

Service Connect로 blue/green 배포의 트래픽 라우팅을 구현할 때 다음 모범 사례를 고려하세요:

헤더 기반 테스트로 시작 – 모든 트래픽을 전환하기 전에 테스트 트래픽 헤더 규칙으로 통제된 트래픽을 사용해 green 서비스를 검증하세요.
상태 확인 구성 – blue와 green 서비스 모두 비정상 인스턴스로 트래픽을 라우팅하지 않도록 적절한 상태 확인을 구성했는지 확인합니다.
서비스 지표 모니터링 – 배포 중 두 서비스 리비전 모두의 핵심 성능 지표를 추적해 문제를 조기에 식별합니다.
롤백 전략 계획 – 문제가 감지되면 blue 서비스로 빠른 롤백을 활성화하도록 클라이언트 별칭과 라우팅 규칙을 구성합니다.
헤더 일치 로직 테스트 – 프로덕션 배포에 적용하기 전에 비프로덕션 환경에서 헤더 일치 규칙을 검증합니다.

Service Connect blue/green 배포 워크플로

Service Connect가 blue/green 배포 프로세스를 관리하는 방법을 이해하면 배포를 효과적으로 구현하고 트러블슈팅하는 데 도움이 돼요. 다음 워크플로는 배포의 각 단계에서 서로 다른 구성 요소가 어떻게 상호 작용하는지 보여줍니다.

배포 단계

Service Connect blue/green 배포는 여러 개별 단계로 진행됩니다:

초기 상태(Initial State) – blue 서비스가 프로덕션 트래픽의 100%를 처리합니다. 네임스페이스의 모든 클라이언트 서비스가 Service Connect에 구성된 논리적 서비스 이름을 통해 blue 서비스에 연결합니다.
Green 서비스 등록(Green Service Registration) – green 배포가 시작되면 AWS Cloud Map에 "test" 엔드포인트로 등록합니다. 클라이언트 서비스의 Service Connect 프록시는 프로덕션 및 테스트 라우트 구성을 모두 자동으로 받습니다.
테스트 트래픽 라우팅(Test Traffic Routing) – 테스트 트래픽 헤더(예: x-amzn-ecs-blue-green-test)가 있는 요청은 Service Connect 프록시에 의해 자동으로 green 서비스로 라우팅됩니다. 프로덕션 트래픽은 blue 서비스로 계속 흐릅니다.
트래픽 전환 준비(Traffic Shift Preparation) – 성공적인 테스트 후 배포 프로세스는 프로덕션 트래픽 전환을 준비합니다. blue와 green 서비스가 모두 등록되고 정상 상태를 유지합니다.
프로덕션 트래픽 전환(Production Traffic Shift) – Service Connect 구성이 프로덕션 트래픽을 green 서비스로 라우팅하도록 업데이트됩니다. 이는 클라이언트 서비스 업데이트나 DNS 변경 없이 자동으로 발생합니다.
베이크 시간(Bake Time Period) – 프로덕션 트래픽이 전환된 후 blue와 green 서비스 리비전이 동시에 실행되는 기간.
Blue 서비스 등록 해제(Blue Service Deregistration) – 성공적인 트래픽 전환과 검증 후 blue 서비스가 AWS Cloud Map에서 등록 해제되고 종료되어 배포가 완료됩니다.

Service Connect 프록시 동작

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

blue/green 배포 중 핵심 프록시 동작:

자동 라우트 발견 – 프록시는 애플리케이션 재시작이나 구성 변경 없이 AWS Cloud Map에서 프로덕션 및 테스트 라우트를 자동으로 발견합니다.
헤더 기반 라우팅 – 프록시는 인바운드 요청 헤더를 검사하고 구성된 테스트 트래픽 규칙에 따라 트래픽을 적절한 서비스 리비전으로 라우팅합니다.
상태 확인 통합 – 프록시는 정상 서비스 인스턴스에만 트래픽을 라우팅하고, 비정상 태스크를 라우팅 풀에서 자동으로 제외합니다.
재시도 및 서킷 브레이킹 – 프록시는 내장 재시도 로직과 서킷 브레이킹 기능을 제공해 배포 중 복원력을 향상시킵니다.
지표 수집 – 프록시는 blue와 green 서비스 모두에 대한 상세 지표를 수집해 배포 중 포괄적인 모니터링을 가능하게 합니다.

서비스 검색 업데이트

blue/green 배포에 Service Connect를 사용하는 주요 이점 중 하나는 서비스 검색 업데이트를 자동으로 처리한다는 것입니다. 기존 blue/green 배포는 종종 복잡한 DNS 업데이트나 로드 밸런서 재구성이 필요하지만, Service Connect는 이러한 변경을 투명하게 관리합니다.

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

네임스페이스 업데이트 – Service Connect 네임스페이스는 적절한 라우팅 규칙과 함께 blue와 green 서비스 엔드포인트를 모두 자동으로 포함합니다.
클라이언트 구성 – 네임스페이스의 모든 클라이언트 서비스는 재시작이나 재배포 없이 업데이트된 라우팅 정보를 자동으로 받습니다.
점진적 전환 – 서비스 검색 업데이트는 점진적이고 안전하게 발생해 진행 중인 요청에 중단이 없도록 보장합니다.
롤백 지원 – 롤백이 필요하면 Service Connect가 서비스 검색 구성을 빠르게 되돌려 blue 서비스로 트래픽을 라우팅할 수 있습니다.