AWS 301 세미나 - 컨테이너 서비스

왜 301일까...?

 

주제 : AWS 컨테이너 서비스(ECS, EKS, Fargate) 활용을 위한 고급 이론과 실습

일시 및 장소 : 2019년 8월 23일 메디톡스 빌딩 지하 1층

 

 

저번주 금요일에 AWS에서 주최하는 세미나 중 하나인 301 세미나에 다녀왔다. AWS에서 진행하는 세미나는 단계에 따라 101, 201, 301 세미나로 나누어진다. 문득 왜 이름을 저런식으로 정했는지 너무 궁금했다. (처음엔 강의실 호수인 줄)

 

신청한 이유는 평소에 docker를 사용하긴 하는데 docker swarm이나 kubernetes 같은 오케스트레이션 툴까지는 사용해 볼 일이 없어서 언젠가 공부해봐야지 했는데 마침 세미나 리스트에 해당 주제가 있었기 때문이었다. 예전에 구글링하다가 타다 서비스와 비트윈 서비스를 만든 VCNC에서 EKS로 서비스 이관한 과정에 대한 글을 흥미롭게 읽은 기억이 있어서 기대하며 세미나에 갔다.

 

사람이 꽤 많았다.

세미나는 이론과 실습을 모두 진행하는데 여기서는 발표해주신 이론 내용만 정리해보려고 한다. 세미나는 크게 Docker와 Kubernetes, ECS, EKS 등을 주제로 진행되었다. 정리가 목적인 글이어서 글의 흐름이 매끄럽지 못할 수 있을 것 같다.

 

 

---

 

1. Docker와 오케스트레이션 툴

 

사실 VM을 사용해봤다면 docker는 어려운 개념은 아니다. 다만 docker는 프로세스 가상화인 점이 다르다. 중요한 건 커널을 공유하는지이다. docker는 호스트와 커널을 공유한다. 개인적으로 아래 그림이 docker와 VM을 잘 설명하고 있다고 생각한다.

 

왼쪽이 VM, 오른쪽이 docker

보통 서버 몇 대만으로 운영되는 서비스는 흔치않으므로 결국 docker로 서비스를 하려면 여러 개의 컨테이너들을 운영해야하는 상황에 마주치게 된다. 이 때 오케스트레이션 툴이 필요해진다. 오케스트레이션 툴은 서버 밸런싱, 고가용성 등 서비스 운영 시 요구되는 다양한 요소들을 관리하고 보장할 수 있도록 해준다.

 

 

2. Kubernetes 기본 개념

 

출처 : https://www.nakivo.com/blog/docker-vs-kubernetes/

 

우리는 CPU와 메모리를 설정해서 job만 요청하면된다. 오케스트레이션 툴들은 사용자가 던진 job을 받아서 알아서 상황에 맞게 컨테이너를 띄어줄 것이다. 서비스 관리는 서비스 디스커버리를 통해 이루어진다. key-value 형태의 메모리 저장소 (etcd!) 에 모든 컨테이너와 관련된 정보가 저장되어 있기 때문에 고가용성을 보장하는 서비스 관리가 가능하다. CPU, 메모리, 디스크와 같은 리소스들도 관리해준다. 서버 자체와 pod에 대한 Auto-Scaling도 해준다. 컨테이너 업그레이드 및 롤백도 가능하다. 어떤 종류의 컨테이너를 어디에 배치할 것인지에 대한 것도 (Placement) 가능하다.

 

출처 : https://www.nakivo.com/blog/docker-vs-kubernetes/

 

 

클러스터를 관리하는 Master Node와 실제로 컨테이너를 띄우는 Worker Node로 구성된다. 명령이 들어오면 API Server를 거쳐 Worker Node가 컨테이너를 띄우는 구조이다.

 

Pod으로 띄우는 경우 서버나 컨테이너가 죽으면 문제가 발생할 수 있으므로 가용성을 위해 Replica set도 설정할 수 있다.

 

버전 1.12 부터 라벨링을 지원한다. 볼륨은 물리적으로 떨어져 있으므로 볼륨 혼용 문제는 꽤나 머리 아픈 문제였다. 그러나 이러한 라벨링을 통해 볼륨이 속해 있는 가용 영역에 맞게 컨테이너를 띄울 수 있게 되었다. (?)

 - 이 부분 정리가 제대로 안되어있어서 맞는 말인지 확인이 좀 필요하다.

 

YAML 파일로 설정을 모든 배포나 서비스를 관리할 수 있다.

 

NAS 볼륨이나 외부 볼륨들을 컨테이너에 마운트하여 사용할 수 있는 드라이버를 제공하는 CSI 프로젝트라는 것이 있다.

 

Pod 은 1개 이상의 컨테이너의 묶음이다. 멀쩡한 컨테이너를 묶어서 배포하는 데에는 나름의 장점이 있다. 일단 한 pod 안에 있는 컨테이너들은 같은 IP와 port를 공유한다. 스토리지도 공유한다. 덕분에 pod 내의 컨테이너들끼리는 localhost로 통신이 가능하다. 그래서 묶음 단위의 서비스로 배포가 가능하다. 예를 들어 웹 서버 컨테이너 + 로깅 서버 컨테이너 조합으로 pod을 생성할 수 있다는 것이다.

 

