2018.06.18

현대적인 소프트웨어 개발 방법 ‘클라우드 네이티브’의 정의와 특징

Andy Patrizio | InfoWorld
“클라우드 네이티브”라는 용어가 특히 클라우드 제공업체들 사이에서 자주 거론된다. 2015년 리눅스 재단은 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)라는 이름의 조직까지 출범했다.

‘클라우드 네이티브’의 정의
일반적인 의미에서 “클라우드 네이티브”는 클라우드 컴퓨팅 제공 모델의 이점을 활용하는 애플리케이션 구축 및 실행 접근 방법이다. “클라우드 네이티브”의 핵심은 애플리케이션을 어떻게 만들고 배포하는지에 있으며 위치는 중요하지 않다. 클라우드 네이티브는 구내 데이터센터와 달리 애플리케이션이 퍼블릭 클라우드에 위치함을 암시한다.

CNCF가 정의하는 “클라우드 네이티브”의 의미는 조금 더 좁아서, 컨테이너화되는 오픈소스 소프트웨어 스택을 사용하는 것을 의미한다. 여기서 애플리케이션의 각 부분은 자체 컨테이너에 패키징되고 동적 오케스트레이션을 통해 각 부분이 적극적으로 스케줄링 및 관리되어 리소스 사용률을 최적화하며, 마이크로서비스 지향성을 통해 애플리케이션의 전체적인 민첩성과 유지 관리 편의성을 높인다.



컨설팅 업체 딜로이트의 마이크 캐비스 이사는 “클라우드 네이티브 앱은 현대의 클라우드 컴퓨팅 플랫폼에 필요한 탄력적이고 분산된 방식으로 실행되도록 설계된다”면서 “이러한 앱은 느슨하게 결합된다. 즉, 코드가 인프라 구성 요소에 고정되지 않으므로 수요에 따라 앱을 확장, 축소할 수 있고 불변적 인프라 개념을 포용할 수 있다. 일반적으로 이러한 아키텍처는 마이크로서비스를 사용해서 구축되지만 꼭 그래야 하는 것은 아니다”라고 말했다.

클라우드 서비스 제공업체 스플렁크(Splunk)의 최고 기술 지지자인 앤디 맨은 클라우드 네이티브 애플리케이션의 가장 큰 차이점은 애플리케이션을 구축, 제공, 운영하는 방식에 있다면서 “클라우드 서비스를 활용한다는 것은 컨테이너와 같이 민첩하고 확장 가능한 구성 요소를 사용해서 재사용 가능한 개별적인 기능을 제공하는 것을 의미한다. 이러한 기능은 멀티 클라우드와 같은 여러 기술 경계 간에 매끄럽게 통합되므로 제공 팀이 반복 가능한 자동화와 오케스트레이션을 사용해서 빠르게 작업 과정을 반복할 수 있다”고 말했다.

클라우드 네이티브 앱 개발에는 일반적으로 데브옵스, 애자일 방법론, 마이크로서비스, 클라우드 플랫폼, 쿠버네티스 및 도커와 같은 컨테이너, 그리고 지속적 제공이 포함된다. 간단히 말해 새롭고 현대적인 모든 애플리케이션 배포 방법이 사용된다.

따라서 플랫폼 서비스(PaaS) 모델을 사용하는 편이 가장 바람직하다. 필수는 아니지만 PaaS를 사용하면 여러 가지가 훨씬 더 쉬워진다. 클라우드 고객의 대다수는 기반 하드웨어에서 앱을 추상화하는 데 도움이 되는 인프라 서비스(IaaS)로 시작한다. 그러나 PaaS는 부가적인 계층을 추가해서 기반 OS를 추상화하므로 기업은 OS 호출에 대해 신경 쓸 필요 없이 앱의 비즈니스 논리에 온전히 집중할 수 있다.

클라우드 네이티브와 구내 애플리케이션의 차이점
클라우드 네이티브 애플리케이션 개발을 위해서는 전통적인 엔터프라이즈 애플리케이션과는 상당히 다른 아키텍처가 필요하다.

언어
회사 서버에서 실행되도록 만들어진 구내 앱은 윈도우 서버 플랫폼과 엔터프라이즈 자바에 배포되는 경우 C/C++, C# 또는 기타 비주얼 스튜디오 언어와 같은 전통적인 언어로 작성되는 경향이 있다. 메인프레임에서는 보통 코볼이 사용된다.

