어떤 컨테이너 오케스트레이션이 가장 적합합니까?

컨테이너화된 애플리케이션을 운영할 때, 정보 기술(IT) 팀은 다양한 선택지를 가지게 되며, 이는 모든 수준의 기술 전문성을 필요로 합니다.

하나의 옵션을 선택하는 것은 다른 옵션으로의 빠른 전환이 어려울 수 있다는 점을 고려할 때, 쉽지 않은 결정일 수 있습니다.

이 글에서는 Amazon Elastic Container Service (ECS)와 Kubernetes라는 두 가지 주요 선택지를 비교 분석합니다.

두 플랫폼 모두 컨테이너 오케스트레이션 및 마이크로서비스 관리 분야에서 뛰어난 성능을 자랑합니다. 더 자세히 알아보기 전에 컨테이너에 대한 간단한 복습을 해보는 것이 좋습니다. 컨테이너는 코드 개발, 테스트, 배포 과정을 간소화하여 널리 사용되고 있습니다. 컨테이너는 필요한 종속성, 라이브러리, 그리고 환경 설정을 포함한 코드를 실행 가능한 패키지로 묶는 애플리케이션 계층의 추상화입니다.

컨테이너 사용의 주된 목적은 코드 배포 과정을 단순화하는 것이지만, 수많은 컨테이너를 관리하는 것은 점점 더 복잡해지고 있습니다. 안정적인 배포, 부하에 따른 애플리케이션 확장, 비정상 컨테이너 교체, 부하 분산, 그리고 포트 노출을 위해서는 별도의 메커니즘이 필요합니다.

컨테이너 오케스트레이션은 이러한 문제를 해결하는 데 도움을 줍니다. 컨테이너 실행과 전체 인프라 관리를 위한 수단이 필요하며, 이를 위한 다양한 도구가 존재합니다. 여기서는 몇 가지 핵심적인 도구에 집중하여 살펴보겠습니다.

이 글에서는 ECS와 Kubernetes를 비교하여 각 플랫폼의 장점을 강조하고, 프로젝트에 가장 적합한 선택을 내릴 수 있도록 안내합니다.

Amazon ECS란 무엇인가?

Amazon ECS는 컨테이너화된 애플리케이션의 배포, 관리, 확장을 간소화하는 컨테이너 오케스트레이션 서비스입니다. 이 서비스는 기본적으로 애플리케이션과 필요한 리소스를 정의합니다. 그런 다음 Amazon ECS는 다른 AWS 서비스와 통합하여 컴퓨팅 옵션 전반에서 앱을 시작, 모니터링, 확장합니다. 프로그래밍 방식으로 상태를 확인하거나 클러스터를 수정하는 것도 가능합니다.

ECS를 사용하면 작업 정의 및 API (애플리케이션 프로그램 인터페이스) 호출을 통해 서버 그룹인 클러스터에 앱을 배포할 수 있습니다.

참고: 어떤 AWS EC2 인스턴스를 사용해야 합니까?

Amazon ECS의 장점

기존 ECS – 2015년에 처음 출시된 이 버전은 Amazon EC2를 기반으로 하여 클라우드에서 Docker 컨테이너를 쉽게 실행할 수 있게 해줍니다. 기존 ECS는 유연성이 뛰어난 EC2 옵션에 대한 기본적인 제어 기능을 제공합니다. 이는 컨테이너를 실행할 인스턴스 유형을 선택할 수 있다는 것을 의미합니다. 또한, EC2 인스턴스에서 활동을 모니터링하고 기록하는 데 사용되는 다른 AWS 서비스와 연동됩니다.
Fargate ECS – 2017년에 출시된 Fargate는 기본 EC2 컴퓨팅 옵션을 관리할 필요 없이 컨테이너를 실행할 수 있게 합니다. Fargate는 필요한 CPU와 메모리를 자동으로 계산하여 기존 방식과 다른 접근법을 제공합니다. 워크로드를 빠르게 시작하고 실행해야 할 경우, 기본 컴퓨팅 옵션에 대한 고민을 덜 수 있어 최적의 선택이 될 수 있습니다.
단순화된 애플리케이션 아키텍처 – ECS는 외부 종속성이 거의 없거나 이동 부분이 적은, 독립적으로 작동하는 마이크로서비스가 적은 애플리케이션에 적합한 선택입니다.
간편한 모니터링 및 로깅 – ECS는 CloudWatch와 같은 AWS 로깅 및 모니터링 도구와 쉽게 통합될 수 있습니다. 컨테이너 워크로드에 대한 가시성을 설정할 필요가 없어 시간을 절약할 수 있습니다.
쉬운 학습 곡선 – ECS는 배우기 쉽습니다. 호스팅된 Kubernetes가 KOPS 플레이버 및 Kubeadm과 같은 기존 모델보다 인기를 얻고 있지만, ECS는 여전히 학습이 용이합니다.
서버리스 인프라 – ECS를 사용하면 가상 머신을 직접 관리할 필요 없이 컨테이너를 실행할 수 있습니다. 컨테이너 배포를 사람의 개입 없이 자동화할 수 있습니다.
내장 보안 – Amazon ECS는 기본적으로 안전하게 보호되며, 격리된 Virtual Private Cloud 네트워킹 메커니즘을 통해 보안 조치를 단계적으로 적용합니다.

