Introduction
개발 단계에서 밍글이 사용했던 서버 인스턴스 서비스는 AWS의 EC2였습니다. EC2는 AWS 계정을 만들게 되면 기본적으로 1년간 프리티어를 제공하기도했고 AWS를 처음 사용해보는 입장에서 가장 간단하게 서버를 배포할 수 있는 방법 중 하나였기 때문에 자연스럽게 개발 서버를 EC2에 올리게 되었습니다.
물론 EC2에 서버를 올리는 방향을 서비스를 릴리즈할 때까지 사용하기에는 비용적인 측면으로나, 유연성적인 측면으로 보았을 때 무리가 있다고 판단을 했고 슬슬 개발 서버 배포가 잦아지면서 수동 배포에 지쳐 쓰러져갈 때 쯤 본격적으로 배포 자동화 파이프라인 도입 겸, 서버 배포 컨테이너 서비스에 대한 조사 및 적용을 계획했습니다.
이 글을 통해 밍글이 컨테이너 서비스를 비교 및 선택한 과정 및 해당 서비스를 활용해 배포 자동화 파이프라인을 구축한 과정을 공유하려고 합니다.
서비스 선택 과정
본격적인 배포 자동화 파이프라인을 구성하기 전, 밍글 서버를 어느 서비스를 사용해서 배포할지 결정이 필요했습니다.
이에 여러 서비스들을 찾아봤고 최종적으로 다음 밍글 서버의 보금자리를 위해 비교했던 완전 관리형 컨테이너 오케스트레이션 서비스들은 다음과 같습니다.
- EKS
- ECS with EC2
- ECS with Fargate
아래 내용을 통해 통해 각 서비스들의 특징은 무엇이고 어떤 점들을 밍글 서버로 고려하는데 중요하게 보았는지를 정리해보겠습니다.
EKS (Elastic Kubernetes Service)
EKS는 오픈 소스인 Kubernetes 기반 애플리케이션을 AWS에서 운영하는데 도움을 주는 서비스입니다. AWS에서 Kubernetes(이하 k8s) 를 AWS EC2 인스턴스나 Fargate 위에 실행시켜서 제공하는 서비스로 k8s에 대한 관리형 서비스로 볼 수 있습니다. k8s를 통한 클러스터의 운영, 확장, 업그레이드, 보안 패치 등을 자동으로 해준다는 점에서 기존 EC2 위에 직접 k8s를 올려서 사용하는 것에 비해 유리하다고 볼 수 있습니다.
장점
- 손쉬운 k8s 클러스터 생성
- k8s가 지원하는 container orchestration 기능을 그대로 사용할 수 있다
- 롤링 배포, auto scaling, 자동 복구 등
- AWS에서 제공하는 다양한 기능(VPC, ELB, IAM 등) 들을 같이 활용할 수 있다
- VPC, ELB등 와의 연계
- 클러스터 외부와의 통신이 가능
- IAM과 연결한 인증 및 인가 구조를 제공
단점
- 오픈 소스인 Kubernetes 기반 애플리케이션을 AWS에서 운영하는데 도움을 주는 서비스:
- AWS에서는 오픈 소스 생태계에서 나오는 도구에 익숙하고, 이를 잘 결합해서 운영할 노하우가 있다면 Amazon EKS를 추천하지만 현재 우리 팀은 k8s 에 대한 지식이 부족함
- 제대로 k8s의 장점을 살리면서 운용하지 못할 가능성이 크다고 판단했습니다.
- 다른 서비스들에 비해 비용이 높음
- 개발 단계였기 때문에 밍글 서버에 사용할 수 있는 비용적 여유가 크지 않았습니다.
ECS (Elastic Container Service)
ECS는 컨테이너식 애플리케이션의 배포, 관리 및 크기 조정을 간소화하는 완전관리형 컨테이너 오케스트레이션 서비스입니다.
Docker기반으로 운영되며, 컨테이너가 실행될 환경 (compatibilities)를 EC2 또는 Fargate로 설정할 수 있습니다.
장점
- 기존의 AWS 서비스를 잘 결합해서 컨테이너 배포에 맞도록 서비스를 만들었기 때문에 손쉽게 배포 및 운영이 가능하다.
- AWS에서 제공하는 서버리스 서비스인 Fargate를 사용하여 인스턴스를 생성할 수 있다.
- EKS에 비해 서비스 구조가 어렵지 않다.
- 클러스터를 관리하는데 대한 추가적인 비용이 없다.
- 여러 container orchestration 기능을 사용할 수 있다.
- 롤링 배포, auto scaling, 자동 복구 등
- AWS의 다른 서비스들과 연동이 편하다.
- cloudwatch, ELB 등의 서비스를 콘솔을 통해 바로 연결할 수 있다.
- 이를 통해 애플리케이션 로그 및 원격 분석의 데이터를 관찰할 수 있다.
EC2 기반
장점
- EC2 인스턴스에 대한 full 컨트롤을 가질 수 있으며 세부적인 설정을 할 수 있습니다.
단점
- EC2 인스턴스를 직접 관리해야한다. 예: 인스턴스에 대한 보안 패치 등을 직접 처리해야함
- underlying infrastructure details, the launch instance, the network security setting, and the auto-scaling group 등을 직접 정의해주어야함
Fargate 기반
- Fargate는 컨테이너 배포 및 운영은 AWS에 맡기고, 실행하는 데 필요한 리소스에 대해서만 비용을 지불하는 서버리스 엔진이다.
장점
- 노드 기반 클러스터를 만들고 관리할 필요가 없어 애플리케이션별로 자동으로 리소스를 지정하면 된다.
- 기반 인프라, 클러스터의 생성, 구성 및 확장, 컨테이너 호스트 등을 걱정할 필요가 없습니다. 이러한 구성은 AWS에서 자동으로 관리해준다.
- 별도의 권한, 보안 레이어를 구성할 필요 없이 AWS에서 제공하는 기능 그대로 가상의 클러스터를 구축하고 그 안에 서비스를 생성, Fargate 기반의 작업을 실행하는 것이 가능하다.
- CPU 및 메모리 용량, 네트워크 보안 설정, IAM 정책 정도만 설정해주어도 된다.
- 비용 측면에서는 작업 실행에 필요한 가상 CPU 및 메모리 리소스만 지불하면 된다.
Conclusion
AWS 공식 문서에서는 EKS에 비해 ECS가 좀 더 simplicity를 추구 가능하다고 표현합니다.
이에 밍글에서는 각 서비스의 장단점을 토대로
- 가격
- 더 단순하고 쉬운 서비스
- 배포 및 관리의 간단함 및 편리성
- Cloudwatch를 통한 로그 확인
- AWS 내부 서비스과의 연동성
등의 장점을 고려해 ECS + Fargate로 배포 서비스를 결정하였습니다.
다음 글에서는 ECR에 도커 이미지를 올리고 및 AWS ECS + Fargate로 서버 배포 과정을 적어보겠습니다.
좋은 글 감사합니다.