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

by

컨테이너화된 애플리케이션을 실행할 때 IT(정보 기술) 팀에 다양한 선택 사항이 제시되어 모든 수준의 기술 전문 지식을 처리합니다.

선택을 한 후에는 곧 다른 옵션으로 마이그레이션하지 않을 것이라는 점을 고려하면 하나를 선택하기 어려울 수 있습니다.

이 게시물은 Amazon Elastic Container Service(ECS)와 Kubernetes라는 두 가지 중요한 옵션을 대조합니다.

둘 다 컨테이너 오케스트레이션 및 마이크로서비스 관리 도메인에서 유능한 플랫폼입니다. 더 나아가기 직전에 컨테이너에 대한 리프레셔는 해를 끼치지 않습니다. 컨테이너는 많은 환경에서 코드 개발, 승격 및 배포를 쉽게 하기 위해 대중화되었습니다. 필요한 종속성, 라이브러리 및 환경 설정이 포함된 코드를 실행 가능한 패키지로 래핑하는 애플리케이션 계층의 추상화입니다.

컨테이너 사용의 주요 목표는 코드 배포 프로세스를 단순화하는 것이지만 수천 개의 컨테이너를 관리하는 것은 점점 더 어려워지고 있습니다. 매우 안정적인 배포를 구현하고, 부하에 따라 응용 프로그램을 확장하고, 비정상 컨테이너를 새 컨테이너로 교체하고, 부하를 분산하고, 포트를 노출하려면 또 다른 메커니즘이 필요합니다.

컨테이너 오케스트레이션이 도움이 되는 곳입니다. 그 외에도 컨테이너를 실행하고 전체 인프라를 관리할 수단이 필요합니다. 이 문제를 해결하기 위해 많은 도구를 사용할 수 있지만 초점을 몇 가지로 좁혀 보겠습니다.

이 기사에서는 ECS와 Kubernetes를 비교하여 각각의 이점을 강조하고 프로젝트에 따라 올바른 것을 선택하는 방향으로 결론을 내립니다.

Amazon ECS란 무엇입니까?

Amazon ECS는 컨테이너화된 애플리케이션의 배포, 관리 및 확장을 간소화하는 컨테이너 오케스트레이션 서비스입니다. 기본적으로 애플리케이션과 필요한 리소스를 정의합니다. 그런 다음 Amazon ECS는 필요한 다른 AWS 서비스의 통합을 허용하면서 컴퓨팅 옵션 전체에서 앱을 시작, 모니터링 및 확장합니다. 예를 들어 프로그래밍 방식으로 상태를 확인하고 클러스터를 수정할 수 있습니다.

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

또한 읽어보십시오. 어떤 AWS EC2 인스턴스를 사용해야 합니까?

아마존 ECS의 장점

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

    • ECS의 한계

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

    • 쿠버네티스란?

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

    K8s는 Google 프로덕션 워크로드를 실행한 15년의 경험(최고의 아이디어와 커뮤니티 관행 결합)을 활용하여 애플리케이션 컨테이너를 쉽게 찾고 관리할 수 있는 논리 단위로 그룹화합니다.

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

    또한 읽기: Kubernetes 시작하기: 초보자를 위한 소개

    쿠버네티스의 장점

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

    • 쿠버네티스의 한계

  • 가파른 학습 곡선 – Kubernetes를 시작하려면 해당 환경을 이해해야 합니다. 게다가 종단 간 솔루션을 제공하려면 다양한 기술과 서비스가 포함되어야 합니다. 그리고 보완 기술이 상당히 다양하기 때문에(때때로 일부 솔루션은 유닉스가 지배적이었던 반면 다른 솔루션은 채택률이 낮은 신기술임) 포함할 기술을 파악하는 데 정신이 없을 수 있습니다. 또한 특정 문제에 대한 보다 포괄적인 솔루션을 제공하기 위해 모든 구성 요소가 어떻게 함께 맞춰지는지 파악해야 합니다. 설명서를 사용할 수 있지만 이러한 서비스를 제공하고 관리하는 방법을 이해해야 합니다.
  • 기능 및 프로젝트 차별화 – 프로젝트와 기능의 차이점을 이해하는 것은 어려울 수 있습니다. 프로젝트 관리에 대한 조언을 쉽게 얻을 수 있지만 기능과 커뮤니티 프로젝트를 명확하게 구분하지 못할 수 있습니다.
  • Kubernetes를 넘어선 지식 – Kubernetes는 정교한 플랫폼입니다. 솔루션을 제공하는 데 있어 이러한 모든 복잡성으로 인해 특히 처음 사용하는 경우 약간의 혼란에 직면할 수 있습니다. 그러나 조직은 여전히 ​​학습 곡선을 증폭시키는 솔루션(예: 서비스로서의 데이터 저장소)을 제공하기를 원합니다. 제품에서 이러한 서비스를 사용하는 경우 Kubernetes를 넘어 지식을 확장해야 합니다.
  • Kubernetes 관리는 어렵습니다. K8s를 사용하여 생산에 들어가는 것은 한 가지입니다. 이를 관리하려면 애플리케이션에 필요한 모든 리소스를 제공해야 합니다. 또한 모든 보안을 처리하고 이를 인프라와 통합해야 합니다. 또한 도구를 효과적으로 처리하고 운영하려면 높은 수준의 전문 지식이 필요합니다. Kubernetes 클러스터를 관리하고, 클러스터를 모니터링 및 문제 해결하고, 대규모로 지원하려면 심오한 지식이 필요합니다.

    • ECS와 쿠버네티스 비교

    다음은 차이점을 보여주는 나란히 비교입니다.

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

    ECS 및 Kubernetes 사용 사례

    ECS 및 Kubernetes 컨테이너화 기술이 산업을 혁신하는 방법은 다음과 같습니다.

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

    IoT 도메인에는 스마트 홈 장치가 있습니다. 자동차 산업으로 관심을 돌리면 운전 경험이 향상되고 보조 제동 시스템과 같은 안전 조치가 개선된 스마트 전기 자동차가 있습니다.

    지금까지는 빙산의 일각입니다. 무선 기술, 웨어러블 장치 및 산업용 사용 사례에 국한되지 않는 ECS의 더 많은 응용 프로그램을 확인할 수 있습니다.

    반면 쿠버네티스는 실용적인 애플리케이션을 공유하고 있습니다. 첫째, IBM 클라우드는 광범위한 런타임에서 프라이빗, 퍼블릭 및 하이브리드 기능을 제공합니다.

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

    마지막 말

    이 가이드를 살펴보면 ECS 또는 K8을 선택할 때의 장점과 단점에 대한 확실한 개요를 갖게 됩니다. 올바른 옵션을 선택하는 열쇠는 몇 가지 인수를 기반으로 합니다. 비용, 서비스 제한 및 인재 비용 사이에서 무게를 달아야 합니다.

    무료 서비스를 이용하고 싶다면 K8s가 최고의 선택이 될 것입니다. 그러나 그에 수반되는 복잡성을 처리하려면 탄탄한 재능이나 기술이 필요합니다. K8에는 공급업체 종속 제한이 없지만 플랫폼 작동 방식에 대한 심층적인 이해가 필요합니다. 반면에 ECS는 구성이 빠릅니다.

    다음으로 Kubernetes와 Docker에 대한 자세한 가이드를 확인하세요.