[아이티데일리] 클라우드 컴퓨팅 기술은 2012~13년 국내에 처음 소개됐다. 2014년에 접어들자 많은 기업 및 조직에서 클라우드에 관심을 가졌고, 시장도 형성되기 시작했다. ‘클라우드 1기’로 구분할 수 있는 이 시기에는 서비스형 인프라(IaaS) 기반의 퍼블릭 클라우드가 핵심이었다. 그렇다면 ‘클라우드 2기’로 부를 수 있는 차세대 클라우드 트렌드는 무엇일까. 바로 클라우드 네이티브로, 그 핵심에는 쿠버네티스(Kubernetes)가 있다. 실제 2020년에 들어 클라우드 네이티브를 구현할 수 있는 핵심 기술로 컨테이너(Container) 관리 플랫폼인 쿠버네티스가 자리를 잡았고, 적용 사례도 확대되기 시작했다. 차세대 클라우드 혁신의 필수 요소로 꼽히는 쿠버네티스의 개념과 기술 및 시장 동향을 짚어본다.

서비스 DR 환경 구축에 적합

쿠버네티스 플랫폼은 많은 이점을 제공한다. 특히 최근 화두로 떠오른 서비스 재해복구(DR) 체계를 마련하는 것에도 장점을 갖고 있다. 쿠버네티스는 베어메탈, 가상머신(VM), 클라우드 환경 등 다양한 환경에서 컨테이너를 이동할 수 있는 이식성, 수요에 따라 자동으로 스케일을 확장하고, 축소할 수 있는 유연성 등을 갖추고 있다. 이러한 이점을 토대로 IT 재해로부터 비즈니스 애플리케이션을 신속하게 복구할 수 있는 플랫폼으로 꼽히고 있다.

물론 기업에서 제공하는 쿠버네티스 솔루션이나 도입 기업의 IT 환경별로 다른 DR 체계를 구현하지만, 공통적으로는 쿠버네티스가 서비스 DR에 강점을 갖고 있다.

쿠버네티스가 서비스 DR에 강점을 갖는 이유는 서버를 클러스터로 묶는 ‘클러스터링(Clustering)’ 기능 때문이다. 보통 쿠버네티스는 서버들을 군집 단위인 클러스터로 묶어 구성한다. 고객마다 구성할 수 있는 클러스터의 용량은 다르지만, 클러스터링 방식은 모두 동일하다. 레드햇의 경우 쿠버네티스 클러스터를 최대 서버 255개까지 묶어 구성하고 있다. VM웨어, 맨텍, 나무기술, 인프라닉스 등 모두 클러스터링을 통해 쿠버네티스를 구축하고 있다.

쿠버네티스 클러스터는 컨테이너를 생성, 배포, 운영, 관리할 수 있는 전체 자원 용량의 총량과 같다. 이는 클러스터를 이루고 있는 서버들의 개수가 많으면 많을수록 컨테이너의 확장성도 늘어난다는 의미다. 또한 클러스터를 구성할 때 프라이빗 클라우드, 퍼블릭 클라우드 IaaS, IDC에 위치한 서버 등을 모두 네트워크로 연결할 수 있다. IDC에서 재해가 발생하면 쿠버네티스가 IDC에서 구동되는 컨테이너들을 IaaS 혹은 프라이빗 클라우드로 자동으로 옮겨 서비스 연속성을 유지할 수 있다.

이와 관련, 레드햇 김종규 상무는 “쿠버네티스 클러스터 구성 방식은 과거 서버 DR과 개념이 비슷하다. 다만 복합적인 클라우드 환경을 쿠버네티스라는 동일한 플랫폼으로 통로를 구성하고 이를 연결해 자원의 유동성을 확보했다는 점에서 차이가 있다”면서, “SK(주) C&C의 IDC 화재 사고와 같이 단일 IDC 클러스터로 구성돼 있는 경우 빠른 서비스 복구를 위해선 쿠버네티스 클러스터 DR을 별도로 구축하는 방향도 고려해야 한다”고 조언했다.

