민첩한 클라우드 환경 구성 필수품 ‘컨테이너’ (2)
상태바
민첩한 클라우드 환경 구성 필수품 ‘컨테이너’ (2)
  • 윤현기 기자
  • 승인 2019.03.10 09:59
  • 댓글 0
이 기사를 공유합니다

다양한 컨테이너·관리 플랫폼 부상…시장 공략 위한 업계 움직임 ‘분주’

컨테이너는 보유하고 있는 여러 이점들로 인해 클라우드 환경에서 그 쓰임새가 점차 늘어나고 있다. 기업에서도 운영하는 클라우드가 늘어나면서, 매번 장비별로 컨테이너를 설정해주는 것이 어려운 일이 됐다. 가령 10개의 컨테이너만 있을 경우 담당자가 일일이 서비스를 올리고 내리고 하는 것이 가능하지만, 그 수가 100개, 200개로 늘어날 경우 사람의 통제 수준을 벗어나게 된다.

이에 중앙에서 여러 노드에 위치한 컨테이너들을 관리해주는 솔루션이 등장했다. 컨테이너 간 호출 등을 담당하는 오케스트레이션 기술이 적용된 것으로, 가장 유명한 것이 ‘쿠버네티스(Kubernetes)’다.

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해주며, 크고 빠르게 성장하는 생태계를 가지고 있다.

컨테이너 적용 전/후 비교
   
▲ 컨테이너 적용 전(왼쪽)과 후

컨테이너가 적용되기 이전의 환경에서는 소스코드를 Ant, Maven 등의 컴파일 수행 툴로 빌드를 수행하며, 그 결과물로 웹 애플리케이션을 배포하기 위한 ‘WAR’를 얻을 수 있다. 이후 클라우드 환경인지 또는 물리서버 환경인지 등을 고려해 해당 환경에 맞는 OS와 WAS를 설치 과정을 거쳐야 한다. 환경 분석과 앱 배포를 위해 L4 및 웹서버 등도 구성해야 하는데, 이러한 일련의 과정이 결코 빠르다고는 할 수 없는 속도로 진행된다.

그러나 컨테이너 기술이 적용되면 시작부터 방법이 달라진다. 단지 소스코드뿐만 아니라 애플리케이션이 올라가서 구동될 수 있는 WAS를 함께 필요로 하기 때문이다. 현재 가장 많이 사용되는 도커 컨테이너를 기준으로 보면 소스코드와 이를 의존하게 되는 WAS, 그리고 어떻게 이미지를 만들 것인지에 대한 작업 명령어들을 담고 있는 ‘도커 파일’을 함께 묶어 컨테이너 이미지 파일이 형성된다.

여기에는 애플리케이션 실행에 필요한 모든 구성 요소가 담겨있으며, 장비에 설치된 컨테이너 엔진만 있으면 해당 이미지를 당겨오는 것이 가능하다. WAS를 설치할 필요가 없으며, 컨테이너 이미지를 구동할 경우 프로세스 형태로 동작하게 된다. 다른 환경에 배포할 때도 단순히 이미지만 당겨와 실행만 시키면 되기 때문에 역시 별도의 WAS를 설치할 필요가 없다.

WAS를 설치하려면 WAS에 대해 잘 아는 인력이 필요하며, 애플리케이션 플랫폼에 대한 이해도가 높아야 구성이 가능하다. 다만 WAS를 설치하고 구성하는 과정이 힘들고 운영이 어려우며, 심지어는 인프라 엔지니어가 미들웨어까지 알고 있어야 하는 문제도 발생할 수 있다. 

쿠버네티스는 구글이 컨테이너 관리를 위해 개발한 시작한 프로젝트였으며, 지난 2014년에 오픈소스화함으로써 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있게 됐다. 쿠버네티스는 구글이 15여년에 걸친 대규모 운영 워크로드 운영 경험을 기반으로 만들어졌으며 커뮤니티의 최고 아이디어와 적용 사례가 결합된 것이 특징이다.

