(전반적인 AWS 서비스는 AWS 자격증 준비 참고)

ECS 구조적 특징

ECS의 Docker host는 EC2 Instance이다.

우선 EC2 Instance는 결국 VM의 일종입니다. 하지만 초반 도커의 개념을 살필 때, VM구조보다 컨테이너 기반의 구조가 효율적이라는 것을 알았고 ECS처럼 VM을 이용하는 것이 아닌 Docker Container를 위한 전용 서버를 구축하는게 더 좋다는 생각을 할 수 있습니다.

그러지 않는 이유는 간단히 말하면 소비자 관점이라서 그렇습니다. AWS는 결국 EC2 서비스가 기반이 되어 여러 추가적인 서비스를 제공하기 때문에 이미 준비된 수많은 EC2 Instance를 활용하는 것이 AWS 자원 관점에선 더 효율적이기 때문입니다.

kubernetes와는 다른 ELB Network 구조

앞의 개념글에서 보면 service에 해당하는 부분이 docker-compose입니다. docker-compose는 docker-network를 통해 컨테이너간 통신을 효율적으로 했고 kubernetes에도 이와 같이 구현되어 있습니다. 이런 방식을 'overly network'라 합니다.
하지만 ECS는 그렇지 않습니다.

ECS 컨테이너간에 논리적으로 묶였지만 그 뿐입니다. 쉽게 말해 묶어주기만 했을 뿐 그 상태로는 컨테이너끼리 통신은 이뤄지지 않습니다. 그래서 이후 ECS 배포에선 컨테이너간 통신이 다시 localhost로 통신하게 되고 이대로면 당연히 비효율적인 통신을 하게됩니다.

하지만 AWS는 이런 문제는 자신들의 서비스 중 하나인 ELB(Elastic Load Balencer)를 통해 해결합니다.
ELB는 TCP계층 ELB가 있고 Application ELB가 있습니다. 컨테이너는 프로세스이니 Application ELB를 통해 컨테이너를 해결합니다.
Service당 Application ELB를 할당하여 ELB를 통해Task 통신을 할 수 있게 됩니다.

EC2인스턴스가 여러 개일 경우, service에 속한 task들이 서로 다른 EC2에 있다면 통신이 여전히 어렵다는 한계가 있습니다.
주로 여러 인스턴스를 통해 동일한 service를 여러 개 배포할 때 생기는 문제입니다.

하나의 호스트에는 하나의 Task만 수용 가능하다.

ECS는 EC2기반(host)이기 때문에 결국 특정 port를 할당하는 구조에선 한계가 있습니다.
Task에서 사용하는 port가 정해져 있으므로 만약 동일한 2개의 Task를 할당하고 싶다면 2개의 EC2 Instance가 필요하다는 뜻이 됩니다.

어느정도 단점을 상쇄하는 방법으로는 한 인스턴스에 여러 Task를 올려서 집적도를 높이는 방법이 있습니다.

ECS 특성에 맞는 설계 필요

앞서 특징들을 보면 알 수 있는것이 AWS 서비스에 맞게 구조화되어 있습니다. 그렇기 때문에 ECS만의 구조가 가지는 특징이 생겼고, Application 설계를 할 때 이런 구조를 생각하며 설계해야 합니다.

Task definition에 단일 속성의 컨테이너만 정의하기

이 부분은 AWS의 설계 원칙을 생각하면 됩니다.
AWS는 기본적으로 수평확장에 유리한 설계를 지향합니다. 따라서 Task를 계속 확장하더라도 문제가 없도록 설계해야 합니다.

만약 Task에 웹,WAS,DB 컨테이너를 묶어서 배포한다면 Task를 늘릴때마다 전부 늘어나게 되는 것입니다(특히 DB).

즉, 각 역할에 맞게 Task를 분리하여 스트레스가 많이 일어나는 Task를 늘릴 수 있는 형태로 설계해야 합니다.
DB는 RDS, MongoDB등의 데이터베이스 서비스를 활용하고 가벼운 웹 보다는 WAS에 컨테이너가 많을 것을 예상해 WAS컨테이너를 분리하는 방식 등을 고려하면 좋습니다.

VPC를 이용한 Container Instance 구분

퍼블릭, 프라이빗 서브넷을 구성하여 보안이 필요한 인스턴스를 프라이빗 서브넷에 할당하는 방식으로 구성합니다.