인프라닉스 권영진 상무 역시 “쿠버네티스는 아키텍처 상 DR, 로드밸런싱, 스케일링이 기본적으로 포함돼있다. 고객들이 굳이 DR 구축을 고려하지 않아도 자동으로 구현된다. 인프라닉스는 고객들이 원할 경우 KT클라우드, 네이버클라우드, 아마존웹서비스(AWS) 등 API 개방 요청을 한 후 퍼블릭 클라우드 VM을 만들어 클러스터를 구축하고 있다”고 설명했다.

쿠버네티스는 서비스 재해복구 외에도 운영센터와 DR센터 간 변경 관리가 용이하며, 서비스 복원 속도도 빠르다는 장점이 있다.

먼저 일반적인 데이터 동기화 및 복구는 백업, 실시간 복제, 복구 자동화 솔루션들의 기능이 고도화되면서 별다른 문제 없이 진행된다. 하지만 문제는 애플리케이션이 운영되는 운영센터의 변경사항이 DR 센터에 바로 적용되지 않고 차이가 존재한다는 점이다.

맨텍 이진현 OM사업본부장은 “일반적으로 운영 환경에서 발생하는 애플리케이션 업그레이드, OS 변경, 인프라 환경 변경 등에 대한 변경 사항이 DR 센터에도 동일하게 적용되지 않는 경우가 많다. 시간이 지나면 운영과 DR 센터 간 차이가 존재하고 문제 발생시 DR 센터에서 애플리케이션을 운영하더라도 서비스 가동에 실패하는 경우가 있다. 물론 정기적인 모의훈련을 통해 이러한 차이를 찾고, 변경 사항들을 수작업으로 업데이트해 변경 관리를 진행할 수도 있기는 하다”면서, “그러나 현대의 IT 환경은 매우 복잡하고 수시로 변화하기에 변경 관리가 특히 어렵다. 쿠버네티스 환경에서 운영 센터와 DR 센터가 운영될 경우 컨테이너화 된 애플리케이션의 저장소를 운영 센터에서 DR 센터로 복제함으로써 상시 변경 및 신규 배포된 앱과 환경 변수들을 실시간으로 동기화할 수 있다. 또한 하이퍼바이저나 호스트 OS의 버전이 다르더라도 컨테이너 기동이 가능하며, 퍼블릭 클라우드도 DR로 활용할 수 있어 저렴한 비용으로 자동화된 DR을 구축할 수 있다”고 설명했다.

쿠버네티스는 서비스를 복구하는 속도도 빠르다. 쿠버네티스 솔루션에는 클러스터 내부에서 컨테이너가 잘 구동되는지, 애플리케이션 운영에는 문제가 없는지 계속 확인하는 서비스 디스커버리(Service Discovery) 기능과 로깅·모니터링(Logging·Monitoring) 기능이 있다. 이들 기능으로 서비스에 장애가 발생해도 신속하게 복구할 수 있다.

예를 들어 하나의 애플리케이션을 운영하기 위해 3개의 컨테이너를 구동하고 있다고 가정해보자. ‘Kubelet’이 쿠버네티스 마스터(Kubernetes Master)로 1개의 컨테이너가 문제 있다는 통신을 보내면 쿠버네티스 마스터에서는 서비스 연속성을 유지하기 위해 다른 컨테이너 1개를 추가하라는 명령을 API 서버에 내리고 컨테이너를 생성한다. 이후 남은 2개의 컨테이너와 추가한 1개의 컨테이너를 파드(Pod) 단위로 묶어 애플리케이션 운영을 유지한다.

