클라우드 네이티브 애플리케이션: 빠른 전달, 위험 감소, 비즈니스 성장

공유

클라우드 네이티브 애플리케이션이란?

클라우드 네이티브는 클라우드 컴퓨팅 모델의 장점을 모두 활용하는 애플리케이션을 개발하고 실행하기 위한 접근 방식입니다. 클라우드는 엔터프라이즈 데이터 센터를 운영할 자본 투자와 직원에 대한 집중도를 제거하는 대신 무한한 주문형 및 종량제 컴퓨팅 능력을 대체해 넣음으로써 실질적으로 모든 업계를 망라해 경쟁 패러다임을 재정의했습니다. IT 비용 감소란 경쟁 우위를 동반한 진입 장벽이 낮아져 팀이 시장에 신규 아이디어를 선보일 수 있는 속도가 기능의 한 부분이 된다는 의미입니다. 그렇기 때문에 소프트웨어가 세상을 집어삼키고 있는 것이고, 스타트업 단계에서 클라우드 네이티브 접근 방식을 사용해 기존의 업계를 파괴하는 것입니다.

그러나 조직에는 DevOps 개념, 지속적인 전달, 마이크로서비스, 컨테이너를 자동화하고 통합할 클라우드 네이티브 애플리케이션과 서비스를 구축하고 운영할 플랫폼이 필요합니다.





DevOps는 소프트웨어 전달과 인프라스트럭처 변경 프로세스 자동화를 목표로 소프트웨어 개발자와 IT 운영자가 협업한 결과물입니다. DevOps는 좀더 신뢰성 있는 소프트웨어 생성, 테스트, 릴리스를 신속하게 자주 진행할 수 있는 문화와 환경을 만듭니다.

지속적인 전달 방식으로 개별 애플리케이션을 변경하면 다른 변경 사항과 함께 하나의 릴리스나 유지 관리 창 등의 이벤트에 통합해 들어갈 때까지 기다리지 않고 준비되는 즉시 릴리스할 수 있습니다. 지속적인 전달 방식은 릴리스 작업을 단조롭고 신뢰 가능하게 만들어 주므로 조직은 최종 배포본이 비즈니스 프로세스와 엔터프라이즈 경쟁력의 일부로 통합될 때까지 위험이 낮은 상황에서 자주 전달하고 최종 사용자들로부터 빠르게 피드백을 얻을 수 있습니다.

마이크로서비스는 소규모 서비스 집합의 일부로서 애플리케이션을 개발하려는 아키텍처형 접근 방식입니다. 각 서비스는 비즈니스 성능을 구현하고, 해당 프로세스에서 실행되며, HTTP API를 통해 통신합니다. 각 마이크로서비스는 보통 자동화 시스템의 일부인 애플리케이션에서 다른 서비스를 독립적으로 배포, 업그레이드, 크기 조정, 재시작할 수 있으므로 최종 사용자에 영향을 미치지 않고 운영 중인 애플리케이션을 자주 업데이트할 수 있습니다.

컨테이너는 가상 머신 (VM)과 비교했을 때 효율성과 속도를 모두 제공합니다. 운영 시스템 (OS) 레벨의 가상화를 사용하는 경우 단일 OS 인스턴스는 하나 이상의 격리된 컨테이너에 동적으로 분리되고, 각 컨테이너에는 고유한 쓰기 가능 파일 시스템과 리소스 할당량이 있습니다. 단일 VM에 높은 패킹 밀도로 결합된 컨테이너들을 제작하고 파괴하는 등의 낮은 오버헤드는 컨테이너를 완벽한 개별 마이크로서비스 배포 수단으로 만들어 줍니다.


“우리가 배운 것 중에는 좀더 빠르게 시장에 선보일 수 없다면 우리가 얼마나 잘 엔지니어링했거나 빌드했거나 배포했거나 사람들을 교육했거나 간에 의심의 여지 없이 시장은 이미 변경되어 있을 것이라는 점입니다. 단지 조금, 그런데 너무 늦었기 때문에 괜찮을 수가 없지요.“

James McGlennon
Liberty Mutual Insurance Group 최고 경영 부사장겸 CIO



클라우드 네이티브 애플리케이션의 중요성

