가상 클러스터로 쿠버네티스 비용 절감하기

v클러스터(vCluster)는 물리적 쿠버네티스 호스트 클러스터 내에 가벼운 가상 쿠버네티스 클러스터를 만들어 리소스 소비를 비약적으로 줄이고 민첩성과 통제력을 높여준다.
 
웹스케일 플레이북에서 나온 플랫폼 엔지니어링은 불과 몇 년 전까지만 해도 미래의 영역으로 간주됐다. 당시에는 플랫폼 엔지니어링이 일반 기업 팀까지 영향을 미칠지, 기업들이 대형 클라우드 제공업체처럼 인프라를 운영하고 싶어할지에 대한 의문이 있었지만, 이제는 가트너가 2026년까지 기업의 80%가 채택할 것이라고 전망할 만큼 보편화되고 있다.
 
플랫폼 엔지니어링은 사람마다 받아들이는 의미가 다르며 이를 정확히 수행하는 방법을 규정하는 기준 경로도 없다. 그러나 보편적으로 공감되는 주요 목표는 있다. 플랫폼 엔지니어링의 한 측면은 병목 지점을 없애고 셀프 서비스를 추가함으로써 개발자 속도를 높이는 데 주력하고, 다른 한편으로는 보안 및 규정 준수와 같은 중앙 제어를 표준화해서 비용과 복잡성을 억제하는 것을 목표로 한다.
 

 
개발자 속도 증대는 플랫폼 엔지니어링이 명확하게 성과를 거두고 있는 영역이다. 컨테이너, 마이크로서비스, 쿠버네티스, CI/CD, 그리고 현대 개발 워크플로우는 의심할 여지없이 분산된 팀의 소프트웨어 개발 속도와 생산성을 높이고 더 자동화된 환경으로 만들었다.
 
그러나 플랫폼 엔지니어링의 "중앙 제어" 부분은 아직 성공을 선언하기 쉽지 않다. 지금은 클라우드 운영 모델의 높은 비용과 복잡성에 대한 반발이 몇 년째 이어지는 중이다. 또한 클라우드 비용이 급등하고 기업은 비용 절감 방안을 찾기 위한 극심한 압박을 받는 만큼 오늘날 플랫폼 엔지니어링의 중앙 제어 측면은 단순히 플랫폼 엔지니어링 팀 문제가 아니라 CFO의 문제다. 클라우드와 쿠버네티스가 사라질 일은 없지만 망가진 중앙 제어 평면을 수정하는 것은 많은 기업이 현재 어려움을 겪고 있는, 수백만 달러 규모의 딜레마다.
 
이 같은 이유로 v클러스터라는 오픈소스 프로젝트가 중대한 돌파구의 순간을 맞이하고 있다. v클러스터는 쿠버네티스 운영 모델의 중심인 클러스터 추상화를 통해 쿠버네티스를 기반으로 하는 조직에 다양한 이점을 제공하는 것을 목표로 한다. v클러스터는 리소스 오버헤드를 대폭 줄여 상당한 비용 절감 효과를 이끌어낼 뿐만 아니라 플랫폼 엔지니어링 팀에 더 높은 민첩성과 더 강력한 중앙 제어 역량도 제공한다.
 

기회를 향한 오픈소스의 길

v클러스터의 공동 창안자이자 로프트 랩스(Loft Labs)의 공동 창업자 루카스 젠텔과 파비안 크램은 만하임 대학교 컴퓨터 과학 학생 시절에 만나 기술 분야에서 비슷한 길을 갔다. 자바에서 시작해 네오4j와 같은 그래프 데이터베이스, 그리고 PHP 및 자바스크립트와 같은 웹 중심 기술을 다루다가 이후 도커와 쿠버네티스가 등장하자 고가 미래라고 생각해 고 언어로 뛰어들었다. 젠텔은 졸업 전에 IT 컨설팅 사업을 시작했고 이 회사의 첫 직원이 크램이었다. 
 
