AWS - ECS EC2 유형의 네트워크 모드 및 비용

클러스터 인프라를 서버리스로 AWS에 일임하는 것이 아니라, 사용자가 직접 EC2 인스턴스로 구성해서 컨테이너 오케스트레이션 서비스만 ECS를 사용한 방식도 가능하다. 장단점은 명확하게 사용자가 직접 클러스터 내용과 EC2 오토스케일링을 구성해야하지만, 비용을 효율적으로 관리할 수 있다.

 

EC2 시작 유형의 ECS 개요

---

ECS Fargate는 AWS가 자체적으로 인프라 클러스터를 담당하기에, 사용자가 신경써야 할 부분은 컨테이너에 관한 configuration이다. 반면 EC2 시작 유형의 ECS는 컨테이너가 배포될 인프라 클러스터를 EC2 인스턴스로 사용자가 관리해야한다. ECS 서비스가 태스크를 실행하면, 실행되는 태스크 컨테이너를 실제로 올릴 컴퓨터인 EC2 인스턴스 풀을 관리한다는 의미이다.

Fargate를 사용할 땐 컨테이너 configuration인 태스크 정의가 주요 관리 포인트이고, EC2 시작 유형 ECS의 주요 관리 포인트는 ECS 서비스 내의 컨테이너들의 네트워크 유형을 포함한 태스크 정의와 인프라 구성을 위한 클러스터이다.

 

ECS의 구성 요소 등은 Fargate 포스팅에서 다루었으니, 주요 차이점인 네트워크 유형과 클러스터 구성에 대해서 다뤄보고자 한다.

AWS - Elastic Container Service(ECS) 구성과 Fargate

 

ECS 작업 네트워크 유형

---

ECS Fargate는 기본적으로 `awsvpc`모드의 네트워크 유형만 활성화되어 크게 신경쓰지 않아도 되는 부분이지만, EC2 시작 유형의 ECS는 인스턴스 관리를 직접 해야하기 때문에 네트워크 모드를 선택할 수 있다. Linux 컨테이너 기반으로 선택할 수 있는 네트워크 모드는 `awsvpc`, `host`, `bridge`, 그리고 `none`이 있다.

 

awsvpc

`awsvpc`모드는 컨테이너에 네트워크 인터페이스인 ENI를 부착한다.

태스크 컨테이너 하나하나에 ENI가 부착된다. `awsvpc`모드의 장점은, 다른 AWS 서비스와의 연동이다. ENI를 통해 AWS 네트워크 상에선 태스크 컨테이너 식별이 가능해 모니터링 등의 서비스와 쉽게 연동을 할 수 있고, 관리 포인트가 AWS로 어느 정도는 넘어가게 된다. 이와 같은 이유로 Fargate 유형의 ECS는 `awsvpc`모드만이 가능하다.

 

일반적으로 우리가 생각하는 docker를 사용한 포트 포워딩이 아니기 때문에, EC2 시작 유형의 ECS에서 `awsvpc`를 사용하면 제약이 상당하다. `awsvpc`모드에선 ENI를 자동으로 생성해 부착하기 때문에, 사용자가 직접 수정하거나 삭제할 수 없다. 이는 태스크 컨테이너에 연결된 ENI를 우발적으로 삭제하는 것을 막기 위함이다. 가장 큰 단점은, EC2 인스턴스마다 가질 수 있는 ENI 제한이 있다. EC2 인스턴스는 기본적으로 ENI를 하나 부여받고, 그 인스턴스에 태스크 컨테이너의 ENI가 추가된다. `t3.medium`을 포함한 많은 인스턴스 유형은 최대 3개의 ENI를 가질 수 있다. 즉, 인스턴스의 ENI와 별도로 2개의 태스크 컨테이너만이 인스턴스 상에 존재할 수 있는 한계가 있다.

 

`awsvpc`모드의 태스크 컨테이너는 인터넷과 직접적인 연결을 할 수가 없다. 부착되는 ENI에 Public IP가 할당되어야 하는데, 이는 수동 설정인 반면 `awsvpc`모드의 태스크 컨테이너에 붙는 ENI는 자동으로 Private IP만을 할당받아 붙기 때문에 외부에서 직접적인 연결이 불가능하다.

그렇기 때문에 ALB나 NLB를 앞에 부착해 IP 기반의 타겟 그룹을 형성해 라우팅을 해야한다.

ENI는 네트워크 인터페이스로써 Private IP를 할당 받을 수 있지만, 인스턴스가 아니기 때문에 타겟 그룹은 `instance`가 아닌 반드시 `ip`가 대상 유형이 되어야한다.

 

Fargate 유형에선 `assignPublicIp`를 설정할 수 있기 때문에 퍼블릭 접근도 가능하긴 하다.

 

host

`host`모드는 간단하게 컨테이너의 포트와 인스턴스의 포트를 그대로 매핑하는 네트워크 모드다.

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-host.html

포트 포워딩이 그대로 되기 때문에 간단하지만, 큰 단점이 존재한다. 같은 태스크 정의로 만들어진 태스크 컨테이너를 하나만 인스턴스 위에 띄울 수 있다. 같은 포트에 여러 컨테이너가 매핑될 수 없기 때문이다. 즉, 한 인스턴스 상에서 태스크의 스케일 아웃이 불가능하고, 태스크 컨테이너의 스케일 아웃을 하기 위해선 물리적인 인스턴스를 늘려서 1:1로 매핑을 해야한다. 컨테이너와 호스트가 같은 포트를 사용하는 것이라고 여길 수 있기 때문에, 컨테이너가 호스트인 척 루프백(localhost)를 통해 인스턴스의 다른 자원에도 접근 할 수도 있기 때문에 보안 상 문제도 있을 수 있다고 한다.

 

bridge

`bridge`모드는 docker 네트워크를 따른다. 우리가 흔히 docker나 docker compose 등을 사용해 포트 매핑을 하는 것처럼, 가상의 네트워크 브릿지를 만든다.

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-bridge.html

포트 매핑은 `host`모드처럼 정적으로 호스트의 특정한 포트와 컨테이너의 특정한 포트를 지정할 수 있다. 이를 정적 포트 매핑이라고 하고, 정적 포트 매핑을 사용하면 사실상 `host`모드를 사용하는 것과 다르지 않다.

 

`bridge`모드에선 동적 포트 매핑을 지원한다.

동적 포트 매핑을 사용하면 컨테이너 포트만 지정하고 호스트 포트는 가능한 포트에서 무작위로 지정된다. 그러면 태스크 컨테이너가 교체되거나, 혹은 같은 태스크 정의로 만들어진 태스크 컨테이너가 한 인스턴스 상에 존재할 수 있게 된다.

 

이러한 포트 매핑은 태스크 정의에서 설정할 수 있다. 호스트 포트를 특정 포트로 지정하면 정적 매핑, 0으로 지정하면 동적 매핑을 사용한다.

"containerDefinitions": [
  {
    ...
    "portMappings": [
      {
        ...
        "containerPort": 8080,
        "hostPort": 0, # 0일 시 동적, 8080 등 특정 포트 지정 시 정적 매핑
        ...
      }
      ...
  }
]

 

동적 포트 매핑을 사용하면 호스트 포트가 랜덤하게 지정되기 때문에 외부에서 고정적인 포트를 알 수가 없기 때문에 접근하기 불편하다. 그래서 일반적으로 ALB나 NLB와 같이 구성해야한다. ALB나 NLB의 타겟 그룹의 대상을 `instance`로 설정하고 ECS로 대상의 인스턴스로 대상을 등록하면 ECS가 새 태스크 컨테이너 생성 시 사용되는 랜덤 호스트 포트를 타겟으로 등록하면서 외부에서 호스트 포트를 알지 못하더라도 접근할 수 있다.

https://viblo.asia/p/aws-certified-solutions-architect-professional-compute-containers-services-on-aws-5OXLAXxZJGr

이를 매끄럽게 설정하기 위해선 순서가 중요하다. 타겟 그룹을 먼저 생성하게 되면 실제로 타겟을 등록해야하고, 이후에 ECS가 자동으로 타겟을 등록하게 끔 연동하는 것이 어렵다.

ECS 클러스터와 서비스를 구성하면서 자연스럽게 타겟 그룹을 만드는 것이 가장 확실하면서 자연스러운 방법이고, ECS 서비스를 먼저 생성했다고 하더라도 수정을 하면서 타겟 그룹을 만드는 것이 타겟 그룹을 먼저 만드는 것보다 더 나은 방법이다.

 

EC2 시작 유형과 Fargate 유형의 가장 큰 차이 중 하나인 클러스터 구성을 위한 ASG와 Capacity Provider가 있지만, 이는 다음 포스팅에서 다루고자 한다. 이번 포스팅에선 비용 차이를 살펴보며 마무리하겠다.

 

ECS Fargate와의 비용 차이

---

Fargate 유형은 AWS의 컨테이너 오케스트레이션 서비스 중 사용자가 클러스터 인프라를 관리하지 않아도 되는 서버리스 서비스이다. 서버리스의 단점은 비용이다. OS나 vCPU, 메모리 같은 세부적인 스펙 등 관리 포인트가 굉장히 줄지만 온디맨드 옵션에 비해서 높은 비용이 부과된다. 그래도 vCPU 수와 메모리 GB를 기준으로 pricing되니 비용 예상하는 것이 어렵진 않다.

 

ap-northeast-2 서울 region에서 2 vCPU, 4GB 메모리의 컨테이너를 Fargate 서비스로 애플리케이션을 운영한다면 30일 동안 서버 비용은 아래와 같다.

2 vCPU: 2 * 0.04656 * 24 * 30 = 67.0464 USD
4GB Memory: 4 * 0.00511 * 24 * 30 = 14.7168 USD
10GB Volume: 0 USD (20GB의 임시 스토리지 사용)

총 월 81.7632 USD

 

같은 2 vCPU, 4GB 메모리 스펙의 t3.small EC2 인스턴스를 사용했을 시의 비용은 Fargate에 비해 상당히 낮아진다.

t3.medium: 0.052 * 24 * 30 = 37.43 USD
10GB EBS Volume: 0.0912 * 10 = 0.912 USD

총 월 38.342 USD

 

2배가 넘게 차이가 난다. 하지만 t 패밀리 인스턴스는 버스트 모드로 CPU 크레딧이라는 특정한 과금 방식이 존재한다.

만약 서비스가 적당히 잘 돼서 월 50% CPU 사용량을 평균적으로 사용한다고 가정해본다면, 추가 비용이 아래와 같이 발생한다.

2 * 0.3 * 60 * 24 * 30 / 60 * 0.05= 21.6 USD

총 월 38.342 + 21.6 = 59.942 USD

 

50%의 CPU 사용량이 지속된다고 해도, 월 20 USD 이상의 차이가 발생한다.

 

ASG, Capacity Provider, 네트워크 모드, 모니터링 구성 등 관리 포인트가 많아지지만 애플리케이션 배포를 위한 비용을 고려한다면 Fargate는 항상 옳은 선택은 아니다. 그래도 편리하게 컨테이너 오케스트레이션을 경험할 수 있으니 많이 활용될만한 서비스임은 확실하다.