ECS의 한계

제한된 스토리지 – 외부 스토리지는 최대 Amazon EBS로 제한되어 Amazon에 종속됩니다.
검증 제한 – ECS는 Amazon 기반 제품이므로 Amazon 외부의 공용 배포에는 사용할 수 없습니다.
공급업체 종속 – ECS는 특정 공급업체에 종속적입니다. 생성된 컨테이너만 관리할 수 있습니다.
ECS 코드 사용 불가능 – ECS 코드의 대부분은 공개적으로 제공되지 않습니다. AWS Blox(사용자 정의 스케줄러 구축을 위한 프레임워크)와 같은 도구에는 오픈 소스 코드 기반의 아주 작은 부분만 존재합니다.

쿠버네티스란?

일반적으로 K8s라고 불리는 Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈 소스 소프트웨어입니다.

Kubernetes는 Google의 프로덕션 워크로드 운영 경험을 바탕으로 (최고의 아이디어와 커뮤니티 관행 결합) 애플리케이션 컨테이너를 찾고 관리하기 쉬운 논리적 단위로 그룹화합니다.

또한 로드 밸런싱, 영구 스토리지, 컨테이너화된 앱의 자동 롤백, 암호 관리, Kubernetes 클러스터의 자가 복구 및 구성 관리와 같은 주요 기능을 제공합니다.

참고: Kubernetes 시작하기: 초보자를 위한 소개

쿠버네티스의 장점

