클라우드 파운드리(Cloud Foundry, 이하 ‘CF’)는 멀티클라우드를 지원하는 오픈소스 기반의 PaaS(Platform as a Service)이다. 일반적인 클라우드서비스인 IaaS(Infra as a Service)에서는 필요한 만큼 컴퓨팅 자원과 인프라가 제공되지만, 애플리케이션을 포장하고 배포하는 것은 모두 고객(개발자)이 알아서 수행해야 한다.
참고로, PaaS는 애플리케이션 패키징, 배포, 실행을 모두 클라우드에서 ‘알아서’ 해주는 것을 말한다. IaaS가 초기 단계의 클라우드서비스를 대표한다면, PaaS는 다음 단계의 진화된 클라우드서비스로 볼 수 있다. 컴퓨팅 자원 할당, 애플리케이션 배포·운영에 대한 전문적인 지식이나 경험이 없어도 얼마든지 애플리케이션을 배포·운영할 수 있다는 것이 PaaS를 사용하는 강점이다.
PaaS는 특정 IaaS 서비스 벤더에 귀속될 필요가 없다. CF 역시 멀티클라우드를 지원한다. CF를 직접 IaaS에 배포해서 사용하는 것도 가능하지만, 상용 CF 클라우드서비스를 활용하는 것이 일반적이다. 피보탈 클라우드 파운드리(PCF: Pivotal Cloud Foundry)를 이은 탄주 애플리케이션 서비스(TAS: Tanzu Application Service)가 아마존 AWS, 마이크로소프트 애저, 구글 클라우드 플랫폼 등 대부분 주요 클라우드서비스에서 제공된다.
기존 CF를 주로 활용해왔던 고객은 이들 클라우드서비스 벤더에서 제공하는 TAS를 사용하여 최소한의 노력으로 퍼블릭 클라우드로의 전환이 가능하다. 더 나아가, 단일 벤더가 아닌 멀티클라우드 벤더를 활용할 수 있을 뿐만 아니라 만일 온-프레미스 CF를 계속 활용한다면 하이브리드 멀티클라우드 형태의 애플리케이션 운용도 가능하다.
CF vs. 쿠버네티스: 클라우드 네이티브 플랫폼 관점에서
CF를 활용하면 일관된 방식으로 애플리케이션을 배포·운영할 수 있다. 즉, 애플리케이션 수요가 늘면 배포 규모를 늘리고, 줄면 배포를 회수하는 스케일업·다운도 가능하다. 특정 애플리케이션 혹은 사용량에 따라 각기 다른 별도의 수동(manual) 형상관리(configuration)가 필요하지 않다는 뜻이다. 이는 클라우드 네이티브 컴퓨팅(Cloud Native Computing)이 지향하는 목표와 일치한다. 도커(Docker)나 쿠버네티스(Kubernetes)가 세상에 모습을 드러내기 전, 이미 CF는 클라우드 네이티브 컴퓨팅을 지향하고 있다고 볼 수 있다.
클라우드 네이티브 컴퓨팅의 핵심은 컨테이너화(containerization)이다. 2020년 기업 IT 리더를 대상으로 한 조사에 의하면 이들 중 85%가 클라우드 네이티브로 가는 것을 높은 우선순위로 두고 있으며, 86%는 더 많은 애플리케이션을 컨테이너화하는 것이라고 답했다. 또 다른 조사에서는 컨테이너 오케스트레이션을 위해 쿠버네티스를 사용하느냐는 질문에 91%가 그렇다고 답했다. 같은 조사에서 75%는 이미 실제 프로덕션에 쿠버네티스를 활용한다고 했다.
CF와 쿠버네티스는 각각 다른 방식으로 클라우드 네이티브 컴퓨팅을 지원한다. CF에서 개발자는 ‘코드’를 배포하는 것이라면 쿠버네티스에서는 패키징을 거친 ‘컨테이너’를 배포하는 것이 개념상 가장 큰 차이라고 할 수 있다. CF에서는 코드 개발이 끝나면 개발자에 의한 “CF push” 명령으로부터 시작하여 CF 애플리케이션 런타임(CFAR) 이미지가 만들어지고 여러 단계를 거쳐 최종적으로 VM(가상머신)을 할당받음으로써 배포까지 완료된다.
쿠버네티스를 사용하는 경우 개발이 완료되면 작성된 애플리케이션 및 필요로 하는 이미지를 모아 컨테이너 이미지로 패키징한다. 이 컨테이너는 쿠버네티스 클러스터에 배포되어 실행단계로 넘어간다. 배포 단위에서 ‘CFAR-VM’이냐, ‘컨테이너’이냐의 차이를 배제하면 기본 배포 개념은 매우 유사하다. 쿠버네티스가 (컨테이너) 운영 플랫폼으로 초점을 맞추었다면, CF는 개발자 친화적 경험에 좀 더 초점을 맞추고 있다고 평하기도 한다.3)
클라우드 네이티브 플랫폼으로서 쿠버네티스의 위상은 앞서 살펴본 바와 같이 계속 높아지고 있다. 애플리케이션 컨테이너화는 선택이 아닌 필수로 여기고 있으며, 컨테이너 오케스트레이션 시장에서는 쿠버네티스 도입이 압도적이다. ‘쿠베네티스’를 사실상 표준 클라우드 운영 체제로 여기는 분위기이다.
이에 어떻게 CF와 쿠버네티스를 접목할 것인가가 CF를 공식적으로 관장하는 CF 파운데이션의 최대 고민거리가 되고 있다. 2021년 5월 15일 현재 CF 파운데이션 홈페이지의 뉴스섹션에 2021년 기사가 15개가 걸려 있는데 이 중 10개의 뉴스 제목에 쿠버네티스 관련 단어가 포함된 것만 보아도 CF의 최고 화두는 쿠버네티스와의 결합임을 알 수 있다.
CF가 쿠버네티스를 품는 방식
CF와 쿠버네티스를 접목하기 위한 여러 프로젝트가 진행되고 있다. CF 고유의 사용자 경험을 살리면서 CF 워크로드(workload)를 쿠버네티스 클러스터에서 효과적으로 사용하게 하는 것이 프로젝트의 목적이다. 주요 프로젝트를 소개하기 전에 우선 CF의 전형적인 구조를 보도록 하자.4) (그림 2)
BOSH는 소프트웨어 출시, 배포, 업데이트를 포함한 전 라이프사이클 관리를 위한 CF 기본 도구이다. IaaS 레벨을 추상화함으로써 다양한 IaaS 또는 하이퍼스케일러(hyperscaler) 상에서 동일한 방식으로 PaaS 동작이 가능하도록 한다. 개발이 완료된 후 ‘CF push’를 하게 되면 CF의 여러 컴포넌트가 API 호출을 통해 상호 동작하여 최종 수행될 CFAR(Cloud Foundry Application Runtime) 이미지가 만들어지며 이는 최종적으로 디에고(Diego)에 의해 지정된 VM 상에서 실행된다. CF가 쿠버네티스와 호환되기 위해선 최소한 두 가지 조건이 필요하다.
- 쿠버네티스 호환 컨테이너 이미지가 생성되어야 한다.
- 생성된 이미지를 쿠버네티스 클러스터에 배포할 수 있어야 한다.
쿠보와 퀵스
쿠버네티스 호환 이미지를 생성하는 프로젝트로는 쿠보(Kubo)와 쿽스(Quarks)를 들 수 있다.
- 쿠보(Kubo: Kubernetes on BOSH): 쿠보는 BOSH를 활용하여 쿠버네티스 클러스터에 CF 애플리케이션을 배포하기 위해 진행되었다. 기존 VM 위에서 돌아가는 CFAR이 아니라 쿠버네티스와 호환되는 CFCR(Cloud Foundry Container Runtime)을 생성하고 이를 쿠버네티스 클러스터에 배포하는 방식이다. 컨테이너 오케스트레이션 및 라이프사이클 관리에 BOSH를 그대로 사용함으로써 기존 CF 고객이 쿠버네티스로 전환할 경우 CF를 사용할 때와 동일한 경험을 제공한다는 것이 강점이다. CFCR이 쿠버네티스와 호환된다고는 하나, 모든 CF 애플리케이션을 완벽하게 CFCR 이미지로 생성할 수는 없다. 따라서 레거시 CF 애플리케이션을 쿠버네티스로 전환하기에는 한계가 있을 수 있다. 상용 서비스인 PKS(Pivotal Container Service)가 이를 기반으로 하고 있다.
- 쿽스(Quarks): 쿽스는 CFAR을 도커(Docker) 컨테이너 이미지로 패키징하는 것이다. 이렇게 패키징된 컨테이너는 쿠버네티스에서 바로 지원되므로 오케스트레이션뿐만 아니라 컨테이너 라이프사이클 관리도 쿠버네티스 인프라로 가능하다.
에이리니 프로젝트
쿠버네티스 클러스터에서 실행 가능한 컨테이너 이미지가 만들어 지면 이를 쿠버네티스 클러스터에 배포하여야 한다. 기존 VM 기반 스케줄링을 담당하던 디에고를 대체할 것이 필요하게 된다. 그래서 등장한 것이 에이리니(Eirini) 프로젝트이다.
- 에이리니(Eirini): CF를 구성하는 컴포넌트로 개발되었으며 쿠버네티스 컨테이너 이미지로 패키징된 CF 애플리케이션을 쿠버네티스 클러스터에서 실행시키는 역할을 담당한다. 쿠버네티스를 컨테이너 스케줄러로 활용함으로써 디에고를 굳이 CF에서 사용할 필요가 없다.
이들 프로젝트는 각각 독립적으로 진행되는 프로젝트이지만, 함께 사용됨으로써 CF와 쿠버네티스의 결합이 좀 더 잘 이루어질 수 있다.
쿠버네티스 기반 CF: KubeCF, CF-for-k8s
다양한 쿠버네티스 기반 CF 프로젝트들이 현재 진행되고 있다. 앞서 올린 그림은 이 중 하나인 KubeCF의 예이다. KubeCF는 CF의 쿠버네티스 배포판으로는 CF에 꽤 가까운 모습을 갖고 있다. CF 컴포넌트들이 기존 IaaS 또는 하이퍼스케일러 대신 쿠버네티스 인프라 위에 그대로 구현되어있는 모습이다. KubeCF는 헬름(Helm)을 이용해 쿠버네티스에 배포될 수 있는 CFAR 빌드를 생성하며 이는 CF-operator에 의해 관리된다.
헬름은 쿠버네티스 패키지 관리 시스템으로 차트(charts) 포맷을 사용함으로써 편하게 쿠버네티스 클러스터에 배포할 수 있도록 하는 운영 도구이다. CF-operator는 쿽스 프로젝트팀이 개발한 도구로 BOSH에서 생성되거나 활용되는 다양한 산출물들을 쿠버네티스에 호환될 수 있도록 확장해 주는 역할을 한다.
KubeCF는 기존 CF 사용자 커뮤니티가 가능한 기존 환경과 유사하게 쿠버네티스로 전환할 수 있도록 한 것에 초점을 두었다고 볼 수 있다. CF-operator는 쿠버네티스 고유 컴포넌트들과 BOSH에서 생성된 것이 동시에 공존할 수 있도록 다양한 모니터링 및 변환 기능을 수행함으로써 기존 CF 환경에 익숙한 사용자들의 쿠버네티스 전환을 용이하게 한다. 하지만 CF-operator를 사용한다고 해서 BOSH에서 사용되는 것 모두가 완벽하게 쿠버네티스 환경에서도 호환될 수 있는 것은 아니다.
CF-for-k8s는 진정한 네이티브 클라우드를 지원하는 CF 배포판임을 표방하고 있다. 그러다 보니 기존 CF에서의 많은 컴포넌트를 과감하게 제거하고 이를 클라우드 네이티브 모듈들로 대체하였다. 살아남은 기존 CF 컴포넌트들도 쿠버네티스 워크로드로 새롭게 포장되었다.
기존 CF의 라우팅 컴포넌트(gorouter)가 이스티오(Istio)로 대체되었다. 이스티오는 쿠버네티스 세계에서 가장 인기 있는 서비스 메시(mesh) 기술이다. 로깅 및 모니터링 컴포넌트도 쿠버네티스에 친화적인 것으로 바뀌었고 CF의 패키지 빌드 컴포넌트도 kpack으로 교체되었다. kpack은 VM웨어가 CF의 buildpack 로직을 새로 구현한 것이다. 물론 쿠버네티스 표준 이미지와 호환된다. kpack으로 생성된 이미지는 에이리니를 통해 쿠버네티스 클러스터에 배포된다. 많은 컴포넌트가 원래 CF 배포본과 달라졌지만, ‘CF push’를 통해 CF 애플리케이션 배포되는 것은 여전히 동일하다.
문제는 CF와의 호환성이다. 실제로 CF-for-k8s 현재 수준으로는 CF 제공자 인증(CF Provider Certification)을 받지 못할 것이라고 한다.
이 밖에도 구글이 자사 앤토스(Anthos) 스윗의 일부로 제공하는 Kf라는 것이 있다. 개발자 관점에서 CF의 명령어 인터페이스(CLI)를 사용하는 것과 유사한 경험을 제공하는 것이 핵심이다. 즉 ‘CF push’를 완벽한 쿠버네티스 네이티브 환경에서도 할 수 있다는 것이다. CF라고 말하기에는 거리가 멀지만 CF의 시그니처 경험을 추구하는 개발자라면 고려해 볼 수 있는 한 옵션이라 하겠다. 기존 CF 애플리케이션의 자연스러운 마이그레이션은 기대하기 어렵다.
쿠버네티스 기반 CF의 미래
KubeCF가 되든 CF-for-k8s가 되든 아니면 또 다른 쿠버네티스 기반 CF 배포판이 나오든 결국 쿠버네티스는 기존 IaaS·하이퍼스케일러 레이어를 완벽하게 대체할 수 있게 될 것이다. 물론 CF가 IaaS나 하이퍼스케일러를 더는 지원하지 않는다는 뜻은 아니다.
하지만 KubeCF와 CF-for-k8s는 확실히 다른 진화의 방향을 제시하고 있다. KubeCF는 CF 호환성을 위해 기존 컴포넌트들을 최대한 유지하며 쿠버네티스 네이티브에 가깝게 가고 있는 방향이라면, CF-for-k8s는 시작부터 쿠버네티스 네이티브를 표방하며 최소한의 CF 호환성을 유지하고 있다.
기업이 뒷받침하는 상용화 수준도 쿠버네티스 기반 CF의 미래에 큰 영향을 미친다. VM웨어에서는 TAS for 쿠버네티스를 작년에 들고 나왔다. 발표 당시의 퍼블릭 베타 서비스 구성 내용을 보면 CF-for-k8s 기반임을 알 수 있다. 그러나 현재 TAS에서는 고급 서비스로 쿠버네티스 기반 데브옵스를 지원하는 것 말고는 본격적인 쿠버네티스 기반 상용 서비스를 하지 않고 있는 것으로 보인다.
KubeCF는 SUSE, IBM, HCL이 주축이 되어 업데이트가 이루어지고 있다. IBM이 프로덕션 수준으로 사용하고 있으며, SUSE 고객들도 사용하고 있는 것으로 알려졌다. 깃헙의 활동을 비교해 보아도 KubeCF가 CF-for-k8s보다는 좀 더 활발하다는 것을 알 수 있다. KubeCF와 CF-for-k8s 두 개만 비교한다면 현재는 KubeCF가 좀 더 희망이 있어 보인다.
끝으로 BOSH를 언급하고 싶다. BOSH는 CF의 표준 운영 도구로서 CF의 특징을 대표하는 컴포넌트이다. 그러나 CF와 쿠버네티스와의 결합이 단단해질수록 BOSH의 역할은 점차 쿠버네티스 고유의 도구로 흡수될 가능성이 크다. CF 애플리케이션의 마이그레이션 관점에서 BOSH-aware 부분을 어떻게 풀어나갈 것인가가 숙제이다. KubeCF에서는 CF-operator가 이를 일부 해결하고 있다. 또 다른 이런 질문도 가능하다. BOSH가 사라진다면 과연 CF라고 부를 수 있는 기준은 무엇일까?
아마도 최후의 보루는 ‘CF push’가 아닐까?
[divide style=”2″]
[box type=”note”]
본 글은 한국지능정보사회진흥원의 지원을 받아 작성되었으며, 디지털서비스 이용지원시스템에 동시 게재합니다.
[/box]
