Elastic Container Service - 기본 개념

이번 글에서는 AWS에서 제공하는 대표적인 컨테이너 서비스 중 하나인 ECS의 기본 개념을 살펴보도록 합니다. ECS는 쿠버네티스 기반의 완전 관리형 컨테이너 오케스트레이션인 AWS EKS(Elastic Kubernetes Service), 그리고 옆동네 GCP의 GKE(Google Kubernetes Engine)와 비교할 수 있는데요, 여기서는 ECS에 초점을 맞춰서 설명합니다.

---

 

ECS는 완전 관리형 컨테이너 오케스트레이션 서비스 입니다. 컨테이너와 오케스트레이션을 이해하기 위해 기존 서비스 방식을 살펴보면 다음과 같습니다.

• 애플리케이션을 인스턴스에 직접 설치해서 운영
  • 진입 장벽이 낮아서 빠르게 애플리케이션을 개발&검증하는데 유리합니다
  • 한편, 컴퓨팅 리소스의 수평확장(scale-out)을 위해 애플리케이션이 설치된 인스턴스를 AMI로 생성해서 사용합니다. 때로는 Gold Image라고 불리기도 합니다
  • 단점으로는 AMI 생성에 드는 여러가지 비용입니다
    • 운영 중인 인스턴스를 AMI로 생성하는 방식 자체를 AWS가 권고하지 않습니다
    • 패치를 위해 outService 시킨 인스턴스에서 작업을 하게 됩니다
    • AMI가 노후화돼도 신경 쓰지 않게 됩니다
      • 인스턴스를 inService 할 때 preprocess 스크립트에 git pull 넣어서 사용을 하기도…
• 애플리케이션을 컨테이너로 운영
  • 컨테이너 환경으로 구동되기 때문에 AMI가 그다지 필요 없습니다
  • 호스트 OS가 무엇이든 상관없이 애플리케이션을 배포할 수 있습니다
  • 다만, 커널 파라미터 튜닝을 위해 어쩔 수 없이 AMI 환경을 끌어다 써야 할 수도 있습니다
    • 서비스의 특성에 따라 대용량 트래픽 처리를 위한 TCP 파라미터 튜닝 등

이렇게 운영을 하던 방식에는 몇 가지 문제가 있는데 바로 유연한 scale-out의 어려움입니다. 예를 들어, 1분 동안 CPU의 평균 사용량이 60% 이상이면 인스턴스 한 대를 inService 시킨다는 정책이 있다고 가정했을 때 인스턴스가 구동되는데 필요한 시간을 무시할 수 없게 됩니다. 부팅이 완료되는데 30초가 걸리는데 30초 사이에 CPU 사용량이 어떻게 급증했을지 알 수 없으니까요. 또한 애플리케이션에 Crash, Hang 등의 문제가 생겼을 때 이를 복구하기 위한 복잡한 과정이 필요합니다. 배포도 마찬가지입니다. 현대에 들어서는 여러 가지 배포 방법론이 있지만 꽤 복잡하고 빠른 대응이 어렵습니다. 혹은 상당한 비용을 감수해야 한다던지요.

아무튼, 서론이 길었는데 컨테이너 오케스트레이션으로 넘어오면서 이런 문제들의 많은 부분이 해소되었습니다. 컨테이너 오케스트레이션의 기본 컨셉은 인스턴스 한 대에 여러 개의 컨테이너를 구동시키면서 시작합니다. 컨테이너의 묶음을 ECS에서는 task라고 부릅니다. 쿠버네티스로 비유하자면 pod와 같은 개념이죠. 한편, task를 클러스터 환경 위에서 돌리는 단위를 service라고 합니다. 쿠버네티스의 namespace와 같습니다.

task 단위는 보통 컨테이너끼리 통신을 통해 긴밀하게 협업해야 하거나 같은 네트워크 안에 존재해야 하는 애플리케이션을 구동할 때 사용하게 됩니다. 예를 들면 RestAPI를 처리하는 애플리케이션과 해당 애플리케이션에서 발생하는 stdout 로그를 처리하는 fluentd 컨테이너를 묶어둘 수 있겠습니다. 한편, task가 꼭 여러 개의 컨테이너를 운영해야 하는 것은 아닙니다. 서비스도 마찬가지로 몇 개의 task definition을 운영하든 상관 없습니다. 다만, 클러스터 내에 효율적인 퍼포먼스를 위한 조절은 필요할 겁니다. 리소스를 적절하게 사용하지 못하고 유휴 상태로 있는 인스턴스가 최소로 운영되는 게 좋겠죠. 그래서 컨테이너 인스턴스(인스턴스가 클러스터에 inService 되면 컨테이너 인스턴스라고 부릅니다)는 몇 대가 적정 수준인지, 우리 서비스가 트래픽이 급변하는지, 평이한지 등을 따져서 인스턴스 타입은 무엇이 좋을지 생각해봐야 합니다. 그리고 task의 cpu unit, memory는 어떻게 운영하는 게 좋을지, 클러스터 내에서 몇 개의 task가 운영되는 게 좋을지 등 효율적인 운영을 위해서는 고민해야 할 게 많습니다.

ECS 구성을 들여다봅니다

검은 바탕은 EC2, C로 표시된 부분이 컨테이너입니다. N개의 컨테이너가 묶여서 task가 되는데 빨간색 점선이 task를 나타냅니다. 인스턴스 4대를 논리적인 영역으로 묶어서 Service를 제공합니다. 그게 노란색 점선 영역입니다.

AWS icon이 익숙하신 분들에게는 아래 이미지가 더 도움이 되실 겁니다. 클러스터 안에서 다양한 서비스를 구동시키고 있는 형상입니다. 어떤 서비스는 무수히 많은 Container를 실행하고 있고, 한편 어떤 서비스는 1~4개의 서비스를 실행하고 있죠. 서비스의 특성에 따라 각기 다른 환경과 동작을 취합니다.

ECS Cluster

효율을 고려할 때 빼 놓을 수 없는 게 바로 Fargate입니다. 클러스터에 인스턴스를 자동 확장을 통해 최소한으로 운영되도록 했어도 서비스의 종류에 따라 비효율적으로 인스턴스 비용이 빠져나가고 있을 수 있습니다. 인스턴스가 항시 떠 있어서 대기할 필요가 없는 경우가 있을 수 있죠. 이럴 때 필요한 게 서버리스입니다. 람다로 작업하기에는 부담스러운 일도 ECS에 Fargate를 활용하면 효율적으로 활용할 수 있습니다.

다음 글에서 ECS를 본격적으로 살펴보도록 하겠습니다.