Docker(7) - 도커를 활용하는 클라우드 서비스 + ECS란?

이제 도커를 잘 쓰고 활용할 수 있게 되었다.

그런데, 개발자가 해야 하는 일 중 도커 컨테이너를 관리하는 것은 극히 일부분일 뿐이다.

만약에, 컨테이너를 돌릴 때 컨테이너에 깔려있는 특정 어플리케이션의 버전이 바뀌었다거나, 컨테이너에 트래픽이 몰린다거나, 버그가 발생한다면

개발자가 일일히 컨테이너를 돌면서 버전을 조사하고, 로드 밸런싱을 하고, 컨테이너를 증설하고, 버그 때문에 컨테이너를 내렸다가 올리기에는 너무나 많은 인적 소모가 있다.

 

그래서 나온 것이 '컨테이너 오케스트레이션 툴'이다.

오케스트레이션이란 그 말 뜻 그대로 여러 개의 컴퓨터 시스템, 앱, 서비스 등을 조율하고 관리하는 것으로, 여러개의 작업을 함께 연결하여 방대한 work-flow나 프로세스를 실행한다.

이름을 보고 '오케스트라'가 떠올랐다면, '여러 가지 악기를 조율해서 공연을 만들어 가는' 그 느낌 그대로 이해하면 된다.

 

컨테이너 오케스트레이션 툴과 제공하는 업체를 크게 살펴보자면,

• GCP(Google Cloud Flatform)에서 제공하는
  • GKE(Google Kubernetes Engine)
• AWS(Amazon Web Service)에서 제공하는
  • EKS(Elastic Kubernetes Service)
  • ECS(Elastic Container Service)

등이 있다.

 

우리가 컨테이너를 제어하고, 만들어내기 위해 여태껏 이미지도 만들고, 레지스트리에 등록도 하고 해 보았는데,

이것을 프로덕션 환경에서 컨테이너들을 구성해서 실제 서비스를 할 때,

'컨테이너를 제어하는데 필요한 여러가지 요소들'을 컨테이너 오케스트레이션이라고 한다.

그럼, 컨테이너 오케스트레이션은 무슨 일을 할까?

• 컨테이너 클러스터링(Clustering)
  • 여러 대의 노드(node)를 하나의 클러스터(cluster)로 묶어서, 어플리케이션을 분산하고 실행하고, 자원을 효율적으로 이용하는 기능
  • 여러 대의 물리적이거나 가상의 서버를 하나의 시스템처럼 동작하게 만드는 기술
  • 컨테이너를 실행하는 호스트의 자원을 효율적으로 분배, 컨테이너가 안정적으로 실행 되도록 함.
  • 여러 대의 컨테이너를 묶어 하나의 서버처럼 사용 할 수 있도록 지원
• 서비스 디스커버리(Service Discovery)
  • 컨테이너를 '자동으로 발견'하고, 서비스 이름과 IP 주소 등을 관리하여, 애플리케이션 간의 연결을 관리하는 기능
  • 클라우드 환경에서의 컨테이너 생성, 배치, 이동에 따른 IP, Port 정보 업데이트 및 관리
  • 결국 컨테이너를 알아서 찾은 다음, 그 컨테이너에 관련된 잡다한 관리들을 전부 다 해준다.
• 자동 스케일링(Autoscaling) - 중요
  • 애플리케이션의 트래픽 양에 따라 자동으로 컨테이너 수를 조절하여, 자원 사용량을 최적화하고, 가용성을 보장하는 기능
  • 트래픽을 감당할수 있도록 계속 제어해줌. 컨테이너를 띄우기도 하고 죽이기도 하면서 수 조절
• 로드 밸런싱(Load Balancing)
  • 여러 대의 노드에서 실행 중인 컨테이너들을 조절하여, 트래픽을 균등하게 분배하여, 애플리케이션의 성능을 최적화하는 기능
• 롤아웃과 롤백(Rollout and Rollback)
  • 새로운 버전의 애플리케이션을 롤아웃하고, 이전 버전으로 롤백하는 기능
  • 컨테이너에 버그가 있거나, 컨테이너가 장애가 나서 죽었을때 빠르게 복구해준다.
• 자동 복구(Automatic Recovery)
  • 컨테이너나 노드의 장애 시 자동으로 복구하는 기능
• 모니터링과 로깅(Monitoring and Logging)
  • 컨테이너나 노드의 상태를 모니터링하고, 로그를 수집하여, 애플리케이션의 성능과 문제점을 분석하는 기능
• 보안과 네트워크 관리(Security and Network Management)
  • 컨테이너와 노드의 보안을 관리하고, 네트워크 설정을 관리하는 기능

이것들을 비롯한 '관리'와 관련된 많은 일을 하는 것이 컨테이너 오케스트레이션이다.

 

그럼, 대표적인 컨테이너 오케스트레이션 툴에는 뭐가 있을까?

1. Docker swarm