쿠버네티스는 모든 것이 포함된 PaaS가 아니며, 컨테이너 수준에서 운영되기 때문에 PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점이 있기도 하다. 모놀리식(monolithic)한 구조가 아니며, 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.

우선 쿠버네티스는 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(Stateless) 워크로드, 상태 유지가 필요한(Stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서 매우 잘 동작할 것이다.

또한 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합, 지속적인 배포(CI/CD) 워크플로우는 기술적인 요구사항은 물론 조직 문화와 취향에 따라 결정된다.

특히 쿠버네티스는 단순한 오케스트레이션 솔루션이 아니며, 오히려 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성돼 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

2~3년 전만 해도 다양한 컨테이너 오케스트레이션 기술이 시장에 존재했다. 그러나 현재는 대부분 쿠버네티스 기반으로 바뀌었으며, 경쟁사들도 쿠버네티스 기반 컨테이너 오케스트레이션 기술을 활용하기에 이르렀다. 최근 들어 많은 인기를 구사하면서 오픈스택보다 더 많은 관심을 받고 있기도 하다.

실제로 레드햇은 독자적인 컨테이너 기술을 보유하고 있었으나 도커 컨테이너와 쿠버네티스 기술을 빠르게 받아들여 이를 제품에 녹여낸 ‘오픈시프트 3.0’을 출시했으며, 이후 아마존웹서비스(AWS), 마이크로소프트(MS), IBM 등 주요 클라우드 업체들도 하나둘씩 쿠버네티스를 공식 지원하게 되면서, 쿠버네티스는 사실상의 업계 표준 컨테이너 오케스트레이션 툴로 자리 잡게 됐다.

▲ 쿠버네티스 아키텍처

최신 기술인만큼 사용 어려워

현재 대부분의 고객들은 컨테이너와 쿠버네티스 기술을 활용해 애플리케이션 배포를 빠르게 할 수 있기를 기대하고 있다. 그 애플리케이션에는 클라우드 네이티브 애플리케이션부터 인공지능(AI)&머신러닝(ML), 블록체인, 사물인터넷(IoT)에 이르기까지 종류고 다양하다.

그러나 정작 기업에서 쿠버네티스를 제대로 사용하는 것은 어렵다. 오픈소스로 돼 있기에 설치부터 배포, 미터링, 알람 기능 설정, OS 패치 및 업그레이드, 컨테이너 플랫폼 등을 스스로 해야 하기 때문이다. 물론 기술력이 있다면 충분히 할 수 있는 부분들이지만, 기업 사용자 75% 이상이 어려움을 호소한다. 물론 실제로 어려울 수밖에 없다. 아직까지 다뤄본 이들이 많지 않은 최신 기술이기 때문이다.

조금만 시간을 거슬러 올라가보자. 1990년대 말~2000년대 초반에 WAS가 국내 시장에 들어왔다. 당시에는 WAS에 대해 아무도 몰랐다. 새로운 기술이었기에 어쩔 수 없는 부분이었다. 마찬가지로 VM을 처음 접했을 때 누구나 잘 사용할 수 있었던가? 현재는 가상화 기술을 내재화한 기업들이 늘어났기에 활용도가 늘어난 것이다.

가령 독자적으로 쿠버네티스를 구축하고 활용한다 할지라도 기술 내재화가 돼 있지 않으면 언제든 문제에 처할 수 있다. 실제로 쿠버네티스를 사용하다 보안 침해가 발생한 사례도 있었다. 이처럼 보안 침해를 받게 되면 예기치 않은 비용이 발생하거나 이를 처리하기 위해 많은 시간을 할애하게 된다. 기술 내재화가 돼 있지 않으면 직접 오픈소스를 다루기보다 벤더가 제공하는 안정적인 컨테이너 플랫폼을 사용하는 것이 더 좋은 선택이 될 수 있다.

“축적된 기술력으로 완성도 높은 기업용 컨테이너 플랫폼 제공”
   
▲ 김현수 한국레드햇 이사

불과 몇 년 전만 하더라도 벤더들은 저마다 독자적인 기술을 활용한 컨테이너 오케스트레이션 관리 솔루션을 제공했다. 그때는 아직까지 컨테이너 관련 표준화된 기술이 없었으며, 가장 많이 사용되는 기술이 표준으로 자리 잡게 될 것이라는 기대가 있었다. 레드햇도 독점 기술 기반의 기업용 컨테이너 플랫폼인 ‘오픈시프트’를 시장에서 경쟁하고 있었다.

구글이 쿠버네티스를 오픈소스화한 이후 레드햇은 독점 기술을 버리고 도커와 쿠버네티스를 기반으로 한 새로운 ‘오픈시프트 3.0’을 출시했다. 당시 경쟁사들은 레드햇이 기존 기술을 버리고 새로운 기술을 도입했기에 고객들이 기술지원에 대한 어려움을 겪을 것이라 예상했었지만, 사실과는 거리가 있었다. 오히려 그들은 뒤늦게 자사 클라우드 환경에서 쿠버네티스 환경을 지원함으로써 레드햇보다 쿠버네티스 관련 기술력이 뒤처질 수밖에 없는 문제점을 안게 됐다.

레드햇은 쿠버네티스 프로젝트에서 구글 다음으로 많은 기여를 하면서 기술력을 축적했으며, 기술지원을 위한 핵심 엔지니어들도 다수 보유하고 있다. 그뿐만 아니라 레드햇의 플랫폼은 타사와 달리 물리서버, VM, 클라우드를 가리지 않고 다양한 환경에서 이용 가능해 하이브리드 클라우드 시장에서 우위를 점할 수 있게 됐다. 

관련 시장 공략 위한 업계 경쟁 촉발

앞서 언급한 바 있듯이 컨테이너는 클라우드 환경에 꼭 필요한 기술이 됐으며, 이를 위해 쿠버네티스와 같은 오케스트레이션 툴의 사용이 권장된다. 이에 업계에서는 관련 시장 공략을 위해 다양한 컨테이너 플랫폼 및 관리 플랫폼을 출시하고 있다.

컨테이너 가상화 기술 및 쿠버네티스에 대한 기업들의 관심이 높아지면서, VM웨어는 컨테이너 및 쿠버네티스 관련 분야에 지속 투자를 이어가고 있다. 2016년 가상화 플랫폼 ‘v스피어(vSphere)’에 주요 컨테이너 기술을 적용할 수 있는 ‘v스피어 통합 컨테이너(vSphere Integrated Containers)’에 이어 2017년 피보탈(Pivotal), 구글 등과의 협업으로 엔터프라이즈 환경에 최적화된 쿠버네티스 배포판 ‘VM웨어 PKS’를 선보였다. 또 2018년, 클라우드 서비스 영역에서 제공되는 ‘VM웨어 클라우드 PKS’를 공개했으며, 하이브리드 클라우드 구현을 지원하는 통합 플랫폼 VM웨어 클라우드 파운데이션(VCF) 3.5 업데이트에서 VM웨어 NSX-T와의 통합으로 컨테이너형 애플리케이션 및 쿠버네티스를 지원한다고 밝혔다.

국내 기업들도 컨테이너 기술 개발에 한창이다. SK(주) C&C는 클라우드 컨테이너 서비스 ‘클라우드 제트 서비스 플랫폼(Cloud Z Service Platform)’을 출시했으며, 나무기술은 컨테이너 기반의 멀티 클라우드 관리 플랫폼 ‘칵테일’을 통해 국내외 시장 공략에 적극 나서고 있다. 티맥스오에스는 컨테이너 기반 가상화를 지원하는 클라우드 플랫폼 ‘프로존’을 선보이고 있다.



댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.