Amazon ECS Service Connect 구성 요소

Amazon ECS Service Connect를 사용하는 경우에는 네트워크 요청을 받는 서버 애플리케이션(클라이언트-서버 서비스)을 실행하거나 요청을 생성하는 클라이언트 애플리케이션(클라이언트 서비스)을 실행하도록 각 Amazon ECS 서비스를 구성합니다.

Service Connect 사용을 시작할 준비가 되면 클라이언트-서버 서비스로 시작합니다. 새 서비스 또는 기존 서비스에 Service Connect 구성을 추가할 수 있습니다. Amazon ECS는 네임스페이스에 Service Connect 엔드포인트를 생성합니다. 추가로 Amazon ECS는 서비스에 새 배포를 생성하여 현재 실행 중인 작업을 대체합니다.

기존 작업 및 기타 애플리케이션은 기존 엔드포인트 및 외부 애플리케이션에 계속 연결할 수 있습니다. 클라이언트-서버 서비스가 스케일 아웃을 통해 태스크를 추가하면 클라이언트의 새 연결이 모든 태스크 간에 즉시 밸런싱됩니다. 클라이언트-서버 서비스가 업데이트된 경우 클라이언트의 새 연결은 새 버전의 태스크 사이에서 밸런싱됩니다.

기존 작업은 확인할 수 없으며 새 엔드포인트에 연결할 수 없습니다. 동일한 네임스페이스에 Service Connect 구성이 있고 이 배포 이후에 실행을 시작하는 새 태스크만 이 엔드포인트를 확인하고 여기에 연결할 수 있습니다.

즉, 서버 애플리케이션 운영자가 언제든지 구성을 변경할 수 있더라도 클라이언트 애플리케이션 운영자가 앱 구성이 변경되는 시기를 결정합니다. 네임스페이스의 엔드포인트 목록은 네임스페이스의 서비스가 배포될 때마다 변경될 수 있습니다. 기존 태스크와 대체 태스크는 최근 배포 후에도 동일하게 작동합니다.

다음 예제를 살펴보세요.

먼저 퍼블릭 인터넷에서 사용할 수 있는 애플리케이션을 단일 AWS CloudFormation 템플릿 및 단일 AWS CloudFormation 스택으로 생성하고 있다고 가정해 보겠습니다. 공개 검색 및 연결 가능성은 프런트엔드 클라이언트 서비스를 포함하여 AWS CloudFormation에서 마지막으로 생성해야 합니다. 프런트엔드 클라이언트 서비스가 실행되고 퍼블릭에서 사용 가능하지만 백엔드는 사용할 수 없는 기간을 방지하려면 이 순서로 서비스를 생성해야 합니다. 이렇게 하면 해당 기간 동안 오류 메시지가 퍼블릭으로 전송되는 것을 방지할 수 있습니다. AWS CloudFormation에서는 dependsOn을 사용하여 AWS CloudFormation에 여러 Amazon ECS 서비스를 병렬로 또는 동시에 만들 수 없음을 나타내야 합니다. 클라이언트 작업이 연결되는 각 백엔드 클라이언트-서버 서비스의 프런트엔드 클라이언트 서비스에 dependsOn을 추가해야 합니다.

두 번째로 프런트엔드 서비스가 Service Connect 구성 없이 존재한다고 가정합니다. 작업은 기존 백엔드 서비스에 연결되고 있습니다. 먼저 DNS 또는 프런트엔드가 사용하는 clientAlias에서의 동일한 이름을 사용하여 백엔드 서비스에 클라이언트-서버 Service Connect 구성을 추가합니다. 이렇게 하면 새 배포가 생성되므로 모든 배포 롤백 탐지 또는 AWS Management Console, AWS CLI, AWS SDK 및 기타 메서드가 백엔드 서비스를 롤백하고 이전 배포 및 구성으로 되돌릴 수 있습니다. 백엔드 서비스의 성능과 동작이 만족스러우면 프런트엔드 서비스에 클라이언트 또는 클라이언트-서버 Service Connect 구성을 추가합니다. 새 배포의 작업만 새 작업에 추가된 Service Connect 프록시를 사용합니다. 이 구성에 문제가 있는 경우 배포 롤백 탐지 또는 AWS Management Console, AWS CLI, AWS SDK 및 기타 메서드를 사용하여 백엔드 서비스를 롤백하고 이전 배포 및 구성으로 되돌려 이전 구성으로 롤백하고 되돌릴 수 있습니다. Service Connect 대신 DNS를 기반으로 하는 다른 서비스 검색 시스템을 사용하는 경우 로컬 DNS 캐시가 만료된 후 프런트엔드 또는 클라이언트 애플리케이션이 새 엔드포인트를 사용하고 엔드포인트 구성을 변경하기 시작하며, 일반적으로 몇 시간이 걸립니다.

네트워킹

기본적으로 Service Connect 프록시는 태스크 정의 포트 매핑의 containerPort에서 수신 대기합니다. 보안 그룹 규칙은 클라이언트가 실행될 서브넷에서 이 포트로 들어오는(수신) 트래픽을 허용해야 합니다.

Service Connect 서비스 구성에서 포트 번호를 설정하더라도 Service Connect 프록시가 수신 대기하는 클라이언트-서버 서비스용 포트는 변경되지 않습니다. 이 포트 번호를 설정하면 Amazon ECS는 해당 작업 내의 Amazon ECS 프록시에서 클라이언트 서비스가 연결하는 엔드포인트의 포트를 변경합니다. 클라이언트 서비스의 프록시는 containerPort를 사용하여 클라이언트-서버 서비스의 프록시에 연결합니다.

Service Connect 프록시가 수신 대기하는 포트를 변경하려면 클라이언트-서버 서비스의 Service Connect 구성에서 ingressPortOverride를 변경합니다. 이 포트 번호를 변경하는 경우 이 서비스에 대한 트래픽에 사용되는 이 포트의 인바운드 트래픽을 허용해야 합니다.

애플리케이션이 Service Connect용으로 구성된 Amazon ECS 서비스로 전송하는 트래픽의 경우 Amazon VPC 및 서브넷에 사용 중인 containerPort 및 ingressPortOverride 포트 번호를 허용하는 라우팅 테이블 규칙 및 네트워크 ACL 규칙이 있어야 합니다.

Service Connect를 사용하여 VPC 간에 트래픽을 보낼 수 있습니다. 라우팅 테이블 규칙, 네트워크 ACL, 보안 그룹에 대한 동일한 요구 사항이 두 VPC에 모두 적용됩니다.

예를 들어, 두 개의 클러스터는 서로 다른 VPC에서 작업을 생성합니다. 각 클러스터의 서비스는 동일한 네임스페이스를 사용하도록 구성됩니다. 이 두 서비스의 애플리케이션은 VPC DNS 구성 없이 네임스페이스의 모든 엔드포인트를 확인할 수 있습니다. 하지만 VPC 피어링, VPC 또는 서브넷 라우팅 테이블, VPC 네트워크 ACL이 containerPort 및 ingressPortOverride 포트 번호의 트래픽을 허용하는 경우를 제외하면 프록시를 연결할 수 없습니다.

bridge 네트워킹 모드를 사용하는 작업의 경우 상위 동적 포트 범위에서 트래픽을 허용하는 인바운드 규칙이 포함된 보안 그룹을 생성해야 합니다. 그런 다음, Service Connect 클러스터의 모든 EC2 인스턴스에 보안 그룹을 할당합니다.

Service Connect 프록시

Service Connect 구성을 사용하여 서비스를 생성하거나 업데이트하는 경우 Amazon ECS는 새 태스크가 시작될 때마다 새 컨테이너를 추가합니다. 별도의 컨테이너를 사용하는 이러한 패턴을 sidecar라고 합니다. 이 컨테이너는 작업 정의에 없으며 구성할 수 없습니다. Amazon ECS는 서비스에서 컨테이너 구성을 관리합니다. 이렇게 하면 Service Connect 없이도 여러 서비스, 네임스페이스, 태스크 간에 동일한 태스크 정의를 재사용할 수 있습니다.

프록시 구성

애플리케이션은 수행 중인 동일한 작업에서 사이드카 컨테이너의 프록시에 연결합니다. Amazon ECS는 애플리케이션이 동일한 네임스페이스의 엔드포인트 이름에 연결되는 경우에만 애플리케이션이 프록시에 연결되도록 태스크와 컨테이너를 구성합니다. 다른 모든 트래픽은 프록시를 사용하지 않습니다. 다른 트래픽에는 동일한 VPC의 IP 주소, AWS 서비스 엔드포인트 및 외부 트래픽이 포함됩니다.

고려 사항

Service Connect를 사용할 때는 다음을 고려하세요.

Service Connect 사용 가능 리전

Amazon ECS Service Connect는 다음 AWS 리전에서 사용할 수 있습니다.