컨테이너는 최근 몇 년간 의심할 여지없이 기술 업계의 화두가 되었습니다. 컨테이너화 기술의 등장과 부상, 그리고 이로부터 파생된 마이크로서비스 아키텍처, DevOps, 클라우드 네이티브 개념은 소프트웨어 산업에 큰 영향을 미쳤습니다.
컨테이너는 많은 장점을 제공합니다. 포괄적인 캡슐화, 편리한 배포, 가벼운 시작 및 스케줄링이 광범위한 채택에 기여했습니다. 오케스트레이션 시스템과 결합되면 컨테이너는 시스템 복잡성에 관계없이 애플리케이션 관리와 반복을 단순화합니다. 또한 컨테이너화된 애플리케이션은 뛰어난 이식성을 보여주며, 표준을 준수하는 컨테이너 런타임이 설치된 모든 환경에서 원활하게 실행됩니다.
가벼운 컨테이너와 탄력적 클라우드 컴퓨팅은 완벽하게 상호 보완됩니다. 다양한 운영 환경에 대한 컨테이너의 적응성과 빠른 시작 기능, 그리고 동적 클라우드 확장의 방대한 리소스 확장성이 결합되어 클라우드 기반 컨테이너화 애플리케이션은 짧은 시간 내에 수천 개의 인스턴스로 확장될 수 있습니다. 따라서 클라우드는 컨테이너화된 애플리케이션의 실행 및 확장에 이상적인 플랫폼입니다.
Docker가 널리 인정받기 전부터 클라우드 제공업체는 이미 컨테이너와 유사한 기술을 탐구하고 활용하고 있었습니다. 클라우드의 멀티 테넌트 특성상 환경 격리가 필요하기 때문에 클라우드 제공업체는 컨테이너화의 사용자이자 수혜자였습니다. 일부 업체는 자체 솔루션을 선택했으며, 모든 업체가 직접 Docker를 채택한 것은 아닙니다.
예를 들어, AWS Elastic Beanstalk은 웹 애플리케이션을 격리하기 위해 비공개 컨테이너와 유사한 기술을 사용했습니다. 이후 Docker 컨테이너로 패키징된 애플리케이션에 대한 지원을 확장했습니다.
Docker의 부상과 함께 주요 퍼블릭 클라우드 제공업체는 만장일치로 표준화된 컨테이너 관련 PaaS 서비스를 제공하기 시작했고, 이를 지속적으로 개선했습니다. 컨테이너 PaaS의 진화를 추적해 보면 뚜렷한 발전 단계가 드러납니다.
초기 클라우드 컨테이너 플랫폼은 클라우드에서 Docker 컨테이너를 원활하게 실행하는 데 중점을 두었습니다. 이러한 서비스는 주로 사용자가 기본 가상 머신 클러스터를 생성하고 수동 가상 머신 관리의 부담을 덜어주는 데 도움을 주기 위한 것이었습니다. 그러나 컨테이너화된 애플리케이션이 더욱 복잡해짐에 따라 오케스트레이션이 시급한 필요로 대두되었습니다. 이에 따라 공급업체는 자체 컨테이너 오케스트레이션 솔루션을 도입하고 강화했습니다.
오케스트레이션 프레임워크가 경쟁하던 시대에 일부 공급업체는 다양한 접근 방식을 채택했습니다. 예를 들어, Microsoft의 Azure Container Service는 Docker Swarm, Apache Mesos (DC/OS), Kubernetes를 지원했습니다. AWS는 Elastic Container Service (ECS)로 자체 오케스트레이션 방식을 채택하여 기존 클라우드 서비스와의 통합을 강화했습니다.
우리가 알고 있듯이, Kubernetes는 오케스트레이션 프레임워크 전쟁에서 승리하여 사실상의 표준이 되었습니다. 클라우드 제공업체는 빠르게 방향을 전환하여 클라우드에서 Kubernetes 지원을 최우선으로 하고 AWS Elastic Kubernetes Service (EKS) 및 Azure Kubernetes Service (AKS)와 같은 Kubernetes 전용 서비스를 출시했습니다. 마찬가지로 알리바바 클라우드는 컨테이너 서비스에서 Swarm 지원을 단계적으로 중단하고 Kubernetes 에디션 (ACK)에 집중했습니다.
클라우드의 컨테이너 기술 지원은 컨테이너 생태계와 함께 진화해 왔으며, 클라우드 제공업체는 참여자이자 지원자로서 중요한 역할을 수행했습니다. 예를 들어, Google Cloud의 Google Kubernetes Engine (GKE)은 생태계 내에서 “태어나고 자란” 존재로서 클라우드 기반 Kubernetes 서비스의 기준을 지속적으로 설정해 왔습니다.
클라우드 기반 Kubernetes 서비스는 자체 호스팅 Kubernetes 클러스터에 비해 몇 가지 뚜렷한 장점을 제공합니다.
첫째, 클라우드의 멀티 테넌트 특성으로 인해 많은 클라우드 기반 Kubernetes 서비스는 Master 노드를 프로비저닝할 필요가 없습니다. 사용자는 Worker 노드만 생성하고 비용을 지불하면 되며, 클라우드 플랫폼이 Master 노드를 제공하고 관리하므로 리소스 소비와 운영 비용이 절감됩니다.
둘째, Kubernetes는 복잡함에도 불구하고 뛰어난 추상화 설계를 갖추고 있어 광범위하고 유연한 확장이 가능합니다. 클라우드 제공업체는 이 분야에 많은 투자를 해 왔으며, 플랫폼의 다양한 IaaS 및 PaaS 구성 요소가 Kubernetes 생태계와 원활하게 통합되어 더 긴밀한 통합을 가능하게 합니다.
예를 들어, 외부 트래픽을 라우팅하는 데 일반적으로 사용되는 Ingress Controller 영역에는 AWS ALB Ingress Controller 및 Azure AKS Application Gateway Ingress Controller와 같은 클라우드 기반 로드 밸런서 컨트롤러 구현이 있습니다. 이러한 컨트롤러는 Kubernetes 클러스터를 제공하기 위해 해당 PaaS 서비스 인스턴스를 생성합니다.
또한 Kubernetes에서 동적 스토리지 볼륨 할당 정책을 정의하는 StorageClass 수준에서는 클라우드 기반 블록 스토리지 서비스를 사용하여 필요에 따라 영구 스토리지를 프로비저닝하고 마운트하도록 지정할 수 있습니다.
아키텍처적 유연성 측면에서 클라우드 기반 Kubernetes 서비스는 또 다른 이점인 멀티 클러스터 배포를 제공합니다.
Kubernetes 클러스터 구축의 진입 장벽이 낮아짐에 따라, 비즈니스 단위 간 상호 의존성이 거의 없다면 각 단위별로 별도의 Kubernetes 클러스터를 생성할 수 있습니다. 이 접근 방식은 격리를 강화하고 서로 다른 클러스터를 독립적으로 확장할 수 있게 합니다.
Docker에서 Kubernetes로의 컨테이너 생태계의 지속적인 진화는 클라우드 네이티브 기술의 물결을 불러일으켰습니다. 개발자는 컨테이너 기술을 학습하고 채택하는 데 혼자가 아닙니다. 클라우드 컴퓨팅 공급업체도 컨테이너 실행을 위한 최적의 플랫폼으로 자리매김하기 위해 경쟁하며, 컨테이너 사용자를 자사 클라우드로 유인하기 위해 수많은 컨테이너 관련 서비스를 도입하고 있습니다.
흥미롭게도, 컨테이너와 공급업체가 적극적으로 홍보하는 특정 클라우드 서비스 사이에는 미묘한 관계가 존재합니다. 경쟁과 대체 요소가 작용합니다.
일부 PaaS 기능이 IaaS를 사용하여 복제될 수 있는 것과 유사하게, 컨테이너는 뛰어난 빌드 자유도와 편리한 패키징 및 배포 메커니즘을 통해 클라우드 내의 특정 재사용 가능 구성 요소를 부분적으로 대체할 수 있습니다. 더욱이 컨테이너는 대규모 시스템의 일부로 오케스트레이션될 수 있으며, 벤더 종속을 완화하는 수단으로도 작용할 수 있습니다.
컨테이너가 특정 클라우드 서비스에 잠재적 위협이 될 수 있음에도 불구하고, 클라우드 컴퓨팅은 다시 한 번 기술적 중립성을 입증했습니다. 클라우드 플랫폼은 컨테이너 실행을 공개적으로 포용하고 지원했으며, 이를 주요 개발 서비스로 지정하기까지 했습니다. 사용자에게 선택권을 부여하는 것은 클라우드의 포용성을 보여줍니다.
Novita AI 는 AI 야망을 실현하는 올인원 클라우드 플랫폼입니다. 통합 API, 서버리스, GPU 인스턴스 등 비용 효율적인 도구를 제공합니다. 인프라를 없애고 무료로 시작하여 AI 비전을 현실로 만드세요.
추천 자료:
