Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

Contents

ECS

AWS에서 제공하는 컨테이너 서비스다. 2015년 8월(대충 이쯤이다.) 부터 도쿄 리젼에서도 사용 할 수 있다

특징

구성상의 특징

EC2 인스턴스 위에 컨테이너를 실행하는 구조다. VM에 사용한 네트워크, 시스템 기술들을 컨테이너에 그대로 사용 할 수 있으니, 인스턴스 위에 컨테이너를 올리는 것은 비효율적인 구성인 것 같다. 이런 구성을 선택한 이유를 생각해 보면
  1. 자원 격리 : VM의 경우 CPU와 메모리와 같은 컴퓨팅 자원들에 대한 높은 수준의 격리를 제공하는 반면, 컨테이너의 자원격리는 만족스럽지 않다. 호스트 운영체제 위에서 바로 컨테이너를 올려버릴 경우 자원 격리가 어려워 질 수 있다.
  2. 네트워크 구성의 어려움 : 컨테이너는 애플리케이션에 가깝다. IP를 직접 할당하는 것보다는 포트(Port)로 서비스하는게 효율적이다. 결국 포트포워딩을 사용하게 될 건데, 호스트 운영체제위에 컨테이너를 올릴 경우 높은 확률로 포트가 충돌한다.
이러 저러한 이유로 그냥 인스턴스위에 포트포워딩으로 서비스 하기로 결정한 것으로 보인다. 인스턴스를 중심으로 하는 네트워크도 잘 갖춰져 있으니 현재로서는 합리적인 방식 인듯.

주요 키워드

컨테이너와 태스크, 클러스터로 구성된다.
  • EC2 Container Instance : 컨테이너를 띄우기 위한 EC2 인스턴스. 일반 AMI를 이용하지 않는 걸롸 봐서, 튜닝한 녀석인 것 같다.
  • 컨테이너 : 기본 구성단위
  • 태스크(Task) : 하나 이상의 컨테이너로 구성된다. 애플리케이션이라고 볼 수 있다.
  • 서비스(Service) : 태스크가 모여서 서비스가 된다. 서비스들은 ELB로 로드밸런싱된다.
  • 클러스터 : 인스턴스들의 그룹이다. AWS는 클러스터에 묶인 인스턴스들의 자원의 모니터링 하고, 적절한 인스턴스에 태스크들을 배치한다.

서비스 네트워크 구성

컨테이너 인스턴스에는 여러 개의 태스크들이 배치될 수 있지만, 일반적으로 같은 종류의 태스크를 배치하지는 않는다. 서비스를 구성하는 태스크들은 ELB로 묶인다. 80번포트를 8080으로 연결하도록 설정했다면, 모든 태스크들은 8080포트를 가져야하기 때문에, 하나의 컨테이너 인스턴스에 같은 태스크가 있으면 안된다. 서비스 네트워크는 다음과 같다.

도입 여부

컨테이너 기반으로 서비스를 하고 싶다면, ECS를 사용하자. 클러스터 관리를 하느라고 삽질 할 필요가 없다. 하지만 인스턴스를 관리하던 기존의 방식에서 컨테이너 방식으로 옮길만한 이유가 있는지에 대한 고민이 필요하다.

컨테이너의 장점 중 하나인 빠른 실행은 실제 서비스 상에서는 결정적인 장점은 아니다. 결정적이라는 수식을 붙인 이유는 장점이기는 하지만, 현재 운영중인 인스턴스를 도커 기반으로 이전 할 만한 유인은 없다고 보기 때문이다. 하지만 수백, 수천대의 인스턴스를 운용하고 있다면, ECS로의 이전을 심각하게 고려해 볼 만 하다. 이 정도의 인스턴스를 운용하고 있다면, 자동화된 애플리케이션 배포 시스템을 가지고 있을 거다. 하지만 컨테이너 배포의 단순함과 빠름에 비할 수는 없다.

남은 잇점은 자원의 효율적인 사용 인데, 결국 클러스터를 얼마나 잘 관리 할 수 있느냐가 관건이다. 클러스터를 구성하는 인스턴스들의 자원을 모니터링 해서, 태스크를 적재적소에 배치 할 수 있어야 한다. ECS는 클러스터 관리를 위한 API들을 제공하고 있다. 인스턴스의 수가 늘어날 수록 많은 비용을 절약 할 수 있을 거다.

결론, ECS의 도입을 고려하고 있다.