• Docker Inc.이 개발한 도커 컨테이너 오케스트레이션 도구
• Docker Swarm은 2015년 Docker 1.12 버전에서 처음 발표됨
• 이전에는 Docker Swarm Classic이라는 이름으로, Swarm 모드가 추가되기 전에 도커 엔진에 통합되기 전에 독립적으로 배포
• Docker Swarm은 쿠버네티스가 등장하기 전까지 가장 대중적인 컨테이너 오케스트레이션 도구 중 하나
• 간단하게 작동하고, 설정이 쉬움

2. Kubernetes

• 배경
  • 구글은 Gmail, Youtube, 검색 등 다양한 웹 서비스가 있고, 이 서비스에 대한 대용량 트래픽을 감당하기 위해 쿠버네티스를 만들었고, 실제 서비스에 적용함
  • 기존 서비스를 유지하며 계속 업데이트를 통해서 고도화할 수 있음.
• 오픈 소스 기반, 구글에서 설계, 현재 리눅스 재단에 의해 관리.
• 쿠버네티스 v1.0은 2015년 7월 21일에 출시됨
• 대규모에 적합함
  • 스케일링 기능 강화 (Replication Controller: 컨테이너 수를 동적으로 조절)
  • 서비스 디스커버리 기능 강화 (DNS 기반)
• 가장 기능이 풍부하고 널리 사용되는 컨테이너 오케스트레이션 프레임워크
• 베어 메탈, VM환경, 퍼블릿 클라우드 등의 다양한 환경에서 작동하도록 설계되어 있음.
• https://kubernetes.io/ko/docs/home/

 

3. GKE(Google Kubernetes Engine)

• Google Cloud Platform(GCP)에서 제공하는 Kubernetes 기반의 관리형 컨테이너 오케스트레이션 서비스
• 따라서 GKE는 Kubernetes를 기반으로 하고, Kubernetes의 기능을 모두 제공

4. EKS (Amazon Elastic Kubernetes Service)

• AWS 제공하는 관리형 Kubernetes 서비스
• EKS는 Kubernetes 기반으로 구축되어 있음
• 사용자는 Kubernetes API를 사용하여 EKS 클러스터를 관리할 수 있다.

5. ECS (Amazon Elastic Container Service)

• AWS에서 제공하는 관리형 컨테이너 오케스트레이션 서비스
• Docker 컨테이너를 실행하기 위한 기능을 제공
• 사용자는 ECS를 사용하여 컨테이너를 배포, 관리, 스케일링
• 쿠버네티스의 복잡한 기능/세팅을 간소화하여 개발자들이 인프라에 대한 신경을 덜게끔 함
• https://docs.aws.amazon.com/ko_kr/ecs/index.html

등, 정말 많은 오케스트레이션 툴이 있다.

다음 글에서는 쿠버네티스를, 이번 글에서는 ECS에 대해 다룰 예정이다.

 

ECS(Amazon Elastic Container Service)

AWS ECS에는 세 가지 계층이 있다.

• 용량 : 컨테이너가 실행되는 인프라(컴퓨팅 자원)
• 컨트롤러 : 컨테이너에서 실행되는 app을 배포하고 관리함
• 프로비저닝 : 스케줄러와 인터페이스하여 애플리케이션과 컨테이너를 배포하고 관리하는데 사용하는 도구

이 컨트롤러를 통해 Capacity options(=컴퓨팅 자원)을 가지고, 이 자원 위에 어플리케이션들을 올린다.

이 Capacity options를 이용하는 방법이 3가지가 있는데,

1. EC2 instance를 이용하는 방법
2. Fargate방식을 이용하는 방법( = EC2를 조금 더 추상화 하였으며, EC2 관리도 귀찮다, 싫다 할때 사용)
3. 온프레미스(외부) 컴퓨팅 자원을 이용하는 방법(효율적이지 않음)

조금 더 자세하게 살펴보자.

Task가 무엇인지는 조금 있다가 알아보도록 하자.

EC2방식?

초기 컴퓨팅 자원을 EC2 인스턴스에 할당한 뒤, Task에 필요한만큼을 할당한다.

용량공급자(Capacity Providers)를 통해 EC2 Auto-Scaling Group을 연결하고,

위의 그림을 보면 Auto-Scaling Group이 EC2 인스턴스에 vCPU 4개를 인스턴스에 할당한 뒤, 2개만 Task에 할당하는 구조이다. 그래서 실제로 도커 컨테이너가 실행되는 곳은 EC2 Instance 내부이다.

또한, ECS에서 제공하는 관리형 지표인 "Capacity Provider Reservation"에 따라 임의로 EC2 용량을 추가/제거 할 수 있으며, 컨테이너 개수의 증가/감소에 따라 EC2도 함께 증가/감소하게 된다.

- 과금 : 호스트로 사용하는 EC2 요금만 부과된다.

Fargate방식?

공식 문서에 따르면,

'AWS Fargate Fargate는 Amazon EC2 인스턴스의 서버나 클러스터를 관리할 필요 없이 컨테이너를 실행하기 위해 Amazon ECS에 사용할 수 있는 기술입니다. Fargate를 사용하면 더 이상 컨테이너를 실행하기 위해 가상 머신의 클러스터를 프로비저닝, 구성 또는 조정할 필요가 없습니다. 따라서 서버 유형을 선택하거나, 클러스터를 조정할 시점을 결정하거나, 클러스터 패킹을 최적화할 필요가 없습니다.' 

