VMware Tanzu Application Service (TAS)
TAS의 유례
1. Cloud Foundry의 탄생과 초기 발전
- 2009년: VMware 내부에서 PaaS 환경을 제공하기 위해 Cloud Foundry의 초기 형태가 개발되기 시작했습니다
- 2011년: VMware가 Cloud Foundry를 오픈소스로 공개하면서 Cloud Foundry 프로젝트가 본격적으로 시작되었습니다
2. Pivotal로의 이관 및 상용화
-
2012년: 당시 VMware의 모회사였던 EMC가 VMware 일부 부서와 함께 새로운 회사 Pivotal을 설립하면서 Cloud Foundry 관련 개발 업무가 Pivotal로 이관되었습니다
-
2013년: Pivotal은 Cloud Foundry를 기반으로 한 상용 PaaS 제품인 Pivotal Cloud Foundry(PCF)를 출시하여, 엔터프라이즈 환경에 적합한 PaaS 솔루션으로 성장시켰습니다
3. Kubernetes의 등장과 VMware에 의한 인수, 리브랜딩
-
Kubernetes의 등장으로 인해 PaaS 시장의 판도가 변화하고, Pivotal의 수익성에 어려움이 발생하자, 2019년 VMware는 Pivotal을 다시 인수하였습니다
-
인수 이후 VMware는 기존 PCF 제품을 자사의 Tanzu 브랜드 아래 통합하고, Tanzu Application Service(TAS)라는 이름으로 리브랜딩하여 Cloud Foundry 기반의 PaaS 솔루션을 계속 지원하게 되었습니다
-
한편, VMware는 Kubernetes 기반의 Tanzu Kubernetes Grid(TKG)도 함께 병행 지원하여, 컨테이너와 VM 기반 워크로드를 모두 포괄하는 하이브리드 전략을 추진하고 있습니다
4. 최신 변동 사항
-
TAS 버전 10: 최신 TAS 버전에서는 제품명이 Tanzu Pivotal Cloud Foundry(TPCF)로 변경되었습니다
-
Broadcom 인수: 최근 VMware는 Broadcom에 인수되어, 현재 TAS 및 Tanzu 포트폴리오의 제품들이 Broadcom 산하에서 운영되고 있습니다
TAS 버전 10이 나오면서 솔루션이름이 TPCF로 변경되었지만 (Tanzu Platform for Cloud Foundry) 나는 TAS라는 이름이 더 익숙해 블로그 내에서는 TAS라고 계속 명칭할 예정
TAS란?
VMware Tanzu Application Service(TAS)는 원래 Pivotal Cloud Foundry(PCF)에서 발전한 플랫폼으로, 애플리케이션 개발자에게 높은 추상화 수준의 PaaS 환경을 제공합니다. TAS는 개발자가 코드만 제출하면 나머지 인프라 설정, 빌드, 런타임 환경, 스케일링, 로깅 및 모니터링 같은 운영 작업을 자동으로 관리하여 빠르게 프로덕션 환경에 애플리케이션을 배포할 수 있도록 해줍니다. 이와 함께 TAS는 BOSH 기반의 릴리즈 관리 및 안정적인 업그레이드 체계를 갖추고 있어 엔터프라이즈 환경에 적합한 신뢰성과 운영 효율성을 제공합니다.
CloudFoundry란?
Cloud Foundry는 오픈소스 기반의 PaaS(Platform as a Service) 솔루션으로, 개발자가 애플리케이션을 쉽고 빠르게 배포할 수 있도록 도와주는 플랫폼입니다.
컨테이너 오케스트레이션에 초점을 맞춘 Kubernetes와 달리, 애플리케이션 배포와 운영을 자동화하는 데 중점을 둔 플랫폼입니다.
CloudFoundry 특징
-
애플리케이션 중심의 배포
개발자는 cf push 한 줄만으로 애플리케이션을 배포할 수 있습니다.
인프라, 컨테이너 관리가 필요 없으며, 코드만 업로드하면 자동으로 실행 환경이 구성됩니다. -
Buildpack을 통한 표준화된 배포
Cloud Foundry는 Buildpack을 사용하여 애플리케이션의 실행 환경을 자동으로 설정합니다.
개발자가 Dockerfile을 직접 작성하지 않아도 되며, 보안 및 표준화가 강화됩니다. -
자동 확장 및 Self-Healing
트래픽 변화에 따라 애플리케이션 인스턴스를 자동으로 확장 또는 축소할 수 있습니다.
애플리케이션 인스턴스가 장애가 발생하면 자동으로 복구됩니다. -
다양한 인프라 지원
Cloud Foundry는 VMware vSphere, AWS, Google Cloud, OpenStack 등 다양한 인프라에서 동작할 수 있습니다. -
강력한 멀티 테넌시(Multi-Tenancy)
조직(Org)과 공간(Space) 개념을 활용하여 여러 개발팀이 하나의 Cloud Foundry 플랫폼을 공유할 수 있습니다.
VMware Tanzu Platform 종류
현재 VMware Tanzu Platform 종류로는 CloudFoundry기반의 TPCF와 쿠버네티스기반인 Tanzu Platform이 있습니다
VMware TAS와 Kubernetes 차이점
아키텍처 및 핵심 기술
TAS
-
Cloud Foundry 기반
TAS는 Cloud Foundry의 철학을 이어받아 개발자에게 높은 수준의 추상화를 제공합니다. 개발자는 cf push와 같은 명령어 한 줄로 애플리케이션을 배포할 수 있으며, 내부적으로는 빌드팩(buildpack)과 Diegocell, CloudController를 통해 애플리케이션 빌드, 배포, 스케일링, 업데이트 등이 자동화됩니다 -
BOSH 및 자동화 도구
TAS는 BOSH를 통해 VM 기반 인프라의 배포와 업그레이드를 관리합니다. 이는 기업 환경에서 복잡한 인프라 관리 부담을 줄이고, 안정적이고 예측 가능한 방식으로 시스템을 운영할 수 있도록 돕습니다
Kubernetes
-
컨테이너 오케스트레이션 플랫폼
Kubernetes는 컨테이너화된 애플리케이션을 Pod, Deployment, Service 등 다양한 개념을 통해 세밀하게 제어하며 YAML 기반의 선언적 매니페스트로 인프라를 구성합니다 -
오픈 소스 생태계 및 확장성
Kubernetes는 오픈 소스와 활발한 커뮤니티 덕분에 수많은 오퍼레이터, 플러그인, 도구(예: Helm, Istio, Prometheus 등)와 함께 활용할 수 있으며 다양한 클라우드 및 온프레미스 환경에서 유연하게 운영할 수 있습니다
TAS는 VM과 컨테이너를 동시에 사용하는 하이브리드 아키텍처를 채택해 리소스가 많이 필요한 서비스에서도 높은 안정성과 컨테이너의 민첩성을 동시에 확보할 수 있는 점이 TAS의 주요 강점입니다.
Kubernetes는 다양한 오픈소스 서비스를 자유롭게 선택할 수 있어 유연성이 뛰어난 반면 TAS는 Grafana, Prometheus 등 정해진 오픈소스만 지원해 선택 폭이 제한됩니다.
예를 들어 IMDG 구성에서는 Kubernetes에서 Redis Gemfire 선택이 가능하지만 TAS는 기본적으로 Gemfire만 지원하며 서드파티 Redis에 대해서는 지원은 하지만 SR 지원 수준이 낮아 사실상 Gemfire에 의존하게 됩니다.
개발자 경험 및 배포 프로세스
TAS
-
단순화된 개발자 경험
TAS는 Cloud Foundry 방식의 단순한 push 명령으로 애플리케이션 배포를 가능하게 합니다. 개발자는 복잡한 인프라 설정 없이 코드만 제출하면 빌드팩이 자동으로 런타임 환경과 종속성을 구성하여 애플리케이션을 실행합니다 -
내부 서비스 바인딩 및 자동 스케일링
기존에 미리 구성된 서비스(예: 데이터베이스, 캐시 등)와의 바인딩이 내장되어 있어 개발자는 추가 설정 없이도 필요한 외부 리소스를 손쉽게 사용할 수 있습니다 또한, 자동 스케일링, 롤링 업데이트 등 운영 작업이 자동화되어 있어 신속하게 변경사항을 반영할 수 있습니다
Kubernetes
-
세분화된 배포 제어
Kubernetes는 선언적 접근 방식을 통해 YAML 매니페스트로 애플리케이션 상태를 정의합니다. 이는 버전 관리 및 재현성이 뛰어나지만 초기 설정이나 복잡한 구조 때문에 학습 곡선이 다소 높습니다 -
Helm 및 템플릿 도구 활용
Helm 차트나 Kustomize와 같은 도구를 사용하면 복잡한 배포 구성을 템플릿화하여 여러 환경에서 일관되게 재사용할 수 있습니다 -
커스텀 배포 전략 구현 가능
Kubernetes에서는 롤링 업데이트, 캔너리 배포, 블루/그린 배포 등 다양한 배포 전략을 세밀하게 구성할 수 있으며, 필요에 따라 맞춤형 오퍼레이터나 스크립트를 추가하여 운영할 수 있습니다
제가 생각하는 PaaS의 취지는 개발자들은 개발에만 집중하고 PaaS 플랫폼에서 배포에 대한 모든것을 담당해야 한다는 생각인데 TAS는 해당 PaaS의 취지에 적합합니다. 개발자는 자신의 소스코드의 jar 또는 war 파일과 manifest만 있으면 쉽게 컨테이너를 배포할 수 있습니다.
운영 및 관리 측면
TAS
-
통합 관리 콘솔
TAS는 로그, 모니터링, 패치, 스케일링 등의 운영을 하나의 관리 콘솔을 통해 제공합니다. 특히 BOSH 기반 자동화 기능을 통해 VM 배포와 업그레이드를 일괄 관리할 수 있습니다 -
엔터프라이즈 신뢰성
TAS는 기존 대기업 환경에서 Cloud Foundry의 안정성을 바탕으로 구축되었기 때문에, 레거시 시스템과의 통합과 안정적 운영에 유리합니다.
Kubernetes
-
자체 복구 및 스케줄링
Kubernetes는 컨테이너의 자가 치유(self-healing) 기능, 자동 스케줄링 및 리소스 배분을 통해 장애 복구와 운영 효율성을 높입니다. 다만, 이를 위해서는 클러스터 구성 요소(API 서버, 스케줄러, etcd 등)을 직접 이해하고 관리해야 합니다 -
분산 관리 및 확장성
다양한 클라우드 및 온프레미스 환경에서 동일한 오케스트레이션 방식을 적용할 수 있어, 멀티 클라우드 운영이나 엣지 컴퓨팅 환경에서 유연하게 활용 가능합니다
TAS는 운영 측면에서 매우 우수한 플랫폼입니다. Kubernetes에 비해 오픈소스 생태계 기반의 확장성은 다소 제한적일 수 있으나, 사전에 정의된 구조와 서비스 위에서 애플리케이션을 운영하기 때문에 안정성과 일관된 운영이 가능하다는 강점이 있습니다.
특히, 개발자와 운영자의 역할이 명확히 분리되어 있으며, cf push를 통한 배포 자동화, 로그 수집, 헬스체크, 스케일링 등의 기능이 내장되어 있어 운영 효율성이 높습니다.
다만, TAS는 단순 컨테이너 플랫폼이 아닌 VM 기반의 플랫폼이기 때문에 Diego Cell 등 구성요소에서 발생하는 이슈에 대해 OS 레벨의 트러블슈팅이 필요한 경우가 많습니다. 커널 설정, 파일 시스템 문제, 리소스 경합 등 인프라 레벨의 이슈까지 점검해야 하는 경우도 자주 발생합니다.
또한, 장애 대응 측면에서 공식 문서나 사례 기반의 레퍼런스가 상대적으로 부족합니다. 문제 발생 시 단일한 해결 가이드를 찾기 어려워, 로그 기반의 분석과 내부 구조에 대한 깊은 이해를 바탕으로 직접 원인을 추적해야 하는 경우가 많습니다. 이러한 점은 운영 난이도를 높이는 요인 중 하나입니다.