이 IT 서비스 사업을 하면서 젠텔과 크램은 데브스페이스(DevSpace)라는 프로젝트를 만들어(쿠버네티스 워크플로우를 간소화하는 데 중점을 둔 도커 컴포즈(Docker Compose의 대안) 깃허브에 올렸다. 이렇게 오픈소스 프로젝트 개발과 유지관리를 처음으로 경험했다. 두 사람 모두 그 이전에도 여러 오픈소스 프로젝트에 기여하고 문제를 수정한 적이 있지만 프로젝트를 소유하거나 유지관리자로서 이끌었던 적은 없었다. 이들은 오픈소스를 배포하고 사람들이 사용하고 가치 있게 여기고 기여하는 오픈소스의 마법에 빠져들었다.
 
두 사람은 대학을 졸업한 후 PaaS 제품을 개발해서(젠텔에 의하면 "쿠버네티스의 헤로쿠와 같은 것"을 지향함) Y 콤비네이터(Y Combinator)에 지원했다가 거절당했지만 다시 지원하도록 초대를 받았고 이를 발판으로 U.C. 버클리의 스카이덱(SkyDeck) 액셀러레이터 프로그램에 참여했다. 최종적으로 둘은 PaaS가 매우 어려운 비즈니스라는 결론을 내렸다. 벽에 부딪힌 것은 이들이 처음이 아니다. 클라우드 파운드리, 헤로쿠, 그리고 도커를 만든 사람들조차 닷클라우드(dotCloud)의 수익화에 어려움을 겪고 있다.
 
젠텔은 "PaaS에 무료 사용자는 많지만 비용을 내고 사용할 만한 사람은 많지 않다는 것을 알게 됐다. 이 경험을 통해 우리는 대규모 쿠버네티스 클러스터를 실행하면서 이 클러스터를 사용자들과 공유하는 것은 매우 복잡한 작업이고 비용도 많이 든다는 점을 배웠다. 또한 PaaS보다 훨씬 더 기회가 큰, 훨씬 더 나은 방법이 있다는 것도 알게 됐다. 쿠버네티스 클러스터를 실행하는 누구에게나 유용할 만한 개념이었다”라고 말했다.
 

플릿은 잘못된 추상화

컨테이너 오케스트레이션의 초기 시장에서는 서비스를 "애완동물(각 서버를 개별적으로 관리)"이 아닌 "가축(교체 가능한 하드웨어)"으로 취급하는 것이 서버를 클러스터로 전환하는 데 있어 핵심 개념이라고 받아들였다.
 
몇 년 동안 소규모 클러스터의 플릿(fleet)과 하나의 대규모 클러스터를 두고 아키텍처에 대한 논쟁이 이어졌다. 젠텔은 "쿠버네티스 자체가 5노드 클러스터와 같은 환경이 아니라 대규모에서 실행되도록 설계됐다. 소규모 클러스터에서는 중복과 비효율성이 매우 커진다”라고 말했다.
 
그러나 주요 클라우드 제공업체들이 자체적인 쿠버네티스 상품을 출시하면서 소규모 단일 테넌트 클러스터와 여러 클러스터로 구성된 플릿이 기업 시장에 판매되는 추상화의 단위가 됐고, 여기에 "미니 클러스터의 클러스터" 방식으로 서비스의 동기화를 유지하고 모든 요소를 조율하기 위한 "플릿 관리" 솔루션이 가미됐다.
 
젠텔은 현재 과다한 클라우드 비용 문제의 상당부분은 클라우드 제공업체의 원죄에 기인한다고 지적했다.
 
플릿 접근 방식에 따른 첫 번째 결과는 무거운 인프라 구성요소에 대해 반복해서 비용을 지불해야 한다는 불이익이다. 플랫폼 팀은 이스티오(Istio), 오픈 폴리시 에이전트(Open Policy Agent)와 같은 핵심 서비스로 표준화하기를 원하는데, 이러한 서비스는 대규모 실행에 맞게 설계됐으므로 작은 규모로 많은 수를 실행하는 방식은 매우 비효율적이다. 플릿 접근 방식에서 이러한 서비스는 항상 각 클러스터에 설치되므로 전체 플랫폼 스택이 여러 소규모 클러스터에 걸쳐 복제되면서 핵심 서비스의 극심한 중복이 발생한다.
 
또 다른 중요한 결과는 이러한 클러스터가 항상 실행된다는 점이다. 아무도 끄지 않는다. 주요 클라우드 솔루션에는 버튼을 클릭해서 전체 클러스터를 끌 수 있는 손쉬운 방법이 없다. 모든 과정이 수작업이다. 정책을 마련해 적용해야 하며, 클러스터를 연결, 관리, 보호, 모니터링하는 데 사용되는 전체 플랫폼 서비스 스택을 가동하는 데 30분이 걸린다. 또한 모든 플랫폼 서비스(보안 구성요소, 정책 에이전트, 규정 준수, 백업, 모니터링, 로깅 등)가 계속 실행되는 상황에서는 어느 클러스터가 정말 "유휴" 상태인지 알기가 어렵다.
 

v클러스터 : 빼는 것이 더하는 것

젠텔과 크램은 클러스터에 대한 플릿 접근 방식에 개선의 여지가 많다는 점과 쿠버네티스 멀티테넌시를 전통적인 네임스페이스 방식을 넘어 재정의할 수 있다는 것을 깨달았다.
 
이들은 2023년 v클러스터를 출시하면서 가벼운 가상 쿠버네티스 클러스터를 만들기 위한 추상화인 "가상 클러스터" 개념을 도입했다. 가상 사설망이 물리적 인프라 위에 가상 네트워크를 만드는 방법과 마찬가지로 가상 클러스터는 공유된 물리적 쿠버네티스 클러스터 위에 격리된 쿠버네티스 환경을 만든다.
 
v클러스터는 인증된 쿠버네티스 배포판이므로 가상 클러스터는 다른 모든 쿠버네티스 클러스터와 똑같이 작동하지만 중요한 차이점이 하나 있다. 각 가상 클러스터는 자체 네임스페이스와 포드, 서비스를 관리하지만 플랫폼 스택을 복제하지 않는다. 대신 기반 물리적 클러스터에서 실행하는 이스티오나 오픈 폴리시 에이전트와 같은 무거운 플랫폼 구성요소를 공유한다. 이 공유된 플랫폼 스택 덕분에 가상 클러스터는 플랫폼 서비스 복제라는 무거운 짐을 더 이상 끌고 다니지 않는다.
 
그러면서도 각 v클러스터에는 자체 API 서버와 제어 평면이 있어 테넌트에 강력한 격리를 제공하고 플랫폼 팀이 보안과 거버넌스를 위한 자체 맞춤형 정책을 만들 수 있도록 한다. 자체 네임스페이스를 만들고 자체 맞춤형 리소스를 배포하고 자체 백업 저장소를 사용해 클러스터 데이터를 보호하고 자체 액세스 제어 정책을 사용자에게 적용할 수 있다.
 
또한 v클러스터는 플랫폼 팀에 물리적 클러스터보다 훨씬 더 높은 속도와 민첩성을 제공한다. 가상 클러스터를 가동하는 데 소요되는 시간은 물리적 클러스터에 비해 극히 짧다. v클러스터를 재시작하는 데는 약 6초가 소요되는데, 이스티오와 같은 무거운 플랫폼 서비스를 실행 중인 물리적 쿠버네티스 클러스터의 경우 30분 또는 45분이 걸린다.
 
젠텔은 "쿠버네티스는 API, 툴, 표준화 관점에서 훌륭하지만 클라우드 제공업체rk 소규모 클러스터 실행용으로 내세운 아키텍처로 인해 비용과 무거움 측면에서 물리적 서버 시대로 되돌아갔다"면서 "90년대에는 사람이 실제로 데이터 센터로 들어가서 서버를 연결하고 자극 증명을 발급하고 기타 수동 단계를 수행해야 했다. 현재 쿠버네티스의 상황도 비슷하다. 많은 기업이 전체 애플리케이션 스택을 각 클러스터에 실행하고 있으며 이로 인해 많은 중복이 발생한다”라고 지적했다.
 
v클러스터는 쿠버네티스 클러스터를 더 가볍고 단명하게 만들어 준다. 가상 머신이 물리적 서버에 미친 영향, 컨테이너가 전반적인 워크로드에 미친 영향과 비슷하다.
 
젠텔은 "소규모 단일 테넌트 쿠버네티스 클러스터를 가동한다는 것은 애초부터 잘못된 개념이다. 비용이 상당하고 관리하기도 매우 어렵기 때문이다. 결국 수백 개의 클러스터가 생성된다. 이 모든 클러스터에 걸쳐 인그레스 컨트롤러, 인증서 관리자, 프로메테우스, 메트릭과 같은 것들을 유지 관리해야 한다. 막대한 작업이며 동기화를 유지하기도 매우 어렵다”라고 말했다.
 

숫자로 본 v클러스터

v클러스터는 깃허브에서 6,000개의 별표를 획득했으며 기여자는 120명 이상이다. 이 프로젝트는 쿠버네티스 전문가들의 관심을 끌어서, 랜처(Rancher)의 전 CTO이자 공동 창업자인 대런 세퍼드는 가상 클러스터 사용을 적극 지지하고 있다. 어도비, 코어위브(CoreWeave), 코드프레시(Codefresh)와 같은 기업의 여러 팀은 큐브콘(KubeCon)과 같은 이벤트에서 v클러스터를 사용 중임을 밝혔다.
 
젠텔과 크램의 스타트업인 로프트 랩스는 최근 v클러스터를 중심으로 한 엔터프라이즈 기능을 확장하기 위한 자금 투자를 받았다. 2,400만 달러의 시리즈 A는 깃랩, 오픈AI와 같은 기업의 첫 기관 투자자로 유명한 코슬라 벤처스(Khosla Ventures)가 주도했다.
 
v클러스터를 기반으로 한 로프트 랩스의 상용 솔루션은 비활성 가상 클러스터를 자동으로 끄는 "슬립 모드"와 관련해서 특히 관심을 모았다. 일반적으로 기업에서 클러스터는 가동된 후 항상 실행된다. 로프트 랩스의 제품은 유입되는 API 요청을 모니터링해서 가상 클러스터 활동을 측정하고, 사용되지 않을 때 슬립 모드를 사용해 자동으로 가상 클러스터 규모를 축소하여 클라우드 리소스와 전체 비용을 절감한다.
 
v클러스터는 클라우드 인프라를 더 효율적으로 실행하고 클라우드 비용을 낮추는 데 도움이 되는 것과 함께 중앙 제어 및 개발자 속도 측면에서 성공적인 결과를 얻기 위한 더 명확한 경로도 제공한다. v클러스터는 물리적 클러스터 리소스를 확장하는 외에 각 가상 클러스터에 자체적인 개별 API 서버와 제어 평면을 제공해서 플랫폼 팀에 쿠버네티스 클러스터의 관리, 보안, 리소스 할당, 확장을 위한 더 높은 유연성과 제어 기능을 제공한다.
editor@itworld.co.kr