오픈 소스 (벤더 종속 없음) – Kubernetes는 온프레미스든 클라우드든, 오케스트레이션 전략을 재설계할 필요 없이 사용할 수 있습니다. 라이선스 비용이 필요한 기존 소프트웨어와 달리 K8s는 무료이며 오픈 소스입니다. 또한 K8s 클러스터는 퍼블릭 및 프라이빗 클라우드 모두에서 실행되어 양쪽 모두에 가상화 리소스를 제공할 수 있습니다.
강력한 유연성 – K8s는 애플리케이션의 고가용성을 요구하면서 효율성과 확장성도 지원해야 할 경우 훌륭한 솔루션입니다. 이러한 특성은 고수익을 창출하는 애플리케이션에서 특히 유용합니다. 간단히 말해 워크로드에 대한 세밀한 제어를 가능하게 합니다. 애플리케이션을 보다 강력한 플랫폼으로 전환하고 싶다면 K8s는 ECS와 같은 공급업체 종속성에 제한되지 않습니다.
고가용성 – K8s는 애플리케이션의 가용성과 필요한 인프라를 제공하도록 설계되어 생산 환경의 컨테이너에 필요한 기능을 제공합니다. 고가용성을 위한 몇 가지 주요 기술은 다음과 같습니다.
- 상태 확인 및 자가 치유 – Kubernetes는 정기적인 노드 검사를 통해 장애로부터 애플리케이션을 보호합니다. 오류로 인해 포드 또는 컨테이너가 손상되면 K8s는 자동으로 교체를 제공합니다.
- 로드 밸런싱 및 트래픽 라우팅 – 트래픽 라우팅과 관련하여 K8s는 적절한 컨테이너에만 요청을 전달합니다. 로드 밸런싱을 통해 포드 전체에 로드를 분산시켜 중단, 일시적인 트래픽 급증, 또는 대량 처리 등 다양한 상황에 리소스를 균형 있게 배분합니다. 또한 필요한 경우 외부 로드 밸런서를 사용할 수도 있습니다.
워크로드 확장성 – K8s는 다음과 같은 기준에서 효율적인 확장을 제공합니다.
- 자동 크기 조정 – CPU 사용률 및 기타 지표를 기반으로 실행 중인 컨테이너 수를 자동으로 조정할 수 있습니다.
- 수동 조정 – 명령줄 또는 인터페이스를 통해 실행 중인 컨테이너 수를 직접 조정할 수 있습니다.
- 복제 컨트롤러 – 이 도구를 사용하면 클러스터 사양과 일치하는 포드 수를 결정할 수 있습니다. 지정된 수보다 적으면 새로 시작하고, 너무 많으면 종료합니다.
배포를 위한 설계 – K8s는 소프트웨어 구축, 테스트, 배포 프로세스의 속도를 높이도록 특별히 설계되었습니다. 제공되는 기능 중 일부는 다음과 같습니다.
- 자동화된 롤백 및 롤아웃 – 개발 중에 새로운 구성이나 애플리케이션 업데이트를 배포할 수 있습니다. K8s를 사용하면 애플리케이션 중단 없이 프로세스를 수행할 수 있습니다. 문제가 발생하면 K8s는 자동으로 이전 버전으로 롤백합니다.
- 카나리아 배포 – 기존 버전과 병렬로 프로덕션 환경에서 새 배포를 테스트할 수 있습니다. K8s를 사용하면 이전 버전 앱을 축소하면서 최신 버전을 확장할 수 있습니다.
- 다양한 프로그래밍 언어 및 프레임워크 지원 – Go, Java, 또는 .Net 등 어떤 프로그래밍 언어 배경을 가지고 있든, Kubernetes는 많은 개발 언어 및 프레임워크를 지원합니다. 앱이 컨테이너에서 실행될 수 있다면 K8s에서도 실행할 수 있습니다.
서비스 검색 – 모든 개발자는 서비스 간의 통신 방법을 필요로 합니다. K8s의 운영 모델은 컨테이너를 지속적으로 생성하고 폐기하므로 특정 위치에 서비스가 존재하지 않을 수 있습니다. 기존 개발 환경에서는 서비스 레지스터를 사용하여 이러한 서비스의 위치를 추적합니다. K8s는 포드를 그룹화하고 서비스를 원활하게 검색하는 기본 서비스 개념을 통해 이 문제를 해결합니다. K8s는 모든 포드에 IP 주소를 제공하고, 포드 세트에 DNS 이름을 할당하며, 모든 포드 세트에서 부하 트래픽의 균형을 맞춥니다. 이러한 아키텍처는 서비스 검색이 모든 컨테이너에서 추상화된 환경을 생성합니다.
활발한 커뮤니티 – K8s는 수많은 개발자가 서비스를 활용하는 활발한 커뮤니티의 지원을 받습니다. 작성 시점에 1억 명이 넘는 개발자가 K8s를 사용하여 3억 3천만 개 이상의 프로젝트를 발견했습니다. 커뮤니티는 지속적으로 성장하고 있으며 개발자 간의 협업을 장려합니다.

쿠버네티스의 한계

가파른 학습 곡선 – Kubernetes를 사용하려면 해당 환경에 대한 깊이 있는 이해가 필요합니다. 또한 종단 간 솔루션을 제공하기 위해 다양한 기술과 서비스를 통합해야 합니다. 관련 기술이 상당히 다양하기 때문에 (어떤 솔루션은 유닉스가 지배적이었던 반면, 다른 솔루션은 채택률이 낮은 새로운 기술) 어떤 기술을 포함해야 할지 결정하는 데 어려움을 겪을 수 있습니다. 모든 구성 요소가 어떻게 조화롭게 작동하여 특정 문제를 해결하는지 이해해야 합니다. 설명서가 제공되지만, 이러한 서비스를 제공하고 관리하는 방법을 숙지해야 합니다.
기능 및 프로젝트 구별 – 프로젝트와 기능의 차이점을 파악하기 어려울 수 있습니다. 프로젝트 관리에 대한 조언은 쉽게 얻을 수 있지만, 기능과 커뮤니티 프로젝트를 명확하게 구분하기 어려울 수 있습니다.
Kubernetes를 넘어선 지식 – Kubernetes는 복잡한 플랫폼입니다. 이러한 복잡성으로 인해 특히 처음 사용하는 사용자들은 혼란스러울 수 있습니다. 조직은 서비스로서의 데이터 저장소와 같이 학습 곡선을 더욱 가파르게 만드는 솔루션을 원할 수 있습니다. 제품에서 이러한 서비스를 사용할 경우, Kubernetes를 넘어 지식을 확장해야 합니다.
Kubernetes 관리는 어려움 – K8s를 사용하여 프로덕션 환경에 진입하는 것은 시작에 불과합니다. 이를 관리하려면 애플리케이션에 필요한 모든 리소스를 제공해야 합니다. 또한 모든 보안을 처리하고 인프라와 통합해야 합니다. 또한 도구를 효과적으로 다루고 운영하려면 높은 수준의 전문성이 필요합니다. Kubernetes 클러스터를 관리하고 모니터링 및 문제 해결하고, 대규모로 지원하려면 심오한 지식이 필요합니다.