클라우드 네이티브 애플리케이션은 클라우드 모델에 사용할 목적으로 구현됩니다. 소규모의 전담 기능 팀들이 쉬운 확장성과 하드웨어 결합성을 제공하는 플랫폼에 빠른 주기 내에 구현하고 배포한 클라우드 네이티브 애플리케이션은 조직에 클라우드 전반에 대해 더 훌륭한 수준의 민첩성, 회복성, 이동성을 제공합니다.

경쟁 우위 확보

클라우드 네이티브란 클라우드 목표를 IT 비용 절감에서 비즈니스 성장 엔진으로 바꾼다는 의미입니다. 소프트웨어 시대에는 고객의 요구에 부응해 신속하게 애플리케이션을 구현하고 전달할 수 있는 비즈니스가 업계를 장악할 것입니다. 일단 전달된 애플리케이션은 상시 실행되는 탄력적 규모의 서비스를 실행해야 합니다.

유연성

기업은 어떠한 클라우드에서도 수정없이 실행될 애플리케이션을 빌드할 수 있습니다. 팀은 비즈니스 우선 순위를 맞추고 클라우드 가격을 최적화하기 위해 다양한 클라우드 업체들과 개인 클라우드에 마이그레이션하거나 배포할 능력을 유지할 수 있습니다.

개발자들에게 최선의 동기 부여

클라우드 네이티브 애플리케이션을 수용한 팀은 개발자들을 여러 클라우드 인프라스트럭처에서 실행되고 크기를 조정하기 위해 코드를 작성하는 오버헤드를 차단하고 오로지 고객 가치를 전할 코드 작성에 집중시킵니다. 서비스 표준 설정을 주장하는 표준 개발자 스택의 12대 요인 앱은 기본 클라우드 네이티브 플랫폼을 완전히 이용할 수 있도록 표준 개발자 ‘계약’을 제시합니다.

운영과 비즈니스 정렬

기업은 IT 운영을 자동화함으로써 Lean 체제로 변환해 전담 팀을 비즈니스 우선 순위가 높은 곳에 배치할 수 있습니다. 인간의 실수에 따른 오류 위험을 제거함에 따라 직원은 지루한 루틴 관리 작업 대신 프로세스 개선에 집중할 수 있습니다. 모든 레벨의 스택에서 자동으로 라이브 패치와 업그레이드되므로 중지 시간 자체가 사라지고 운영 전문가의 ‘구식' 기술이 필요하지 않게 됩니다.