클라우드 네이티브 앱은 웹 중심 언어로 작성되는 경우가 많다. HTML, CSS, 자바, 자바스크립트, 닷넷, 고, Node.js, PHP, 파이썬, 루비 등이 해당된다.

업데이트 편의성
클라우드 네이티브 앱은 항상 최신 상태를 유지한다. 클라우드 네이티브 앱은 항상 가용성을 유지한다.

구내 앱은 업데이트가 필요하며 보통 벤더에서 구독(subscription) 방식으로 제공하고 업데이트 설치 동안 다운타임이 필요하다.

탄력성
클라우드 네이티브 앱은 사용량이 높은 시간 동안 리소스 사용량을 늘리는 방법으로 클라우드의 탄력성을 활용한다. 클라우드 기반 전자상거래 앱의 사용량이 폭증하는 경우 부가적인 컴퓨팅 리소스를 사용하다가 사용량이 줄어들면 추가된 리소스를 끌 수 있다. 클라우드 네이티브 앱은 필요에 따라 리소스의 규모의 증가에 맞춰 조절이 가능하다.

구내 앱은 동적으로 확장할 수 없다.

멀티테넌시(Multitenancy)
클라우드 네이티브 앱은 아무 문제없이 가상화된 공간에서 작업하고 다른 앱과 리소스를 공유할 수 있다.

구내 앱은 가상환경에서 제대로 작동하지 않거나 아예 작동하지 않고, 가상화되지 않은 공간을 필요로 하는 경우가 많다.

연결된 리소스
구내 앱의 네트워크, 보안, 권한, 스토리지와 같은 네트워크 리소스 연결에는 융통성이 없다. 이러한 리소스의 상당수는 하드 코딩이 필요하며 어떤 부분이 이동되거나 변경되면 작동하지 않는다.

딜로이트의 캐비스는 “클라우드에서는 네트워크와 스토리지가 완전히 다르다. ‘리플랫폼(re-platforming)’이라는 용어는 일반적으로 앱이 클라우드에서 실행 가능하도록 네트워킹, 스토리지, 나아가 데이터베이스 기술의 변화를 수용하기 위한 작업을 의미한다”고 말했다.

다운타임
클라우드는 구내 환경보다 예비성이 더 높다. 한 클라우드 제공업체의 시스템이 중단되면 다른 지역에서 그 부분을 대신 맡을 수 있다.

구내 앱도 페일오버를 지원하는 경우가 있지만 서버가 다운되면 앱도 같이 다운될 가능성이 높다.

자동화
클라우드에서는 앱 관리를 포함한 많은 부분이 자동화된다. 스플렁크의 맨은 “클라우드 네이티브 제공의 이점, 특히 속도와 민첩성은 수동 개입 없이 필요에 따라 자동화 및 오케스트레이션 툴을 사용해 반복적으로 실행되는, 검증과 감사를 거친 안정적이고 잘 알려진 프로세스 기질에 크게 의존한다”고 말했다. 반복성, 셀프 서비스, 민첩성, 확장성, 감사 및 통제를 실현하기 위해 엔지니어는 두 번 이상 반복 수행하는 거의 모든 작업을 자동화하도록 노력해야 한다.

구내 앱은 수동으로 관리해야 한다.

모듈형 설계
구내 앱은 모놀리식으로 설계되는 경향이 있다. 물론 라이브러리로 일부 작업 부담을 전달하지만 본질적으로는 수많은 서브루틴이 있는 하나의 거대한 앱이다. 클라우드 네이티브 앱은 훨씬 더 모듈형으로 설계되며 많은 기능이 마이크로서비스로 분할된다. 따라서 필요 없을 때, 그리고 하나의 모듈에 업데이트를 적용해야 할 때 전체 앱이 아니라 그 모듈만 끌 수 있다.

무상태
클라우드는 느슨한 결합 특성으로 인해 앱이 인프라에 묶이지 않는다. 즉, 앱에 상태가 없다. 클라우드 네이티브 앱은 데이터베이스 또는 다른 외부 엔티티에 상태를 저장하므로 인스턴스가 자유롭게 오갈 수 있으며 그 상황에서도 앱은 여전히 애플리케이션의 작업 단위를 추적할 수 있다. 캐비스는 “느슨한 결합의 핵심이 이것이다. 인프라에 묶이지 않으므로 고도로 분산된 방식으로 앱을 실행하면서, 기반 인프라의 탄력적 특성과는 별개로 앱 상태를 유지할 수 있다”고 말했다.

