Containers on AWS
컨테이너는 클라우드 환경에서 어플리케이션을 실행하는 방법에 대해 표준이 될 정도로 많은 사용자들이 컨테이너를 사용합니다.
2020년 CNCF (클라우드 네이티브 컴퓨팅 재단)의 survey결과 91%의 제품에 컨테이너를 사용중이라고 합니다.
컨테이너는 VM이 아니고 프로세스이기 때문에 다양한 이유로 컨테이너가 죽을 수 있고, 수 많은 컨테이너와 그 이미지를 직접 관리하는 것은 비효율적이고 오류가 발생하기 쉽습니다.
AWS에서는 컨테이너 서비스를 위해 다양한 서비스를 제공하고 있습니다.
컨테이너 관리 (ECS, EKS)
배포, 스케줄링, 컨테이너화 된 어플리케이션 스케일링 관리
호스팅 (EC2, Fargate)
컨테이너가 동작하는 환경
이미지 레지스트리 (ECR)
Private 컨테이너 이미지 저장소 / public도 제공 할 수 있도록 업데이트 되었다.
AWS Elastic Container Service
AWS 환경에서 컨테이너를 쉽게 실행, 확장 및 보호할 수 있는 컨테이너 오케스트레이션 서비스입니다.
ECS는 AWS에서 제공하는 서비스이고 실제 컨테이너가 구동되는 것은 EC2와 같은 컴퓨트 엔진으로 ECS Agent을 통해 컨트롤 플레인과 통신합니다.
Data Plane : 트래픽을 전송하는 목적을 제공하는 영역
Control Plane : Data Plane 으로 어떻게 무슨 트래픽이 흐르도록 제어하는 영역
ECS의 구성요소
ECS 클러스터
작업이 실행되는 논리적 그룹, 컨트롤 플레인을 클러스터 별로 쪼개는 단위
클러스터에 어떻게 로그인 할지 정책이나 (Firelens를 사용하려면 로그인 필요), 모니터링, 태그, 이름 등 관리차원에 필요한 정보가 필요합니다.
ECS Task
하나 혹은 둘 이상의 컨테이너로 이루어진 실제 컨테이너 Task, 쿠버네티스의 Pod과 비슷한 개념
ECS의 최소 실행 단위로 컨테이너에 배치 됩니다. 이 컨테이너가 무슨 이미지를 가질꺼고, 어떤 로그 라우터를 사용하고, 포트는 무엇을 사용할지 등을 지정해줍니다.
컨테이너를 어떤 인스턴스 (EC2 또는 Fargate) 로 배치할 건지도 선택 합니다.
ECS 서비스
Task를 지속적으로 관리하며, 실패한 Task을 자동으로 대체하여 Task수를 유지 및 복구 해줍니다.
서비스 유형 (replica, daemon) , Task 배치 전략을 선택할 수 있습니다.
배포 유형을 Rolling (ECS로 제어), Blue/Green (CodeDeploy로 제어) 선택할 수 있습니다.
ALB를 통해 로드밸런싱을 수행하며 어떤 LB에 붙일지도 명시 합니다.
서비스 오토스케일링이 가능합니다.
Cluster Auto Scaling
기존의 Auto Scaling
- 클러스터 생성
- Auto Scaling Group 생성
- 인스턴스 시작
- Task 수행
스케일링은 인프라 우선 주의이며, 지표는 이미 수행중인 태스크와 리소스에 기반하기 때문에 어플리케이션의 성격은 반영하지 않습니다.
EC2 인스턴스 수를 어플리케이션에 맞게 Scale In/Out 하기 위해 2019년에 ECS Capacity Provider라는게 나왔습니다.
- 클러스터 생성
- Auto Scaling Group 생성
- Capacity Provider 생성
- Task 실행 (원래는 인스턴스 없이 실행하면 Fail 된다)
- 인스턴스 시작
- Task 배치
아직 전체적인 그림이 이해가 가지 않는다..
AWS Fargate
Firecracker라는 가상화 기술을 통해 경량의 마이크로 VM을 생성하여 "하나의" ECS Task만 호스팅 합니다.
만약 팀에 인프라를 담당할 수 있는 사람이 없다면 Fargate를 고려해보면 좋습니다.
Fargate의 장점
- 관리 업무로 인한 오버헤드 경감
- 까다로운 컨테이너 클러스터 관리를 AWS에 위임하여 어플리케이션에만 집중 가능
- 기존 컨테이너 그대로 배포 가능
- 기존에 사용하던 컨테이너를 변경할 필요 없고 컨테이너 관리 차원에서도 달라지는것이 없습니다.
- gpu사용의 경우 제약이 있어 EC2 인스턴스를 사용하여야 합니다.
- 필요한 만큼만 사용 가능하고, 연동이 쉽다.
- 컨테이너 실행에 필요한 자원만큼만 비용을 지불하면 되며, 기본 AWS 네트워크, 보안과 네이티브 하게 통합하여 사용 가능합니다.
- 만약 자원의 80%가 되면 오토스케일링을 한다고 하면 20%는 항상 놀게 되는데 이를 최소화 하여 쓴 만큼만 오토스케일링 할 수 있어 비용 최소화가 가능합니다.
Fargate Data Plane
자 우리의 VPC안에 RDS가 있습니다. 그렇다면 컨테이너가 우리의 RDS에 접근할 수 있어야 하는데 Fargate VPC는 따로 떨어져 있는데 어떻게 우리의 VPC와 통신이 될까요?
컨테이너는 이더넷으로 컨테이너 런타임 위에 연결이 되어 있고, Fargate도 OS에 이더넷으로 연결되어 동일한 네트워크 그룹을 갖게 됩니다.
AWS Fargate는 CPU와 메모리 용량 규격이 정해져있습니다.
인스턴스 수준의 제어가 필요하거나 사용자 지정 옵션이 필요 하면 (e.g OS레벨에 보안 컴포넌트가 필요) 인스턴스 수준의 제어가 필요하기 때문에 EC2를 사용하여야 합니다. + GPU를 사용한 워크로드
비용 최적화를 위해 Fargate 스팟이 있고 최대 70퍼 절약이 가능합니다.
한 클러스터 내에 Fargate와 EC2를 혼용해서 쓸 수 있습니다.
그 외 AWS에서 제공하는 컨테이너 도구들
ECR
완전 관리형 Private 도커 레지스트리 (public도 제공함)
이미지 스캐닝을 지원한다. (컨테이너 이미지에 대한 보안으로 이미지가 들어왔을 때 위험한 이미지가 EC2에 배포하면 위험하니 정적으로 스캔하는 기능)
Amazon Code Series (CI/CD)
소스 저장소 (Code Commit)
단위 테스트 후 빌드 (Code Build)
배포 (Code Deploy)
Cloudwatch Container Insights
사전 정의된 대시보드, 컨테이너화 된 어플리케이션이나 마이크로 서비스에 대한 메트릭 정보 모니터링 및 알람을 위한 완전 관리형 관측 서비스
Firelens
컨테이너 로그 라우터
AWS및 APN파트너의 로그 분석 및 스토리지 도구에 기본적으로 로그 전송
로그 수집과 파이프라인을 분리
ECS vs EKS
ECS 목적
컨테이너 기술을 잘 알지 못해도 쉽고 빠르게 컨테이너로 배포하도록 하는게 기본 철학
AWS 서비스를 이용해 NoOps가 목표
AWS스택으로 모든 것을 제어하고, 콘솔을 사용해 쉽고 다양한 오토스케일링 정책 설정 가능하고 모니터링/로깅 설정이 가능하다.
EKS 목적
쿠버네티스의 최대 단점인 어려운점을 보완하기 위해 쿠버네티스를 쉽고 빠르게 사용하는 것이 목적
쿠버네티스가 어렵더라도 더 유연하게 많은 컴포넌트를 사용할 수 있다.
그래도 어렵던데..
AWS와 K8S로 관리 포인트가 이원화되며, 오픈소스 기반의 다양한 모니터링/로깅 설정이 가능하다.
CLI 기반으로 Console을 사용하기 위해서 별도의 대시보드 제품을 고려하여아 한다.)
'AWS' 카테고리의 다른 글
| AWS Container Immersion Day - EKS (0) | 2021.04.08 |
|---|