ECS와 쿠버네티스 비교

다음은 두 플랫폼의 차이점을 보여주는 표입니다.

차이점	Kubernetes	Amazon ECS
애플리케이션 정의	애플리케이션은 포드, 노드, 서비스를 결합하여 배포됩니다.	애플리케이션 배포는 작업의 형태를 취합니다. 작업은 컨테이너 인스턴스입니다. 예: ECS 인스턴스에서 실행되는 Docker 컨테이너.
배포	클러스터를 수동으로 배포하고 구성해야 하므로 배포가 복잡합니다.	AWS 콘솔을 통한 손쉬운 배포
노드 지원(머신 수)	클러스터당 5000노드.	컨테이너 클러스터당 최대 300,000개의 컨테이너. 활용된 인프라 용량으로 제한됨.
로드 밸런싱	포드는 인그레스 컨트롤러 뒤에서 로드 밸런서로 사용되는 서비스를 통해 노출됩니다.	2개의 로드 밸런서 사용 가능; ELB-Application 또는 Network.
가격	무료.	ECS는 무료이지만 EC2 리소스에 대해 비용을 지불해야 합니다.
최적화	단일 대형 클러스터에 최적화됨.	요구 사항 및 컨테이너 요구 사항으로 사전 구성됨.
자동 확장	배포를 구축할 때 자동 확장 매개변수를 정의합니다.	CloudWatch와 같은 모니터링 서비스를 사용합니다. CPU, 메모리 및 사용자 지정 매개 변수를 기반으로 자동 확장합니다.
상태 확인	두 가지 상태 확인(준비 상태 및 활성 상태)을 사용할 수 있습니다.	CloudWatch와 같은 모니터링 서비스를 통해 획득합니다.
서비스 검색	환경 변수 또는 DNS를 통해 구현합니다.	모니터링 서비스인 CloudWatch를 통해 획득합니다.
벤더 종속	아니요.	예.

ECS 및 Kubernetes 사용 사례

ECS 및 Kubernetes 컨테이너화 기술이 산업을 혁신하는 몇 가지 사례입니다.

ECS INC International은 ECS 기술이 구현된 다양한 사용 사례를 강조합니다. 현대 의료 기기에서는 환자를 치료하는 혁신적인 방법과 약물 전달 기술을 찾아볼 수 있습니다. 전자 흡입기, 의료용 자동 주사기, 주입 펌프 등 여러 도구가 존재합니다.

IoT 분야에는 스마트 홈 장치가 있습니다. 자동차 산업에서는 운전 경험을 향상시키고 보조 제동 시스템과 같은 안전 조치를 개선한 스마트 전기 자동차를 예로 들 수 있습니다.

이것은 빙산의 일각에 불과합니다. 무선 기술, 웨어러블 장치, 산업용 응용 등 ECS의 더 많은 응용 사례를 확인할 수 있습니다.

반면 Kubernetes는 실용적인 다양한 응용 사례를 제공합니다. 예를 들어 IBM 클라우드는 광범위한 런타임에서 프라이빗, 퍼블릭 및 하이브리드 기능을 제공합니다.

음악 스트리밍 분야의 거대 기업인 Spotify는 Kubernetes 기술을 활용하여 초당 최대 1,000만 건의 요청을 처리하고 원활한 운영을 가능하게 합니다. 이것은 하나의 사례일 뿐이며, K8s는 마이크로서비스 아키텍처, 클라우드 네이티브 네트워크 기능, 기계 학습, 소프트웨어 개발 수명 주기 등 여러 분야에서 더 많은 기능을 제공합니다.

결론

이 가이드를 통해 ECS 또는 K8s를 선택할 때의 장단점에 대한 명확한 이해를 얻으셨을 것입니다. 올바른 옵션을 선택하는 것은 몇 가지 요소를 고려해야 합니다. 비용, 서비스 제한, 인력 비용 등을 종합적으로 고려하여 결정해야 합니다.

만약 무료 서비스를 선호한다면 K8s가 최고의 선택일 것입니다. 하지만 그에 따른 복잡성을 해결하기 위해서는 뛰어난 기술과 인력이 필요합니다. K8s는 공급업체 종속에 대한 제약이 없지만, 플랫폼 작동 방식에 대한 깊이 있는 이해가 필요합니다. 반면에 ECS는 설정이 더 빠릅니다.

추가 정보: Kubernetes와 Docker에 대한 자세한 가이드