대부분의 구내 앱은 상태가 있다. 즉, 앱의 상태를 코드가 실행되는 인프라에 저장한다. 이러한 이유로 서버 리소스를 추가할 때 앱에 장애가 발생할 수 있다.

클라우드 네이티브 컴퓨팅의 과제
맨은 고객이 저지르는 큰 실수 중 하나는 기존의 구내 앱을 클라우드로 그대로 들어 옮기려 하는 것이라면서 “기존 애플리케이션, 특히 모놀리식 레거시 애플리케이션을 클라우드 인프라로 옮기는 방식으로는 클라우드 네이티브의 핵심 기능을 활용하지 못한다”고 말했다.

대신 새 클라우드 네이티브 애플리케이션을 새로운 클라우드 인프라에 배치하거나 기존 모놀리식을 해체해서 클라우드 네이티브 원칙을 사용해 처음부터 리팩터링함으로써 새로운 방식으로 새로운 것을 할 방법을 찾아야 한다.

또한 기존 개발 방법을 버려야 한다. 폭포수 모델은 당연히 통하지 않고, 애자일 개발 방법조차 충분하지 않을 수 있다. 최소 존속 가능 제품(minimum viable product, MVP) 개발, 다변수 테스트, 빠른 반복과 같은 새로운 클라우드 네이티브 접근 방법을 도입하고 데브옵스 모델로 여러 조직 경계에 걸쳐 긴밀하게 공조해야 한다.

클라우드 네이티브가 되기 위한 조건에는 인프라 서비스, 자동화/오케스트레이션, 가상화, 컨테이너화, 마이크로서비스 아키텍처, 관찰 가능성을 포함한 많은 측면이 있다. 모든 요소는 새로운 작업 방식을 의미하며, 이는 새로운 방식을 배우면서 과거의 습관을 버리는 것을 의미한다. 신중하게 진행해 나가야 한다. editor@itworld.co.kr


2018.06.18

현대적인 소프트웨어 개발 방법 ‘클라우드 네이티브’의 정의와 특징

Andy Patrizio | InfoWorld
“클라우드 네이티브”라는 용어가 특히 클라우드 제공업체들 사이에서 자주 거론된다. 2015년 리눅스 재단은 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)라는 이름의 조직까지 출범했다.

‘클라우드 네이티브’의 정의
일반적인 의미에서 “클라우드 네이티브”는 클라우드 컴퓨팅 제공 모델의 이점을 활용하는 애플리케이션 구축 및 실행 접근 방법이다. “클라우드 네이티브”의 핵심은 애플리케이션을 어떻게 만들고 배포하는지에 있으며 위치는 중요하지 않다. 클라우드 네이티브는 구내 데이터센터와 달리 애플리케이션이 퍼블릭 클라우드에 위치함을 암시한다.

CNCF가 정의하는 “클라우드 네이티브”의 의미는 조금 더 좁아서, 컨테이너화되는 오픈소스 소프트웨어 스택을 사용하는 것을 의미한다. 여기서 애플리케이션의 각 부분은 자체 컨테이너에 패키징되고 동적 오케스트레이션을 통해 각 부분이 적극적으로 스케줄링 및 관리되어 리소스 사용률을 최적화하며, 마이크로서비스 지향성을 통해 애플리케이션의 전체적인 민첩성과 유지 관리 편의성을 높인다.



컨설팅 업체 딜로이트의 마이크 캐비스 이사는 “클라우드 네이티브 앱은 현대의 클라우드 컴퓨팅 플랫폼에 필요한 탄력적이고 분산된 방식으로 실행되도록 설계된다”면서 “이러한 앱은 느슨하게 결합된다. 즉, 코드가 인프라 구성 요소에 고정되지 않으므로 수요에 따라 앱을 확장, 축소할 수 있고 불변적 인프라 개념을 포용할 수 있다. 일반적으로 이러한 아키텍처는 마이크로서비스를 사용해서 구축되지만 꼭 그래야 하는 것은 아니다”라고 말했다.

클라우드 서비스 제공업체 스플렁크(Splunk)의 최고 기술 지지자인 앤디 맨은 클라우드 네이티브 애플리케이션의 가장 큰 차이점은 애플리케이션을 구축, 제공, 운영하는 방식에 있다면서 “클라우드 서비스를 활용한다는 것은 컨테이너와 같이 민첩하고 확장 가능한 구성 요소를 사용해서 재사용 가능한 개별적인 기능을 제공하는 것을 의미한다. 이러한 기능은 멀티 클라우드와 같은 여러 기술 경계 간에 매끄럽게 통합되므로 제공 팀이 반복 가능한 자동화와 오케스트레이션을 사용해서 빠르게 작업 과정을 반복할 수 있다”고 말했다.

클라우드 네이티브 앱 개발에는 일반적으로 데브옵스, 애자일 방법론, 마이크로서비스, 클라우드 플랫폼, 쿠버네티스 및 도커와 같은 컨테이너, 그리고 지속적 제공이 포함된다. 간단히 말해 새롭고 현대적인 모든 애플리케이션 배포 방법이 사용된다.

따라서 플랫폼 서비스(PaaS) 모델을 사용하는 편이 가장 바람직하다. 필수는 아니지만 PaaS를 사용하면 여러 가지가 훨씬 더 쉬워진다. 클라우드 고객의 대다수는 기반 하드웨어에서 앱을 추상화하는 데 도움이 되는 인프라 서비스(IaaS)로 시작한다. 그러나 PaaS는 부가적인 계층을 추가해서 기반 OS를 추상화하므로 기업은 OS 호출에 대해 신경 쓸 필요 없이 앱의 비즈니스 논리에 온전히 집중할 수 있다.

클라우드 네이티브와 구내 애플리케이션의 차이점
클라우드 네이티브 애플리케이션 개발을 위해서는 전통적인 엔터프라이즈 애플리케이션과는 상당히 다른 아키텍처가 필요하다.

언어
회사 서버에서 실행되도록 만들어진 구내 앱은 윈도우 서버 플랫폼과 엔터프라이즈 자바에 배포되는 경우 C/C++, C# 또는 기타 비주얼 스튜디오 언어와 같은 전통적인 언어로 작성되는 경향이 있다. 메인프레임에서는 보통 코볼이 사용된다.

클라우드 네이티브 앱은 웹 중심 언어로 작성되는 경우가 많다. HTML, CSS, 자바, 자바스크립트, 닷넷, 고, Node.js, PHP, 파이썬, 루비 등이 해당된다.

업데이트 편의성
클라우드 네이티브 앱은 항상 최신 상태를 유지한다. 클라우드 네이티브 앱은 항상 가용성을 유지한다.

구내 앱은 업데이트가 필요하며 보통 벤더에서 구독(subscription) 방식으로 제공하고 업데이트 설치 동안 다운타임이 필요하다.

탄력성
클라우드 네이티브 앱은 사용량이 높은 시간 동안 리소스 사용량을 늘리는 방법으로 클라우드의 탄력성을 활용한다. 클라우드 기반 전자상거래 앱의 사용량이 폭증하는 경우 부가적인 컴퓨팅 리소스를 사용하다가 사용량이 줄어들면 추가된 리소스를 끌 수 있다. 클라우드 네이티브 앱은 필요에 따라 리소스의 규모의 증가에 맞춰 조절이 가능하다.

구내 앱은 동적으로 확장할 수 없다.

멀티테넌시(Multitenancy)
클라우드 네이티브 앱은 아무 문제없이 가상화된 공간에서 작업하고 다른 앱과 리소스를 공유할 수 있다.

구내 앱은 가상환경에서 제대로 작동하지 않거나 아예 작동하지 않고, 가상화되지 않은 공간을 필요로 하는 경우가 많다.

연결된 리소스
구내 앱의 네트워크, 보안, 권한, 스토리지와 같은 네트워크 리소스 연결에는 융통성이 없다. 이러한 리소스의 상당수는 하드 코딩이 필요하며 어떤 부분이 이동되거나 변경되면 작동하지 않는다.

딜로이트의 캐비스는 “클라우드에서는 네트워크와 스토리지가 완전히 다르다. ‘리플랫폼(re-platforming)’이라는 용어는 일반적으로 앱이 클라우드에서 실행 가능하도록 네트워킹, 스토리지, 나아가 데이터베이스 기술의 변화를 수용하기 위한 작업을 의미한다”고 말했다.