차이점 비교: 클라우드 네이티브 vs 기존의 엔터프라이즈 애플리케이션
클라우드 네이티브 애플리케이션
기존의 엔터프라이즈 애플리케이션
예측 가능. 클라우드 네이티브 애플리케이션은 예측 가능한 행위를 통해 회복력을 극대화하도록 디자인된 프레임워크나 “계약"을 준수합니다. 클라우드 플랫폼에 사용된 자동화율이 높은 컨테이너 중심 인프라스트럭처는 소프트웨어 작성 방식을 추진합니다. 처음에 12 Factor 앱으로 기록된 12 원칙은 그와 같은 “계약"의 좋은 사례입니다. 예측 불가능. 기존의 애플리케이션은 아키텍처나 개발 방식으로 인해 클라우드 네이티브 플랫폼 실행에 따른 혜택을 모두 누릴 수 가 없습니다. 이 경우 흔히 빌드 시간이 오래 걸리고 용량이 큰 배치 파일 상태로 릴리스되어 점진적인 확장만 가능하며 오류 요인도 많아집니다.
OS 추상화. 클라우드 네이티브 애플리케이션 아키텍처에서 개발자는 애플리케이션의 간편한 이동과 크기 조정을 위해 플랫폼을 기본 인프라스트럭처 종속성을 무시하는 수단으로 사용할 것을 요구합니다. 가장 효율적인 추상화 수단은 형식적 플랫폼입니다. 예를 들어 Pivotal Cloud Foundry는 Google Cloud Platform (GCP), Microsoft Azure, 또는 Amazon Web Services (AWS)같은 클라우드 기반 인프라스트럭처에서 운영하기 적절합니다. OS 종속적. 개발자들은 기존의 애플리케이션 아키텍처를 사용해 애플리케이션과 기본 OS, 하드웨어, 스토리지, 지원 서비스 간에 밀접한 종속성을 구축할 수 있습니다. 이러한 종속성 때문에 새로운 인프라스트럭처에 애플리케이션을 이동하고 크기를 조정하는 작업은 클라우드 모델에 수행하는 것에 비해 복잡하고 위험하게 됩니다.
적정 용량. 클라우드 네이티브 애플리케이션 플랫폼은 지속적인 애플리케이션의 요구를 기반으로 배포 시에 인프라스트럭처 프로비저닝과 구성, 리소스의 동적 할당 및 재할당을 자동화합니다. 클라우드 네이티브 런타임에 빌드하면 요구를 충족시키기 위한 크기 조정, 리소스 사용, 가용 리소스 간의 오케스트레이션, 중지 시간 최소화를 위한 오류 복구 등을 포함해 애플리케이션 수명 주기 관리를 최적화합니다. 용량 과다. 전통적인 IT는 애플리케이션 전용의 맞춤형 인프라스트럭처 솔루션 (“눈송이”)을 설계하므로 해당 애플리케이션의 배포가 지연됩니다. 수요 충족분 이상의 확장 여유분이 거의 없는 최저 용량 추정치에 기준했을 때 솔루션은 흔히 용량 과다 상태입니다.
공동 작업. 사람, 프로세스, 도구의 결합체로서 개발자와 운영자 간의 긴밀한 협업을 가능하게 하는 DevOps는 클라우드 네이티브를 통해 완성된 애플리케이션 코드를 신속하고 매끄럽게 프로덕션으로 전환시킬 수 있습니다. 사일로 방식. 기존의 IT는 개발자가 운영자에게 완성된 애플리케이션 코드를 ‘다짜고짜 떠넘기면’ 그것을 받아 프로덕션 환경에서 실행하는 방식으로 운영됩니다. 조직의 우선 순위는 고객의 가치를 우선하므로 내부 충돌, 절충을 거쳐 늦어진 전달, 직원의 사기 저하 등의 문제가 발생합니다.
지속적인 전달. IT 팀은 개별 소프트웨어 업데이트를 준비되는 동시에 릴리스할 수 있습니다. 신속하게 소프트웨어를 릴리스하는 조직은 좀더 엄격한 피드백 순환을 거치므로 고객의 요구에 더 효과적으로 응답할 수 있습니다. 지속적인 전달은 테스트 중심 개발과 지속적인 통합을 포함한 기타 관련 접근 방식들과 가장 잘 어울립니다. 폭포수형 개발. IT 팀은 보통 수주나 수개월 마다 주기적으로 소프트웨어를 릴리스합니다. 이때 다수의 구성 요소가 이미 완성되어 있고 인위적인 릴리스 수단 이외에 다른 종속성이라고는 없을지라도 코드가 ‘릴리스'에 빌드되어야 릴리스됩니다. 고객들이 원하는 기능들은 지연되고 비즈니스는 경쟁력을 확보해 고객을 끌어들이고 수익을 창출할 기회를 상실합니다.
독립성. 마이크로서비스 아키텍처는 애플리케이션을 느슨하게 결합되어 독립적으로 운영되는 소규모 서비스로 분해합니다. 이렇게 분해된 서비스들은 더 작고 독립된 개발 팀에 지정되어 다른 서비스에 영향을 주지 않으면서도 빈번하고 독립적인 업데이트, 크기 조정, 장애 조치/재시작 가능합니다. 종속성. 모놀리식 아키텍처에는 많은 이질적인 서비스들을 하나의 배포 패키지로 구성했기 때문에 서비스 간에 불필요한 종속성이 야기되어 개발 및 배포 도중 민첩성을 상실하게 됩니다.
자동화된 확장성. 크기와 무관한 인프라스트럭처 자동화는 인간의 실수에 따른 중지 시간을 없앱니다. 컴퓨터 자동화는 그와 같은 문제가 전혀 없으며 배포 크기와 상관없이 동일한 규칙을 일관되게 적용합니다. 또한 클라우드 네이티브는 기존의 가상 오케스트레이션 위에 구축된 임시 자동화 수준을 넘어 섭니다. 완전한 클라우드 네이티브 아키텍처에는 팀에 맞춤형 자동화를 요구하는 대신 팀을 위해 작동하는 자동화와 오케스트레이션이 이미 포함되어 있습니다. 즉, 자동화 기능을 통해 관리하기 편한 애플리케이션을 쉽게 구축하고 실행할 수 있습니다. 수동 크기 조정. 수동 인프라스트럭처에는 수동으로 직접 서버, 네트워크, 스토리지 구성을 담당하고 관리하는 운영 직원이 있습니다. 운영자는 크기와는 무관하게 올바른 문제 진단에 늦고, 또한 크기와 무관하게 복잡도로 인해 적절한 구현에 실패합니다. 손으로 직접 작성한 코드에는 잠재적으로 인프라스트럭처에 인적 오류가 발생할 가능성이 있습니다.
빠른 복구. 컨테이너 실행 시간과 오케스트레이터는 VM 상위에 동적인 고밀도 가상 오버레이를 제공하며, 이는 호스팅 마이크로서비스와 이상적으로 어울립니다. 오케스트레이션은 VM 클러스터의 컨테이너 배치를 동적으로 관리하므로 오류 발생 시에 탄력적인 크기 조정과 복구/재시작 기능을 제공합니다. 느린 복구. 개별 VM은 시작/중지가 느리고 애플리케이션 코드를 배포하기 전에도 이미 거대한 오버헤드가 있기 때문에 VM 기반 인프라스트럭처는 마이크로서비스 기반 애플리케이션에 느리고 비효율적인 파운데이션입니다.