라고 적혀있다.

서버리스란?
EC2 인스턴스등 호스트 컴퓨팅을 사용하지 않고 컴퓨팅 자원을 제공해주는 서비스

결국, 이용자는 컨테이너가 어디서 운영되는지 관리할 필요가 없다. 그저 ECS에서 알아서 컴퓨팅 자원을 Task에 배분해준다. 사진을 보면 EC2 인스턴스를 사용하지 않고도 알아서 Task에 vCPU 2대가 할당되어있는 것을 볼 수 있다. 

Fargate 방식은 효율적으로 자원을 분배하기 위해 EC2 인스턴스조차도 추상화해놓았기 때문에,

극단적인 예를 들면 1/2vCPU, 1/4vCPU를 Task에 분배하는 것조차 가능하다.

- 과금 : 시간당 vCPU, Storage 용량 비용이 부과된다.

 

개인적으로는 이렇게 이해했다. 물론 완벽한 비유는 아니다.

- 스프링(리액트)의 오만 떼만 설정방식때문에 세팅하는데에 시간이 너무 길어지고, 그 시간을 조금 더 개발 시간에 투자하기 위해 스프링 부트(create-react-app / start.spring.io)가 등장했듯, 쿠버네티스의 초기 세팅이나 튜닝, 또 컨테이너 관리에 걸리는 시간을 조금 더 단축하고 ECS의 fargate 방식이 등장했다.

- 물론, 상세한 튜닝이나 설정이 필요한 경우 스프링 부트 대신 스프링을 사용해야 하듯, ECS보다 EKS를 사용한다.

External방식?

AWS 컴퓨팅 자원을 이용하지 않고, 외부 리소스를 컨테이너에 할당하는 유형이나 많이 이용되지는 않는다.

호스트나 컨테이너 등의 실제 서비스는 물리적으로 AWS 밖에서 동작하며, 이것을 모니터링하거나 관리할 때에는 AWS 콘솔을 이용한다.

그럼 효율적인 자원 관리를 해주는 Fargate 방식이 EC2보다 더 비싸겠네요?

꼭 그런건 아니다. 상황에 따라 다르다.

EC2방식은 컨테이너를 띄우기 위해서는 EC2 인스턴스가 계속 켜져 있어야 한다. 그래서 계속 비용이 발생하고, Fargate방식은 효율적 자원 분배를 할 수 있게 해주기 때문에 트래픽이 적을 때에는 Fargate방식이 오히려 저렴하고, 트래픽이 많을 때에도 상황에 따라 Fargate방식이 더 저렴한 경우도 있다.

 

ECS 구성

이제 실제적으로 ECS가 어떻게 구성되어있는지를 살펴보자.

AWS Cloud라는 가상 공간 안에 VPC를 만들고, VPC 안에 ECS 클러스터가 존재한다.

1. Task Definition

Task definition이란 컨테이너를 설명하는 json파일로, 다음의 정보를 포함한다.

• 컨테이너 이미지: 어떤 이미지를 기반으로 컨테이너를 만들 것인지
• 컨테이너 vCPU / Memory 자원 할당
• 포트 구성
• 컨테이너 환경변수
• 컨테이너 로그
• 이 외에 도커 컨테이너를 정의하는 모든 설정 파일

어떻게 보면 docker-compose와 닮았고, 실제로 Task definition은 docker-compose를 지원한다.

2. Task

쿠버네티스 클러스터 안의 'pod'와 유사한 개념이다. ECS에서 배포할 수 있는 가장 작은 단위로, 도커 컨테이너의 작업 단위이다.

3. Service

쿠버네티스 클러스터 안의 'node'와 유사한 개념이다.

특정 작업 정의에 기반한 작업 집합을 실행하고 유지,관리하는 역할

• 특정 작업의 인스턴스를 지정된 수로 유지하거나, 부하 분산, 서비스 발견, 롤링 업데이트 등과 같은 추가 기능을 제공
• Task를 몇개나 유지할 것인지 등을 Service로 묶어서 관리함

주요 기능 및 목적

• Desired Count
  • 사용자가 지정한 수의 작업 인스턴스를 지속적으로 실행하도록 보장
  • 만약 작업 인스턴스가 실패하거나 중지되면 ECS는 자동으로 새 작업을 시작하여 원하는 수의 작업 을 유지
• Load Balancing
  • Application Load Balancer, Network Load Balancer 또는 Classic Load Balancer와 통합 될 수 있음
  • 트래픽이 ECS 작업에 균일하게 분산될 수 있도록 함
• Service Discovery
  • 동적 IP 주소(EIP)를 사용하여 서비스를 검색하고 연결
• Rolling Updates
  • 애플리케이션 업데이트
  • 작업 정의(서비스의 개수, 관리 방법 등)를 업데이트하면서 서비스를 지속적으로 실행할 수 있도록 함
• Scaling
  • 요구 사항 / 정책에 따라 자동으로 확장 및 축소 시킴