Service 는 pod들의 L4 load balancer 역할을 한다. default로 round robin 방식을 사용한다. 실제로 ingress 같은 L7 load balancer (Nginx, HAProxy...) 를 추가할 수도 있다. Cluster IP 제공, load balancer 역할, NodePort 방식의 세 가지 타입이 모두 가능하다. 결론적으로 service로 만들어주어야 외부에서 접근이 가능하다.

 

Namespace 는 논리적인 구분 단위이다. 그냥 그야말로 나누고 싶은대로 나누면 된다. 접근제어가 가능하기 때문에 프로젝트 단위로 나누어도 좋다.

 

kublet 은 노드들에 있는 에이전트로 master node의 명령을 수행하고 상태를 보고하는 역할을 한다.

 

kube-proxy 는 일종의 추상화된 서비스 레이어로 load balancer 역할을 한다.

 

kube-api-server 는 그냥 간단히 REST API 서버이다.

 

etcd 는 앞서 언급했듯이 클러스터 내 모든 컨테이너의 상태 정보를 저장하는 일종의 key-value 저장소이다.

 

 

3. ECS vs EKS

 

ECS와 EKS 모두 AWS의 서비스이다. EKS의 경우 AWS에서 제공하는 kubernetes 서비스이고, ECS는 AWS에서 자체적으로 제공하는 오케스트레이션 서비스이다. 기능적인 측면에서는 kubernetes가 우위이지만 AWS의 다른 서비스와의 연동은 ECS가 더 낫다고 한다. 큰 차이로는 EKS의 경우 Master Node를 직접 사용하려면 비용이 발생하지만 ECS는 비용이 발생하지 않는다는 점이다. 또한, kubernetes는 1000 Unit을 1 Core로 인식하고 AWS는 1024 Unit을 1 Core로 인식한다는 차이점도 있다.

 

다만 kubernetes의 경우. GCP나 MS Azure 등의 다른 클라우드 플랫폼에서도 지원하기 때문에 마이그레이션에 있어서는 더 안전하다.

 

두 가지 모두 fargate (일종의 ec2 같은, 그러나 좀 더 세부적으로 컨트롤이 가능한 컴퓨팅 엔진) 사용이 가능하다.

 

 

4. ECS

 

출처 : AWS

클러스터와 관련된 개념들은 kubernetes와 동일하다. 다만 kubernetes에서의 pod은 ECS에서는 task라고 부른다. YAML과 비슷한 형태인 설정 파일을 사용할 수 있다.

 

각 컨테이너에는 awslogs 로그 드라이버가 데몬으로 돌고 있어서 control plane 로그를 CloudWatch에 보내 모니터링이 가능하다.

 

Role의 경우 서버 단위가 아닌 컨테이너 단위로 IAM Role을 설정할 수 있어 최소한의 권한만을 부여할 수 있다.

 

Auto-Scaling 및 다양한 형태의 배포가 가능하다. 당연히 load balancer도 붙일 수 있다.

 

업데이트시에는 Rolling Update와 Blue-Green Deployment를 모두 지원한다.

 

 

7. EKS

 

Worker Node 내부에 DNS 서버가 있어서 도메인으로도 접근이 가능하다.

 

RBAC의 경우 사용자마다 컨테이너에 대한 권한을 어떻게 줄 것인지에 대한 설정인데 EKS의 경우 여기에 IAM Role까지 추가로 사용할 수 있다.

 

Control Plane, etcd 관리를 지원한다.

 

클러스터의 경우 최신 버전부터 아래로 두 버전 이하까지 제공한다.

 

Worker Node를 버전 업데이트하는 경우 CloudFormation으로 노드를 만들어 클러스터에 조인시킨 후 나머지 노드들은 taint 시킨다.

 

ECR 사용이 가능하다. (컨테이너 이미지 서비스)

 

aws_node daemonset 은 Container Network Interface 을 제공한다. CNI를 사용하는 경우 pod이 뜰 때 VPC에 있는 IP 중 하나의 IP를 사용하기 때문에 다른 서버들과 통신이 용이하고, 네트워크적으로 레이어가 줄어들어 속도가 빠르다는 장점이 있다. (VPC 에서 바로 node의 pod으로 갈 수 있음) 또한, 트래픽 통제 및 세부 모니터링이 가능해진다. 다만, CNI를 사용하므로써 더해지는 limit이 존재할 수 있다.

 

 

6. 업데이트된 내용들

 

Windows 이미지의 컨테이너도 지원한다.

ARM CPU 인스턴스도 지원한다.

- 더 있었던 것 같은데...

 

7. 더 자세한 내용

 

eksworkshop.com

EKSworkshop.com

 

---

 

세미나는 전반적으로 유익했던 것 같다. 약간 서비스 도입하기 전에 괜찮을지 판단해야하거나 빠르게 개념을 훑어보고 싶을 때 좋을 것 같은 세미나였다. 후반부로 갈수록 집중력이 좀 떨어져서 정리를 제대로 못하긴 했지만 큰 그림을 잡는 데에는 무리가 없었던 것 같다. 활용만 잘 하면 진짜 편리한 기능과 서비스인 것 같다. (뭐 대부분 그렇긴 하지만)

 

 

$20인가 하는 크레딧을 준다

설문조사하면 요런 귀염뽀짝한 스티커도 준다

 

다음 세미나는 배포 자동화에 관련된 것 하나와 보안 서비스 관련된 세미나였는데 시간이 된다면 들어보고 싶다.