쿠버네티스는 클러스터 전체를 관리하는 쿠버네티스 마스터와 컨테이너가 배포되는 가상 또는 물리머신인 워커노드(Worker Node)로 구성된다. 쿠버네티스 마스터는 ‘Kubectl’라는 커맨드 인터페이스를 통해 세팅되며 API 서버, 스케줄러, 컨트롤러 매니저, ETCD로 구성된다. API 서버는 유저로부터의 요청 및 마스터와 워커노드 간의 통신을, ‘Kubelet’은 쿠버네티스 마스터의 API 서버와 통신을 담당하며 수행 명령을 받거나 노드의 상태를 쿠버네티스 마스터로 전달하는 역할을 한다. ‘Kube-proxy’는 노드에 들어오는 네트워크 트래픽을 포드 내의 컨테이너에게 라우팅하고 노드와 쿠버네티스 마스터 간의 네트워크 통신을 관리하는 역할을 한다.

쿠버네티스에 의해서 배포 및 관리되는 컨테이너들은 ‘포드(Pod)’라는 단위로 묶인다. 포드는 하나 이상의 컨테이너를 포함하며, 같은 포드에 속해있는 컨테이너들은 서로 로컬 통신이 가능하고 디스크 자원도 공유할 수 있다.

VM웨어 ‘VM웨어 탄주’

VM웨어의 ‘VM웨어 탄주 애플리케이션 플랫폼(Tanzu Application Platform)’은 멀티 클러스터에 걸친 앱 배포 및 가시성 문제를 해결해 고객이 앱 개발 및 배포 시간을 단축하고, 쿠버네티스를 비롯한 기존 개발자 툴과 자산을 보호할 수 있는 기능을 제공한다. 아울러 멀티 클라우드 환경에서 쿠버네티스 워크로드에 대한 가시성을 높여 워크로드와 환경에 대한 통찰력을 얻을 수 있도록 ‘VM웨어 탄주 포 쿠버네티스 오퍼레이션(Tanzu for Kubernetes Operations)’도 제공하고 있다. 이 서비스는 기업이 클라우드 전반에 걸쳐 쿠버네티스 클러스터를 관리, 보안 및 모니터링하도록 지원하며 컨테이너 배치 및 관리에 대한 단순하고 일관된 접근 방식을 제공한다.

쿠버네티스 솔루션 연합 활발, 고객 확보 ‘총력’

쿠버네티스가 컨테이너 관리 오픈소스의 표준으로, 클라우드 네이티브의 핵심으로 자리매김하자 이 시장을 두고 업체간 경쟁도 뜨겁다. 쿠버네티스 솔루션을 공급하는 방식은 크게 프라이빗 클라우드 형태와 퍼블릭 클라우드 형태로 나뉜다.

국내에서 프라이빗 클라우드 형태로 쿠버네티스 플랫폼을 제공하는 기업은 레드햇(레드햇 오픈시프트, Redhat OpenShift), VM웨어(VM웨어 탄주, Vmware Tanzu), 맨텍(아코디언, Accordion), 나무기술(칵테일 클라우드, Cocktail Cloud), 인프라닉스(시스마스터 K8s, Sysmaster k8s), 투라인코드(냅, NAPP), 티맥스클라우드(하이퍼클라우드, Hypercloud) 등이다.

퍼블릭 클라우드 형태로 쿠버네티스 플랫폼을 제공하는 기업은 대부분 클라우드 서비스 제공사(CSP)다. AWS는 ‘아마존 엘라스틱 컨테이너 레지스트리’, ‘아마존 엘리스틱 컨테이너 서비스’, ‘아마존 ECS 애니웨어’, ‘아마존 엘리스틱 쿠버네티스 서비스’, ‘아마존 EKS 애니웨어’, ‘아마존 EKS 디스트로’, ‘AWS 프로톤’ 등을 제공하고 있다. MS 애저의 경우 ‘애저 쿠버네티스 서비스’, ‘애저 레드햇 오픈시프트’, ‘애저 펑션’, ‘애저 API 매니지먼트’, ‘애저 코스모스 DB’, ‘애저 컨테이너 레지스트리’ 등이다.

