VPC Amazon ECS 서비스 간 네트워킹

VPC Amazon ECS 컨테이너를 사용하면 모놀리식 애플리케이션을 별도의 부분으로 분산시켜 안전한 환경에서 독립적으로 배포 및 확장할 수 있습니다. 그러나 VPC 안팎에서 이러한 모든 부분이 서로 통신할 수 있는지 확인하는 것은 어려울 수 있습니다. 서로 다른 장점과 단점을 가진 의사 소통을 촉진하기위한 몇 가지 방법이 있습니다.

서비스 검색 사용

서비스 대 서비스 통신의 한 가지 방법은 서비스 검색을 사용한 직접 통신입니다. 이 방법에서는 사용할 수 있는AWS Cloud Map서비스 검색을 Amazon ECS와 통합합니다. Amazon ECS는 서비스 검색을 사용하여 시작된 작업 목록을AWS Cloud Map는 특정 서비스의 하나 이상의 작업에 대한 내부 IP 주소로 확인되는 DNS 호스트 이름을 유지 관리합니다. Amazon VPC 다른 서비스는 이 DNS 호스트 이름을 사용하여 내부 IP 주소를 사용하여 트래픽을 다른 컨테이너로 직접 전송할 수 있습니다. 자세한 내용은 단원을 참조하십시오.서비스 검색의Amazon Elastic Container Service.

위 다이어그램에서 세 가지 서비스가 있습니다.serviceA에는 하나의 컨테이너가 있고serviceB에는 두 개의 컨테이너가 있습니다.serviceB와 통신해야 합니다.serviceC에는 하나의 컨테이너가 있습니다. 이러한 세 가지 서비스 모두의 각 컨테이너는AWS Cloud Map를 사용하여 통신해야하는 다운스트림 서비스에서 컨테이너의 내부 IP 주소를 찾습니다.

서비스 간 통신에 대한 이러한 접근 방식은 짧은 대기 시간을 제공합니다. 언뜻보기에는 컨테이너 사이에 추가 구성 요소가 없으므로 간단합니다. 트래픽은 한 컨테이너에서 다른 컨테이너로 직접 이동합니다.

이 방법은 사용할 때 적합합니다awsvpc네트워크 모드입니다. 각 작업에는 고유 한 IP 주소가 있습니다. 대부분의 소프트웨어는 DNS 사용만을 지원합니다.A레코드는 IP 주소로 직접 해석됩니다. 를 사용할 때awsvpc네트워크 모드에서 각 작업의 IP 주소는A레코드. 그러나 를 사용하는 경우bridge네트워크 모드에서 여러 컨테이너가 동일한 IP 주소를 공유 할 수 있습니다. 또한 동적 포트 매핑으로 인해 컨테이너에 해당 단일 IP 주소에서 포트 번호가 임의로 할당됩니다. 이 시점에서A레코드가 더 이상 서비스 검색에 충분하지 않습니다. 또한 사용 해야 합니다.SRV레코드. 이러한 유형의 레코드는 IP 주소와 포트 번호를 모두 추적할 수 있지만 응용 프로그램을 적절히 구성해야 합니다. 사용하는 일부 사전 빌드된 응용 프로그램은SRV레코드.

의 또 다른 장점은awsvpc네트워크 모드는 각 서비스에 대해 고유한 보안 그룹을 가지고 있다는 것입니다. 해당 서비스와 통신해야 하는 특정 업스트림 서비스에서 들어오는 연결만 허용하도록 이 보안 그룹을 구성할 수 있습니다.

서비스 검색을 사용하는 직접적인 서비스 간 통신의 주된 단점은 재시도를 하고 연결 실패를 처리하기 위해 추가 논리를 구현해야 한다는 것입니다. DNS 레코드는 TTL (Time TTTTL) 기간을 통해 캐싱되는 기간을 제어할 수 있습니다. 애플리케이션이 DNS 레코드의 최신 버전을 선택할 수 있도록 DNS 레코드가 업데이트되고 캐시가 만료되려면 약간의 시간이 걸립니다. 따라서 응용 프로그램이 더 이상 존재하지 않는 다른 컨테이너를 가리 키도록 DNS 레코드를 해결 할 수 있습니다. 응용 프로그램은 재시도를 처리하고 잘못된 백엔드를 무시하는 논리가 있어야합니다.

내부 로드 밸런서 사용

서비스 간 통신에 대한 또 다른 방법은 내부 부하 분산 장치를 사용하는 것입니다. 내부 로드 밸런서는 전적으로 VPC 내부에 존재하며 VPC 내부의 서비스에서만 액세스할 수 있습니다.

로드 밸런서는 중복 리소스를 각 서브넷에 배포하여 고가용성을 유지합니다. 때 컨테이너에서serviceA에서 컨테이너와 통신해야합니다.serviceB로 설정하면 로드 밸런서에 대한 연결을 엽니다. 그런 다음 로드 밸런서는 컨테이너에 대한 연결을service B. 로드 밸런서는 각 서비스 간의 모든 연결을 관리하기 위한 중앙 집중화된 장소 역할을 수행합니다.