다운타임
클라우드는 구내 환경보다 예비성이 더 높다. 한 클라우드 제공업체의 시스템이 중단되면 다른 지역에서 그 부분을 대신 맡을 수 있다.

구내 앱도 페일오버를 지원하는 경우가 있지만 서버가 다운되면 앱도 같이 다운될 가능성이 높다.

자동화
클라우드에서는 앱 관리를 포함한 많은 부분이 자동화된다. 스플렁크의 맨은 “클라우드 네이티브 제공의 이점, 특히 속도와 민첩성은 수동 개입 없이 필요에 따라 자동화 및 오케스트레이션 툴을 사용해 반복적으로 실행되는, 검증과 감사를 거친 안정적이고 잘 알려진 프로세스 기질에 크게 의존한다”고 말했다. 반복성, 셀프 서비스, 민첩성, 확장성, 감사 및 통제를 실현하기 위해 엔지니어는 두 번 이상 반복 수행하는 거의 모든 작업을 자동화하도록 노력해야 한다.

구내 앱은 수동으로 관리해야 한다.

모듈형 설계
구내 앱은 모놀리식으로 설계되는 경향이 있다. 물론 라이브러리로 일부 작업 부담을 전달하지만 본질적으로는 수많은 서브루틴이 있는 하나의 거대한 앱이다. 클라우드 네이티브 앱은 훨씬 더 모듈형으로 설계되며 많은 기능이 마이크로서비스로 분할된다. 따라서 필요 없을 때, 그리고 하나의 모듈에 업데이트를 적용해야 할 때 전체 앱이 아니라 그 모듈만 끌 수 있다.

무상태
클라우드는 느슨한 결합 특성으로 인해 앱이 인프라에 묶이지 않는다. 즉, 앱에 상태가 없다. 클라우드 네이티브 앱은 데이터베이스 또는 다른 외부 엔티티에 상태를 저장하므로 인스턴스가 자유롭게 오갈 수 있으며 그 상황에서도 앱은 여전히 애플리케이션의 작업 단위를 추적할 수 있다. 캐비스는 “느슨한 결합의 핵심이 이것이다. 인프라에 묶이지 않으므로 고도로 분산된 방식으로 앱을 실행하면서, 기반 인프라의 탄력적 특성과는 별개로 앱 상태를 유지할 수 있다”고 말했다.

대부분의 구내 앱은 상태가 있다. 즉, 앱의 상태를 코드가 실행되는 인프라에 저장한다. 이러한 이유로 서버 리소스를 추가할 때 앱에 장애가 발생할 수 있다.

클라우드 네이티브 컴퓨팅의 과제
맨은 고객이 저지르는 큰 실수 중 하나는 기존의 구내 앱을 클라우드로 그대로 들어 옮기려 하는 것이라면서 “기존 애플리케이션, 특히 모놀리식 레거시 애플리케이션을 클라우드 인프라로 옮기는 방식으로는 클라우드 네이티브의 핵심 기능을 활용하지 못한다”고 말했다.

대신 새 클라우드 네이티브 애플리케이션을 새로운 클라우드 인프라에 배치하거나 기존 모놀리식을 해체해서 클라우드 네이티브 원칙을 사용해 처음부터 리팩터링함으로써 새로운 방식으로 새로운 것을 할 방법을 찾아야 한다.

또한 기존 개발 방법을 버려야 한다. 폭포수 모델은 당연히 통하지 않고, 애자일 개발 방법조차 충분하지 않을 수 있다. 최소 존속 가능 제품(minimum viable product, MVP) 개발, 다변수 테스트, 빠른 반복과 같은 새로운 클라우드 네이티브 접근 방법을 도입하고 데브옵스 모델로 여러 조직 경계에 걸쳐 긴밀하게 공조해야 한다.

클라우드 네이티브가 되기 위한 조건에는 인프라 서비스, 자동화/오케스트레이션, 가상화, 컨테이너화, 마이크로서비스 아키텍처, 관찰 가능성을 포함한 많은 측면이 있다. 모든 요소는 새로운 작업 방식을 의미하며, 이는 새로운 방식을 배우면서 과거의 습관을 버리는 것을 의미한다. 신중하게 진행해 나가야 한다. editor@itworld.co.kr


X