국내 CSP로서는 네이버클라우드가 ‘컨테이너 서비스’와 ‘쿠버네티스 서비스’와 ‘컨테이너 레지스트리’ 등의 서비스를 제공하고 있다. NHN클라우드는 ‘토스트 쿠버네티스’라는 컨테이너 관리 서비스를 제공하고 있다.

이 시장을 공략하기 위해 △프라이빗 쿠버네티스 솔루션 기업과 퍼블릭 쿠버네티스 솔루션 기업 △프라이빗 쿠버네티스 솔루션 기업 간 △프라이빗 쿠버네티스 솔루션 기업과 HW 기업 간 연합 등이 이루어지고 있다.

먼저 프라이빗 쿠버네티스 솔루션 기업과 퍼블릭 쿠버네티스 솔루션 기업의 연합으로는 레드햇-AWS, 레드햇-MS, VM웨어-AWS, VM웨어-MS애저, VM웨어-오라클 클라우드, 맨텍-AWS, 맨텍-MS, 맨텍-네이버클라우드 등을 들 수 있다. 이들은 주로 프라이빗 쿠버네티스 솔루션을 퍼블릭 클라우드의 쿠버네티스 솔루션 및 IaaS, SaaS와 연동해 멀티·하이브리드 클라우드 관리에 역점을 두고 있다.

프라이빗 쿠버네티스 솔루션 기업 간의 연합으로는 레드햇-나무기술, 레드햇-이노그리드, 맨텍-VM웨어 등을 들 수 있다. 협업 방식은 한 기업의 쿠버네티스 엔진 위에 포털, 서드파티 솔루션을 결합해 제공하는 형태다.

마지막으로 뉴타닉스-레드햇, 뉴타닉스-맨텍, 뉴타닉스-나무기술, 델 테크놀로지스-VM웨어, HPE-맨텍 등은 프라이빗 쿠버네티스 솔루션사와 HW 기업 간의 연합이다. 이들은 하이퍼컨버지드 인프라(HCI) 형태의 어플라이언스로 쿠버네티스 솔루션과 HW 장비를 묶어 고객에게 제안하고 있다.

이 같은 연합은 장단점이 있다. 장점으로는 솔루션 간 상호 부족한 부분을 보완할 수 있다는 점이다. 그러나 오픈소스의 장점인 개방성이 무력화되고 벤더 종속성을 벗어나기 어렵다는 단점이 있다.

이러한 장·단점에도 불구하고 이기종 쿠버네티스 간 통합 관리와 자원 효율성을 확보하고 시장을 선점하기 위한 솔루션 벤더 간 합종연횡은 더욱 가속화될 것으로 예상된다.

나무기술 ‘칵테일 클라우드’

나무기술의 ‘칵테일 클라우드(Cocktail Cloud)’는 쿠버네티스 기반의 MSA, AI·ML 파이프라인, 빅데이터 등의 서비스를 구축하고, 관리할 수 있는 플랫폼이다. 높은 서비스 가용성, 확장성, 안정성과 데브옵스를 통한 민첩성과 효율성을 확보하고, 다양한 애플리케이션을 제공해 고객은 운영 비용과 시간을 줄일 수 있다. 특히 다중·형 쿠버네티스 멀티 클러스터 관리 기능과 조직별 멀티태넌시 기능을 통해 자원 관리 및 확장 요구에 빠르게 대응할 수 있으며, 하이브리드 클라우드에서 유연한 애플리케이션 적용과 최적화된 운영 환경을 구현할 수 있다. 이를 통해 기업 내 조직은 프로젝트 별로 자유롭게 컨테이너를 구축해 독립된 개발 인프라를 제공할 수 있고, 관리자는 이들을 손쉽게 확인하고 관리할 수 있는 통합 모니터링 대시보드를 활용할 수 있다.