[AWS] ECS Service Connect vs Service Discovery

01. ECS Service Discovery vs Service Connect

컨테이너가 가지고 있는 IP 주소는 매번 동적으로 변경되기 때문에, 서비스끼리 통신할때 고정된 IP 주소를 미리 알 수 없다는 문제가 발생한다. ECS Service Discovery나 Service Connect는 이러한 문제를 해결하기 위한 기술이다.

01-1. ECS Service Discovery?

Route53의 프라이빗 호스팅 영역과 AWS Cloud Map을 결합하여 ECS Service에 고정된 DNS 이름을 부여하는 방법이다.

1. ECS Service Discovery 설정 시 내부 흐름

Route53의 호스팅영역은 CloudMap에서 지정한 네임스페이스(Namespace)의 인스턴스 검색 여부에 따라 달라지는 것으로 보인다. “VPC에서 API 호출 및 DNS 쿼리”를 지정하면 호스팅 영역이 프라이빗으로 구성이 될것이고, “API 호출 및 퍼블릭 DNS 쿼리”를 지정하면 호스팅 영역이 퍼블릭으로 구성이 될것같다.

1. 사용자가 ECS 서비스(Service)를 만들면서 ‘서비스 검색’을 설정하면, Cloud Map에 네임스페이스(Namespace)와 그 안의 서비스(Service)라는 이름표가 먼저 생성된다.
   ex) 네임스페이스(order-service-ecs-ns-stg) 안에 서비스(order-service)가 생성됨.
2. 실제 태스크(Task)가 실행되어 고유한 IP를 할당받으면, ECS가 CloudMap의 ‘서비스’ 항목 아래에 해당 IP를 인스턴스(Instance)라는 이름으로 등록한다.
3. 이때, Route53의 호스팅영역이 생성이되고 해당 호스팅영역의 도메인명은 CloudMap의 네임스페이스(Namespace)로 지정이 되며, 레코드의 경우 CloudMap의 서비스명으로 결정이 된다. 또한, 인스턴스의 값(ECS IP)는 레코드의 값으로 지정이 되며 1개의 레코드 이름(api.local)에 N개의 IP 주소가 리스트 형태로 저장이 된다.

Cloud Map (관리 단위)	Route 53 (실제 데이터)	예시 (Namespace: local, Service: api)
네임스페이스 (NS) 🌐	호스팅 영역 도메인 이름	local
서비스 (Service) 🏷️	DNS 레코드 이름 (FQDN)	api.local (서비스명 + 네임스페이스)
인스턴스 (Instance) 📍	레코드 값 (Value)	10.0.0.1 (해당 태스크의 IP)의 IP)

2. 실제 ECS Service간 통신은 어떻게 이루어 지는지?

1. ECS Service A의 컨테이너(Container)가 ECS Service B에 요청하기 위해 api.local와 같은 도메인을 요청한다.
2. 프라이빗 호스팅 영역의 도메인인 경우 내부 VPC Resolver에 의해 Route53 DNS로 요청을 수행한다.
3. Route53은 모든 태스크(Task)의 IP를 주는게 아닌, Cloud Map이 건강하다(Healthy)고 판단한 IP만 골라서 해당 IP를 반환한다. 건강하지 않은 IP는 자동으로 레코드에서 제외된다.

01-2. ECS Service Connect?

ECS Service Connect는 별도의 로드밸런서(LB)나 복잡한 DNS 설정 없이, Envoy(L7 Proxy Server) 형태의 사이드카(Sidecar) 컨테이너를 각 태스크(Task)별로 구동해서 ECS Service 간의 통신에 대한 중계 및 관리를 수행해주는 서비스 메시(Service Mesh) 기능이다.

1. ECS Service Connect 설정 시 내부 흐름

1. 사용자가 ECS 서비스 생성 시 “ECS 서비스 연결”을 선택하면 기본적으로 각 태스크(Task)에는 사이드카(Sidecar) 형태의 Envoy 컨테이너가 함께 구동된다.
2. CloudMap의 Namespace > 서비스명 > 인스턴스명 > IP/PORT명이 기재된다. 이때, Route53처럼 별도의 DNS 설정이 되지는 않는다.
3. ECS 컨트롤 플레인은 Cloud Map에 등록된 최신 IP 목록을 각 태스크(Task)의 Envoy 프록시에게 실시간으로 전달한다.
4. Envoy 프록시는 전달받은 정보를 바탕으로 내부적으로만 유효한 서비스 별칭(opensearch-api)를 활성화하여, 애플리케이션이 해당 이름으로 요청을 보낼 수 있게 준비한다.

2. 실제 ECS Service간 통신은 어떻게 이루어 지는지?

애플리케이션이 직접 통신을 담당하기 보다는 Envoy 컨테이너가 통신 담당