클라우드 네이티브 애플리케이션 고려 시 염두에 두십시오.

운영은 클라우드 네이티브 세상에서 변환되어야 합니다.

운영팀은 현재 상황 유지자에서 프로세스 개선과 자동화 챔피언에 등극해 비즈니스에 직접 가치를 전달하게 됩니다. 클라우드 네이티브 플랫폼은 1일차에 릴리스되고 2일차에 애플리케이션을 운영하며 이전에 수동 개입이 필요했던 문제들에 대해 자동으로 모니터링하고 수정합니다.

작업에 우선 순위를 두어야 합니다.

모든 작업을 클라우드 네이티브로 변환하지 않아도 됩니다. 비즈니스 및 IT 전문가들은 협업하여 기존 작업과 개발 가능한 작업의 우선 순위를 정해 기술적 타당성, 전략적 중요도, 그에 따른 각 사례별 클라우드 네이티브 방향에 대한 ROI를 결정해야 합니다. 미개발 영역의 개발뿐만 아니라 다양한 플랫폼 재구성 패턴들을 사용해 이러한 평가를 돕습니다.

개발자들이 계약에 따라 코드를 작성해야 합니다.

클라우드 네이티브 플랫폼의 혜택을 누리기 위해 개발자들은 기꺼이 12대 원칙과 플랫폼 및 서비스 표준을 준수하기 위해 더 많은 규칙을 요구할 것입니다. 이는 분명 과거 그들이 관례화해 놓은 전권 위임에 대해 변경을 가져올 수 있습니다. 그러나 어떠한 저항도 클라우드 네이티브 플랫폼이 제공하는 혜택을 경감시킬 수는 없습니다.

플랫폼이 필요하다면 개발하겠습니까? 구입하겠습니까?

많은 팀들이 오픈 소스 자동화와 컨테이너 기술을 결합해 그들만의 플랫폼을 구축하고 있습니다. 그러나 얼마 못가서 애초에 예상했던 것보다 많은 구성 요소가 필요하게 되고, 필요한 구성 요소의 대부분은 애초에 디자인에 포함되어 있지도 않았기에 구축하는 애플리케이션을 실제 구동하기 위한 그들의 노력은 지연되기 시작합니다. 여기에 더해 일단 팀이 플랫폼 작업을 시작하면 그것을 유지 관리해야 한다는 사실도 간과할 수 없습니다. 이러한 경우와 Pivotal Cloud Foundry처럼 입증된 통합형 플랫폼 사용을 비교해 보십시오. 팀은 플랫폼의 운영 및 인프라스트럭처 관리 능력을 확신한 상태에서 첫날부터 비즈니스 중심의 애플리케이션 구축에 집중할 수 있습니다.

혼자 하지 마십시오.

예를 들어 Pivotal Labs과 협업하는 동안 몰입해 학습하면 지속적인 전달 등과 같은 Agile 제품 개발 실무팀에 온전히 적응하게 되고 새로운 개발 진행을 보강해갈 수 있습니다. 이 모델에 대한 정보는 사방에 널렸습니다. 시험삼아 써보십시오. 조직의 민첩성이 충분하지 않다고 느끼는 직원이 75%에 이른다면 팀이 새로운 것을 시도하는 것은 기회입니다.




Next
Pivotal Perspectives