에서 컨테이너의 경우serviceB가 중지되면 로드 밸런서가 풀에서 해당 컨테이너를 제거 할 수 있습니다. 또한 로드 밸런서는 풀의 각 다운스트림 대상에 대해 상태 확인을 수행하고 다시 정상 상태가 될 때까지 풀에서 잘못된 대상을 자동으로 제거할 수 있습니다. 응용 프로그램은 더 이상 다운스트림 컨테이너가 몇 개인지 알 필요가 없습니다. 로드 밸런서에 대한 연결을 열기만 하면 됩니다.

이 방법은 모든 네트워크 모드에 유리합니다. 로드 밸런서는 작업 IP 주소를 추적할 수 있습니다.awsvpc네트워크 모드를 사용할 때 IP 주소와 포트의 고급 조합뿐만 아니라bridge네트워크 모드. 여러 컨테이너가 실제로 동일한 Amazon EC2 인스턴스에서 다른 포트에서 호스팅되는 경우에도 모든 IP 주소와 포트 조합에 걸쳐 트래픽을 균등하게 분산합니다.

이 접근법의 한 가지 단점은 비용입니다. 고가용성을 유지하려면 로드 밸런서에 각 가용 영역에 리소스가 있어야 합니다. 이렇게 하면 로드 밸런서를 지불하는 오버헤드와 로드 밸런서를 통과하는 트래픽 양 때문에 추가 비용이 추가됩니다.

그러나 여러 서비스가 하나의 로드 밸런서를 공유하도록 함으로써 오버헤드 비용을 줄일 수 있습니다. 이는 Application Load Balancer 서를 사용하는 REST 서비스에 특히 적합합니다. 트래픽을 서로 다른 서비스로 라우팅하는 경로 기반 라우팅 규칙을 생성할 수 있습니다. 예,/api/user/*의 일부인 컨테이너로 라우팅 할 수 있습니다.user서비스, 반면/api/order/*로 라우팅할 수 있는order서비스를 선택합니다. 이 방법을 사용하면 하나의 Application Load Balancer 대해서만 비용을 지불하고 API에 대해 하나의 일관된 URL을 보유할 수 있습니다. 그러나 백엔드의 다양한 마이크로 서비스로 트래픽을 분할 할 수 있습니다.

서비스 메시 사용

AWS App Mesh는 많은 수의 서비스를 관리하고 서비스 간에 트래픽이 라우팅되는 방식을 더 잘 제어할 수 있는 서비스 메시입니다. App Mesh 는 기본 서비스 검색과 부하 분산 간의 중개자 역할을 합니다. App Mesh 사용하면 응용 프로그램이 서로 직접 상호 작용하지 않지만 중앙 집중식 부하 분산 장치도 사용하지 않습니다. 대신 작업의 각 복사본에는 Envoy 프록시 사이드카가 함께 제공됩니다. 자세한 내용은 단원을 참조하십시오.란 무엇입니까?AWS App Mesh의AWS App Mesh사용 설명서.

위 다이어그램에서 각 작업에는 Envoy 프록시 사이드카가 있습니다. 이 사이드카는 작업에 대한 모든 인바운드 및 아웃바운드 트래픽을 프록시합니다. App Mesh 컨트롤 플레인은AWS Cloud Map를 사용하여 사용 가능한 서비스 목록과 특정 작업의 IP 주소를 가져올 수 있습니다. 그런 다음 App Mesh 는 Envoy 프록시 사이드카에 구성을 전달합니다. 이 구성에는 연결할 수있는 사용 가능한 컨테이너 목록이 포함됩니다. 또한 Envoy 프록시 사이드카는 각 대상에 대해 상태 확인을 수행하여 사용 가능한지 확인합니다.

이 접근 방식은 관리 부하 분산 장치의 용이성과 함께 서비스 검색 기능을 제공합니다. Envoy 프록시 사이드카가 해당 부하 분산을 처리하므로 응용 프로그램은 코드 내에 많은 부하 분산 논리를 구현하지 않습니다. Envoy 프록시는 실패를 감지하고 실패한 요청을 다시 시도하도록 구성할 수 있습니다. 또한 MTL을 사용하여 전송 중인 트래픽을 암호화하고 응용 프로그램이 확인된 대상과 통신하고 있는지 확인하도록 구성할 수도 있습니다.

Envoy 프록시와 로드 밸런서 간에는 몇 가지 차이점이 있습니다. 즉, Envoy 프록시를 사용하면 자체 Envoy 프록시 사이드카를 배포하고 관리할 책임이 있습니다. Envoy 프록시 사이드카는 사용자가 Amazon ECS 작업에 할당하는 일부 CPU와 메모리를 사용합니다. 이렇게 하면 작업 리소스 소비에 약간의 오버헤드가 추가되고 필요할 때 프록시를 유지 관리하고 업데이트하기 위한 추가 운영 워크로드가 추가됩니다.

App Mesh 및 Envoy 프록시를 사용하면 작업 간 대기 시간이 매우 짧습니다. 이는 Envoy 프록시가 각 작업에 배치되기 때문입니다. 하나의 Envoy 프록시와 다른 Envoy 프록시 사이에는 네트워크 점프를 인스턴스화하는 인스턴스가 하나만 있습니다. 즉, 로드 밸런서를 사용할 때와 비교하여 네트워크 오버헤드가 적습니다. 로드 밸런서를 사용할 때 두 개의 네트워크 점프가 있습니다. 첫 번째는 업스트림 작업에서 로드 밸런서로, 두 번째는 로드 밸런서에서 다운스트림 작업으로 이어집니다.