Chapter 02 컨테이너 설계에 필요한 AWS 기초 지식
2-1 AWS가 제공하는 컨테이너 서비스
제어 플레인
- 제어 플레인이란 컨테이너를 관리하는 기능을 의미한다.
- AWS가 제공하는 제어 플레인은 2가지가 있다.
Amazon Elastic Container Service (ECS)
- ECS는 완전 관리형 (Fully managed) 컨테이너 오케스트레이터다.
- 컨테이너를 동작시키는 실행 환경 서비스는 아니다.
- 쿠버네티스와 달리 AWS가 소유권을 가지고 제공한다.
- ECS는 다른 AWS 서비스와의 연계성이 매우 좋고 신뢰성이 높다.
- 태스크 (Task)
- 애플리케이션 실행을 위해선 컨테이너가 필요한데 컨테이너가 동작하는 컴포넌트를 태스크라 한다.
- 하나 이상의 컨테이너로 구성된 애플리케이션 실행 단위
- 태스크 정의 (Task Definition)
- 태스크를 만드는 템플릿 정의 (JSON 형식)
- 컨테이너 이미지, 할당할 자원, Log 출력 장소 등을 지정
- 태스크 정의에 컨테이너 정의는 여러 개 설정 가능
- 서비스 (Service)
- 지정한 수만큼의 태스크를 유지하는 스케줄러
- 서비스를 만들 땐 실행할 태스크 수에 맞춰 로드 밸런서와 태스크를 실행할 네트워크를 지정한다.
- 태스크가 어떤 이유로 종료 되어도 태스크 정의를 바탕으로 새로운 태스크를 만들어 수를 유지한다.
- 클러스터 (Cluster)
Amazon Elastic Kubernetes Service (EKS)
- EKS는 완전 관리형 쿠버네티스 서비스다.
- EKS를 통해 쿠버네티스 제어 플레인 관리를 AWS에게 위임할 수 있다.
- 쿠버네티스 노드를 동작시키는 실행 환경으로 Fargate를 선택할 수 있다.
- EKS는 쿠버네티스 기반이기에 ECS와 달리 AWS 독자적인 용어를 사용하지는 않는다.
데이터 플레인
- 컨테이너가 실제로 동작하는 지원 환경을 지정
- AWS가 제공하는 데이터 플레인은 2가지가 있다.
Amazon Elastic Compute Cloud (EC2)
- EC2는 AWS에서 가상 머신을 이용할 수 있는 서비스
- ECS나 EKS에서 EC2를 컨테이너 호스트로 사용할 수 있다.
- 호스트를 운영하는 비용이 높아진다.
- 서버가 제대로 동작하는지에 대한 모니터링과 자원 관리를 직접 해야 하기 때문
- 대신 유연성을 요하는 설계에서 필요한 경우가 있다.
AWS Fargate
- Fargate는 컨테이너용 서버리스 컴퓨팅 엔진이다.
- 컨테이너용이기에 Fargate만으로는 이용할 수 없다.
- Fargate 장점
- 호스트를 관리하지 않아도 된다.
- Fargate 컨테이너 실행 환경은 AWS에서 언제나 최신 상태를 유지해준다.
- Fargate 단점
- EC2를 사용하는 것보다 가격이 비싸다.
- 커널 관련 매개변수나 OS 자원을 세세하게 튜닝해야 하는 애플리케이션과는 맞지 않는다.
- 컨테이너 기동 시간이 다소 오래 걸린다.
- 단점에도 불구하고 Fargate를 선택한다면 그 이유
- Fargate 스케일링은 매우 간단
- OS 관련된 운영을 하지 않아도 되기에 전담 인력을 확충하지 않아도 된다.
- 요금이 EC2에 비해선 높지만 TCO 관점에선 압도적으로 유리하다.
- TCO 비용: 서비스 도입, 유지, 관리에 드는 총 비용
- EC2 관리 인건비 + EC2 비용 > Fargate 비용
- 비즈니스에서 부가 가치를 만드는 활동에 주력하는 의미에서 신규 컨테이너 구축 시 Fargate 활용이 가능한지 적극 검토해보기 바란다.
Amazon Elastic Container Registry (ECR)
- ECR은 완전 관리형 컨테이너 저장소다.
- ECS와의 연계가 쉽기 때문에 새 컨테이너를 만들 때도 ECR의 이미지를 가져올 수 있다.
- ECR을 통해 Dockerfile에서 이미지를 바로 취득할 때 도커 허브를 이용하지 않아도 된다.
- AWS에 시스템을 구축한다면 다른 AWS 서비스와의 연계나 보안을 고려해 ECR을 사용하는 것을 추천한다.
2-2 아키텍처 구성 예
- 지금까지의 제어 플레인과 데이터 플레인으로 컨테이너를 이용하는 아키텍처를 검토해보자
- 다음 4가지 내용으로 장단점을 구려해보자
- 비용
- AWS 서비스 사용료
- 운영 비용 (인적 비용등의 간접 비용)
- 학습 비용 (AWS에 대한 학습)
- 확장성
- 배포의 신속성, 수평 스케일링, 자원 확장 (수직 스케일링)
- 신뢰성
- 의도한 기능을 워크로드가 위도대로 수행하는 것을 보증
- 어떤 문제가 생겼을 때 신속히 복구가 가능한지
- 엔지니어링 관점
ECS on EC2
- 비용
- 서비스 사용료 - EC2 사용료
- EC2 인스턴스와 EBS 볼륨에 대한 서비스 사용료가 발생
- EC2는 실행 시간만큼 비용이 발생하고 인스턴스가 커질수록 다가가 커진다.
- 운영 비용은 높은 편
- EC2의 OS 관리 등을 유지보수 해야하기 때문
- 학습 비용 측면에선 EC2가 오래된 서비스이기에 비교적 구축과 관련된 정보를 많이 얻을 수 있다.
- 확장성
- 배포의 신속성은 우수
- 이미지 캐시를 EC2 호스트에 저장할 수 있어 이미지 다운로드 시간이 단축된다.
- 수평 스케일링은 확보한 용량까지만 가능하기에 다소 약한 편
- 수직 스케일링은 AWS 콘솔에서 쉽게 변경할 수 있어 우수하다.
- 신뢰성
- ECS는 관리형 서비스이기에 장애 복구는 AWS의 책임
- EC2에 직접 접근 가능하기에 장애 조사 자체는 비교적 쉬운 편
- ECS는 AWS 자체 오케스트레이터이기에 AWS에 지원을 요청하면 다양한 전문적 지원을 받을 수도 있다.
- 엔지니어링 관점
ECS on Fargate
- 비용
- 서비스 비용으로 Fargate 비용이 주로 발생한다.
- 컨테이너 이미지 취득 시점부터 ECS 태스크가 종료될 때까지를 초 단위로 과금한다.
- EC2보다 다소 비싼 편
- 운영 비용은 상당히 낮다.
- 인프라 관리 비용이 거의 들지 않음
- 컨테이너 실행을 위한 인프라를 추상화할 수 있어 OS와 미들웨어 취약점에 대한 대응을 하지 않아도 된다고 한다.
- 학습 비용 측면에선 ECS on EC2와 많은 부분이 동일하다.
- Fargate에 대한 몇 가지 제약 사항을 이해하면 되는 정도
- 확장성
- 배포의 신속성은 우수하지 않다.
- Fargate에서 가동하는 컨테이너는 각각 ENI(Elastic Network Interface)를 연결해야하기 때문인데 ENI 생성에는 다소 시간이 걸린다.
- 이미지 캐시가 불가능해 컨테이너 이미지 취득에 시간이 걸린다.
- 수평적 스케일링은 쉽게 조절 가능
- 수직적 스케일링에는 몇 가지 제약이 존재
- 신뢰성
- ECS와 관련된 부분은 ECS on EC2와 같다.
- Fargate는 SSH를 통해 호스트에 접근할 수 없지만 ECS Exec을 통해 Fargate 장애 조사가 편해졌다.
- ECS Exec을 통해 컨테이너에 대화형 셸을 이용해 조작하거나 명령할 수 있다.
- 엔지니어링 관점
- ECS on EC2와 마찬가지로 비교적 엔지니어 확보는 쉬운 편
EKS on EC2
- 비용
- 데이터 플레인 사용료에 비해선 미미하지만 ECS와 달리 EKS에 과금이 이루어진다.
- 운영 비용은 비교적 비싸다.
- EC2의 높은 운영 비용에 쿠버네티스 운영 비용도 높기 때문
- 쿠버네티스는 3개월에 한 번 마이너 버전이 나오기에 정기적으로 컨테이너 플랫폼 버전을 업데이트하는 운영이 필요
- 학습 비용은 비교적 높은 편
- 확장성
- 신뢰성
- EKS도 AWS가 관리하기에 EKS 자체 장애는 AWS가 관리해준다.
- 다만 쿠버네티스 자체에 문제가 발생하면 AWS에서 해결할 수 없는 문제가 된다.
- 쿠버네티스 자체 문제 발생 시 자력으로 문제를 해결해야 함
- 엔지니어링 관점
- 새로운 체제와 기술을 배우고 싶은 엔지니어가 있는 조직이라면 EKS를 채용해보는 것도 충분한 가치가 있을 것
EKS on Fargate
- 이 아키텍처의 특징은 데이터 플레인을 모두 Fargate로 하지는 않는다는 점이다.
- 상주 실행이 필요한 처리는 EC2
- 스팟 처리가 필요한 경우엔 Fargate
- 비용
- 서비스 사용료로는 EKS 비용 + Fargate 비용이 높게 발생
- Fargate 비용은 스팟 사용으로 줄일 수 있긴 하다.
- 운영 비용은 EKS on EC2에 비해선 낮다.
- 쿠버네티스 버전업 시 EKS on EC2에선 EC2까지 버전업을 해야 했지만 Fargate의 버전업을 불필요하기에 EKS만 버전업하면 된다.
- 학습 비용은 모든 아키텍처 중 제일 높다.
- 확장성
- ECS on Fargate와 큰 차이가 없다.
- 신뢰성
- 제어 플레인은 EKS on EC2와 같다.
- 데이터 플레인은 ECS on Fargate와 같다.
- 엔지니어링 관점
- EKS on EC2 아키텍처와 많이 비슷할 것이라 생각된다.
2-3 각 아키텍처를 적용한 사용 예
- 각 비즈니스의 특성에 따라 사용 사례와 전제 사항을 비교하여 어떤 아키텍처를 선택하면 좋을지 검토해야 한다.
온프레미스 또는 EC2에 쿠버네티스를 사용하는 경우
- 직접 쿠버네티스의 제어 플레인 및 데이터 플레인을 운영하는 경우
- 온프레미스 자산을 클라우드로 이전하고 싶은 경우
- 제어 플레인을 직접 운영하는 운영 비용을 줄이기 위해 아키텍처를 변경하는 경우
- 대상 아키텍처 선택 고려 사항
- 쿠버네티스는 OSS이기 때문에 어떤 클라우드 환경에서도 동작한다.
- 온프레미스나 EC2에 실행되는 쿠버네티스 매니페스트를 읽어와 관리형 서비스로 이전하는 것이 가능
- 그러나 이전 비용은 크기 때문에 우선 EKS를 선택하는 것이 좋다.
- EKS on Fargate는 제약이 많기 때문에 우선은 EKS on EC2로 구축하는 편이 좋다.
블록체인을 이용하는 풀 노드(Full node)를 구축하는 경우
- 블록체인을 사용하려면 대용량 데이터를 로컬에 저장해야할 필요가 있다.
- 데이터 플레인 선택
- EBS로 충분한 용량 확보가 가능한 EC2를 선택하는 것이 좋을 수 있다.
- 제어 플레인 선택
- AWS 이외의 클라우드나 온프레미스에서 동작시키는 것까지 고려한다면 EKS를 선택하는 것이 좋을 것이다.
- 학습 비용과 운영 비용을 생각한다면 ECS를 추천한다.
기계 학습이 필요한 경우
- 기계 학습을 위해선 막대한 처리가 필요하고 CPU보다는 병렬 처리에 특화된 GPU를 사용한다.
- 데이터 플레인 선택
- Fargate는 제약으로 인해 GPI를 사용할 수 없기에 EC2를 선택
- 제어 플레인 선택
- ECS, EKS 중 어느 것을 사용해도 상관없다.
- 팀 성격에 따라 적합한 것을 선택하자
높은 자원 집약율을 실현하고자 하는 경우
- ‘높은 자원 집약율’이란 인스턴스의 CPU와 메모리를 낭비하지 않게 사용한다는 것을 의미
- 온프레미스에선 자원을 다 사용하는 것은 과부하 문제가 있을 수 있지만 클라우드 서비스에선 자원을 전부 사용하는 것이 효율이 좋다.
- 데이터 플레인 선택
- 높은 자원 집약률 실현을 위해선 처리량에 따라 적절한 인스턴스 유형을 지정해야 한다.
- Fargate는 처리량에 따라 CPU와 메모리 요건을 지정해 호스트를 만들고 컨테이너를 실행하기에 Fargate가 적격
- 제어 플레인은 ECS와 EKS 어느 것을 사용해도 문제 없다.
SI로 서비스를 만드는 경우
- 서비스 관점이 아닌 조직에 관점을 맞춘 사용 방법
- 타사의 의뢰를 받아 서비스를 만드는 경우 제품에 대한 개선 노력이 결여돼 기술 부채가 쌓이기 쉬운 환경이다.
- 제품 기능에 직접적 영향 없는 부분의 개선은 SI 개발 측에선 어려운 경우가 많다.
- 제어 플레인 선택
- EKS를 선택했을 때 몇 개월마다 버전 업데이트 등의 비기능 개선이 필요하므로 ECS가 나은 선택일 수 있다.
- Ops 조직을 별도로 구축하기 어려운 환경이라면 더더욱 EKS를 선택하기 힘들 수 있다.
- 데이터 플레인 선택
- 운영 비용 최소화를 목적으로 Fargate를 추천한다.
자사 제품으로 서비스를 개발하는 경우
- 자사 개발이라도 비기능 개선이 어려운 것은 마찬가지다.
- 하지만 자사 개발의 경우에는 새롭게 시도한 것에 대한 노하우가 회사에 남는다.
- 데이터 플레인 선택
- 운영 비용을 줄이기 위해 우선 Fargate를 검토하는 것이 좋다.
- 좀 더 유연한 구성을 원하는 경우 EC2를 고려해보자.
- 제어 플레인 선택
- 엔지니어 확보, 앞으로의 TCP를 고려한 최적의 아키텍처를 선택할 필요가 있다.
- 사실상 표준인 EKS를 선택하느냐 AWS다운 서비스인 ECS를 선택하느냐 검토할 수 있을 것이다.
2-4 AWS에서 컨테이너를 이용할 때의 장점
- 로드맵 제공
- AWS 컨테이너 기술에선 컨테이너를 업데이트해 나가는 지침이 로드맵으로 제공된다.
- ECS, Fargate, ECR, ELS 및 기타 AWS 제공 OSS 프로젝트에 대한 대부분의 작업이 로드맵에 포함되어 있다.
- 필요한 기능이 있다면 깃허브 Issue를 이용해 요청할 수도 있다.
- 지속적인 요금 개정
- AWS는 가볍고 편하게 시작할 수 있으며 각 서비스 이용 요금도 비교적 합리적이다.
- Fargate나 EKS 등이 대폭 요금 인하된 사례도 있다.
- 다수의 컨테이너 활용 사례
- 활용 사례가 많다는 것은 그만큼 이용을 많이 한다는 지표
- 많은 컨퍼런스에서 AWS 컨테이너 서비스에 관한 발표가 다루어졌다.
- 풍부한 학습 매뉴얼
- AWS 공식 콘텐츠
- AWS 문서
- AWS Webinar
- 공식 컨퍼런스
- AWS가 매년 주최하는 AWS re:Invent와 AWS Summit이 있다.
- AWSKRUG (AWS 한국 사용자 모임)
- AWS Certification (자격증)
- … 등