넷플릭스∙스포티파이∙우버의 공통점…'클라우드 네이티브'의 정의와 특징

‘클라우드 네이티브 컴퓨팅(Cloud-native Computing)’이란 용어는 소프트웨어 개발자가 클라우드 인프라 상에서 현대적인 소프트웨어 애플리케이션을 제작하고 배포하고 유지 관리하는 데 필요한 다양한 도구와 기법을 통칭한다. 클라우드 네이티브를 정의하고 관련 생태계를 탐구하고 클라우드 네이티브의 장점과 과제를 소개한다.
 

클라우드 네이티브 정의 

클라우드 네이티브는 클라우드 컴퓨팅의 유연성, 확장성, 탄력성을 이용해 소프트웨어 애플리케이션을 제작하고 실행하는 현대적인 접근법이다. 클라우드 네이티브는 오늘날 퍼블릭 클라우드용 애플리케이션을 개발하기 위해 소프트웨어 개발자가 사용하는 다양한 도구와 기법을 망라한다. 이는 온프레미스 데이터센터에 적합한 전통적인 아키텍처와 상반된다.  

소프트웨어를 제작하고 운영하는 클라우드 네이티브 접근법은 흔히 ‘클라우드에서 탄생했다’라고 이야기되는 일군의 기업들에 의해 개척되었다. 예를 들어 거대 스트리밍 기업인 넷플릭스, 스포티파이, 승차 공유 회사인 우버, 숙박 예약 플랫폼인 에어비앤비 같은 업체를 말한다. 그 후 클라우드 네이티브 접근법은 유사한 디지털 기민성과 강력한 경쟁 우위를 추구하는 다른 기업들에 의해 도입되었다. 
 

클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)은 클라우드 네이티브를 애플리케이션 컨테이너화에 중점을 두면서 다소 협소하게 정의한다. 여기서는 애플리케이션이 마이크로서비스로 분해되어 경량 컨테이너에 담긴 후 다양한 서버에 걸쳐 전개되고 오케스트레이션된다.
 
CNCF의 자체적인 서술에 따르면 “클라우드 네이티브 기술은 퍼블릭, 프라이빗, 하이브리드 클라우드 등 현대적이고 역동적인 환경에서 확장성있는 애플리케이션을 제작하고 운영할 수 있는 역량을 조직에 부여한다.”

일반적으로 클라우드 네이티브 앱 개발은 마이크로서비스, 클라우드 플랫폼, 컨테이너, 쿠버네티스, 불변 인프라, 선언형 API, 연속 배포 기술을 데브옵스, 애자일 방법론 등의 기술과 결합하는 것을 포함한다. 
 

클라우드 네이티브 생태계 

소프트웨어 개발 기법의 보편적 변화에 따라 대부분이 오픈소스로 구성된 도구라는 새로운 환경이 출현하게 되었다. CNCF는 각기 연결된 생태계를 예시로 나타내고 있다.

클라우드 네이티브 컴퓨팅을 이해하려면 다음 4개의 계층을 알아야 한다. 

•    애플리케이션 정의 및 개발 레이어(application definition and development layer): 클라우드 네이티브 스택의 최상위 레이어이고 개발자가 애플리케이션을 제작하는 데 사용하는 도구에 집중한다. 예를 들어 데이터베이스, 메시징 시스템, 컨테이너 이미지, 지속 통합 및 지속 배포(CI/CD) 파이프라인이다. 

•    프로비저닝 레이어(provisioning layer): 클라우드 네이티브 스택의 프로비저닝 레이어는 애플리케이션이 이상적으로 반복적 형식으로 실행될 환경을 구축하고 보안할 때 필요한 모든 것을 아우른다. 클라우드 네이티브 세계에서 통상적으로 코드형 인프라(infrastructure as code)의 취급, 리포지터리에 이미지 저장, 빌드의 자동화를 포함하고, 아울러 취약점 검사, 암호 및 정책 관리, 인증 도구에 의한 애플리케이션 보안 니즈에 대한 대처도 관계가 있다.

•    런타임 레이어(runtime layer): 런타임 레이어는 컨테이너 런타임 등 클라우드 네이티브 애플리케이션의 실행(여전히 도커인 경향이 있음), 스토리지, 네트워킹에 연관된 모든 것을 아우른다. 

•    오케스트레이션 및 관리 레이어(orchestration and management layer): 오케스트레이션 및 관리 레이어는 오케스트레이션, 스케줄링 등 컨테이너화된 애플리케이션을 전개하고 관리하고 확장/축소하는 제반 도구다. 대부분의 경우 쿠버네티스를 의미하고, 아울러 서비스 디스커버리, 서비스 프록시, API 게이트웨이, 서비스 메시 등을 의미하기도 한다. 

레이어 외에도 관찰 가능성 프랙티스(Observability Practices)를 이행하는 것 역시 중요하다. 프랙티스를 통해 제반 서비스를 효과적으로 모니터할 수 있다. 또한 일부 조직은 자신의 스택을 자율-서비스 내부 개발자 플랫폼으로 가져오거나 조직의 의견이 반영된 서비스형 플랫폼(platform as a service, PaaS)을 구매해 개발자의 도입을 용이하게 만들기도 한다. 
 

온프레미스 아키텍처와 비교했을 때 클라우드 네이티브의 장점

클라우드 네이티브 애플리케이션 개발은 흔히 온프레미스 데이터센터에서 운영되는 전통적 기업 애플리케이션과는 매우 다른 아키텍처를 요구한다. 여기에서는 전통적인 앱 개발 모델과 비교했을 때 클라우드 네이티브 애플리케이션이 갖는 핵심적인 차이와 장점을 정리했다.

언어. 회사 서버에서 운영되는 온프레미스 앱은 C/C++, C#, 엔터프라이즈 자바 등 전통적인 언어로 작성되는 경향이 있다. 클라우드 네이티브 앱은 웹 중심의 언어로 쓰여지는 경향이 있고, 예를 들어 HTML, CSS, 자바, 자바스크립트, .NET, 고(Go), 노드닷제이에스(Node.js), PHP, 파이썬, 루비 등이다. 현대적인 언어와 플랫폼을 이용한다면 최고의 엔지니어를 조직에 유입시키는 데 유리하다. 

업데이트 속성. 클라우드 네이티브 앱은 가용성이 매우 높고, 탄력적이고, 정기적인 업데이트가 가능하도록 제작되지만, 온프레미스 애플리케이션은 폭포수 방법론을 이용해 1년에 1회 또는 2회 업데이트되는 것이 보통이다. 클라우드 컴퓨팅의 업데이트 속성은 생산성 향상을 가져와 개발 팀은 자신의 경쟁 우위에 집중할 수 있고 새 기능을 과거보다 더 자주 배포할 수 있다. 

탄력성. 클라우드 네이티브 애플리케이션은 흔히 클라우드의 탄력성을 바탕으로 수요에 따라 소비를 조정하지만 온프레미스 애플리케이션이 효과적인 규모 조정을 하려면 추가 인프라의 물리적 프로비저닝이 요구되곤 했다. 비용 측면의 함의도 갖는다. 클라우드는 사용한만큼 요금을 지불하고, 자체 인프라가 높은 예산을 들여 초과 프로비저닝되는 것을 피할 수 있다. 

멀티테넌시(Multitenancy). 클라우드 네이티브 앱은 가상 공간에서 작업하고 멀티테넌시 모델을 이용해 다른 애플리케이션과 리소스를 공유하는 데 문제가 없다. 개발 팀에 명백한 능률 향상을 가져온다. 

다운타임(Downtime). 클라우드는 하이퍼스케일 클라우드 사업자가 관리하는 데이터센터의 규모 및 지리적 분산에 의해 가외성을 제공한다. 따라서 트래픽을 다른 지역으로 신속히 리다이렉트해 값비싼 다운타임을 피할 수 있기 때문에 중지 시간을 더 원활하게 관리할 수 있다. 

자동화(Automation). 클라우드 네이티브 기술은 엔지니어가 한번 구축하고 다른 급박한 과제로 옮겨갈 수 있는 풍성한 자동화 기회를 열었다. 

스테이트리스(Stateless). 클라우드 네이티브 애플리케이션은 스테이트리스인 경향이 있다. 이들은 저장된 데이터를 한 세션에서 다른 세션으로 이월시키지 않는다. 스테이트리스 모델은 여러 서버에 걸쳐 간단히 확장/축소할 수 있고, 성능 향상을 위해 한층 용이하게 캐시 메모리를 이용할 수 있고, 더 적은 스토리지를 차지하고, 특정 서버에 결착되지 않음으로써 업체 종속도 피할 수 있다. 
 

클라우드 네이티브의 과제 

기존의 온프레미스 애플리케이션을 클라우드 네이티브로 리프트 앤 시프트(마이그레이션)하는 것은 흔히 있는 실수다. 아키텍처의 문제가 발생할 수밖에 없기 때문이다. 그러나 클라우드를 위해 아키텍처를 변경하는 일 역시 그 자체로 까다로운 엔지니어링 과제이다. 

적절한 혼합 스킬을 발견하고, 클라우드 보안 모델에 적응하고, 클라우드 환경의 변화하는 비용 프로파일을 관리하는 일도 클라우드 네이티브를 추진하는 조직이 겪는 대표적인 난제들이다. 

그러나 개발자는 클라우드 네이티브를 하나의 조직 원리로서 수용해나가야 한다. 클라우드를 위한 새 애플리케이션을 구축한다든지, 아니라면 기존의 단일형 애플리케이션을 마이크로서비스로 분할해 클라우드 환경에 더 적합하도록 만들어야 한다.
 
따라서 전통적인 폭포수 전개로부터 탈피해 기민한 개발 원리, 다시 말해 최소 기능 제품(Minimum Viable Product, MVP) 개발 등으로 나아가는 대대적인 사고 방식의 변화가 요구될 것이다. 그러면서 자동화, 다변수 테스팅, 신속 이터레이션, 관측성 등을 수용하고 데브옵스 모델 안에서 운영 팀과 긴밀히 협력해야 한다. editor@itworld.co.kr