1. ECS 서비스 A의 애플리케이션이 ECS 서비스 B의 서비스 별칭(http://opensearch-api:8080)로 요청을 보낸다
2. Envoy는 ECS로부터 받은 최신 주소록 확인 후 여러개의 IP 중 가장 건강(Healthy)하고 부하가 적은 태스크를 직접 선택한다. (L7 수준 로드밸런싱)
3. 선택된 IP로 데이터를 전송한다. 이때 데이터는 자동으로 암호화되어 전송된다.
4. ECS 서비스 B의 Envoy 프록시가 요청 수신 후 애플리케이션에게 전달하고, 응답 역시 같은 경로로 되돌아온다.

03. ECS Service Connect 설정 및 옵션

개념적인 부분에 대한 차이는 정리가 된 것으로 보인다. 필자의 경우 ECS 서비스 간 신뢰성 있는 통신이 중요하다 판단이 되어 ECS Service Discovery를 사용하는 것이 아닌 ECS Service Connect를 사용하기로 결정했다. ECS Service Connect 생성 과정은 아래와 같다.

03-1. ECS Service Connect 설정

가장 먼저 해당 ECS 서비스가 네트워크상에서 어떤 역할(Role)을 수행할지 결정해야 한다.

• ECS 서비스 연결 사용 선택: 이 옵션을 활성화하면 각 태스크 내부에 통신을 중계할 Envoy 사이드카 컨테이너가 자동으로 함께 구동된다.
• ECS 서비스 연결 구성(모드 설정):
  • 클라이언트 측만 해당 (Consumer): 타 서비스에 요청을 보내기만 하는 서비스에 적합하다. 자체 엔드포인트가 생성되지 않으며 외부 노출이 필요 없는 경우 선택한다.
  • 클라이언트 및 서버 (Producer/Consumer): 요청을 보내는 동시에 다른 서비스로부터 요청을 받는 서버 역할도 수행한다. 네임스페이스 내에 엔드포인트 이름과 포트가 등록되어, 타 서비스가 호출할 수 있는 상태가 된다. (예: http://opensearch-api:8000)

03-2. 상세 파라미터 구성

서비스를 네임스페이스에 등록하고 실제 통신에 사용할 주소를 정의하는 단계이다.

• 네임스페이스(Namespace): 앞서 생성한 CloudMap 네임스페이스를 지정하여 통신 그룹을 설정한다.
• 서비스 포트 별칭 (Port Alias): 태스크 정의(Task Definition)의 portMapping 항목에 기재한 이름을 입력한다. 이는 어떤 포트를 Service Connect 네트워크에 노출할지 결정하는 기준이 된다.
• 검색(Discovery Name): 네임스페이스 내에서 서비스를 식별하는 고유 이름이다. 실제 통신 주소로 사용되지는 않지만, 관리 목적으로 사용된다.
• DNS (Alias): 가장 중요한 설정으로, 타 서비스들이 이 서비스를 호출할 때 사용할 실제 호스트 이름을 지정한다. (예: opensearch-api)
• 포트(Port): DNS Alias를 통해 접근할 때 사용할 포트 번호를 지정한다. 이는 실제 컨테이너가 노출한 포트와 매핑된다.
• 유휴 제한 시간 (Idle Timeout): 연결이 유휴 상태로 유지되는 최대 시간을 설정한다. 기본값은 3600초(1시간)이며, 이 시간이 지나면 연결이 자동으로 종료된다.

04. CloudMap 설정 관련

번외로 CloudMap 네임스페이스 설정에 대해서도 간략히 정리한다.

04-1. CloudMap 네임스페이스(Namespace) 생성 옵션

CloudMap 네임스페이스 생성 시 인스턴스 검색 방식에 따라 인프라 구성이 달라진다.

• API 호출: 오직 CloudMap API를 통해서만 인스턴스를 검색한다. Route 53 비용이 발생하지 않으며, Service Connect 환경에서 가장 권장되는 방식이다.
• VPC에서 API 호출 및 DNS 쿼리: API 호출과 동시에 VPC 내부의 Route 53 Private Hosted Zone에 DNS 레코드를 생성한다. 일반적인 DNS 질의가 필요한 경우 사용한다.
• API 호출 및 퍼블릭 DNS 쿼리: 인터넷 환경에서 접근 가능한 Public DNS 레코드를 생성한다.

04-2. IAM 권한 및 트러블슈팅

CloudMap 네임스페이스 생성 및 관리를 위해 servicediscovery 관련 권한이 필요하다. 특히 리소스를 생성할 때 태그(Tag)를 지정한다면, 반드시servicediscovery:TagResource 권한이 포함되어 있는지 확인해야 한다. 해당 권한이 누락될 경우 400 AccessDeniedException 오류와 함께 리소스 생성이 실패할 수 있다.