2018.11.26

‘모든 면에서’ 클라우드 네이티브 앱이 더 나은 이유 9가지

BrandPost Sponsored by Pivotal Brandpost
Pivotal | Pivotal
ⓒ Pivotal

예측 가능 Vs. 예측 불가능

클라우드 네이티브 애플리케이션은 예측 가능한 행위를 통해 회복력을 극대화할 수 있도록 디자인된 프레임 워크나 ‘계약’을 준수한다. 클라우드 플랫폼에 사용된 자동화율이 높은 컨테이너 중심 인프라는 소프트웨어 작성 방식을 추진한다. 초기에 12 Factor 앱으로 기록된 12원칙은 그와 같은 ‘계약’의 좋은 사례다.

반면, 기존의 애플리케이션은 아키텍처나 개발 방식으로 인해 클라우드 네이티브 플랫폼 실행에 따른 혜택을 모두 누릴 수가 없다. 이 경우 흔히 빌드 시간이 오래 걸리고 용량이 큰 배치 파일 상태로 릴리즈되어 점진적인 확장만 가능하며 오류 요인도 많아진다.

운영체제 추상화 Vs. 운영체제 종속
클라우드 네이티브 애플리케이션 아키텍처에서 개발자는 애플리케이션의 간편한 이전과 규모 조정을 위해 플랫폼을 기본 인프라 종속성을 무시하는 수단으로 사용할 것을 요구한다. 가장 효율적인 추상화 수단은 형식적 플랫폼이다. 예를 들어 피보탈 클라우드 파운드리(Pivotal Cloud Foundry)는 GCP(Google Cloud Platform), 마이크로소프트 애저, 또는 아마존 웹 서비스(Amazon Web Services, AWS)같은 클라우드 기반 인프라에서 운영하기 적합한 플랫폼이다.

반면, 기존의 엔터프라이즈 애플리케이션은 운영체제에 종속되기 쉽다.  기존 애플리케이션 아키텍처를 통한 시스템에서는 애플리케이션과 기본 운영체제, 하드웨어, 스토리지, 지원 서비스 간에 밀접한 종속성이 생성된다. 이런 종속성 때문에 새로운 인프라에 애플리케이션을 이동하고 규모를 조정하는 작업이 클라우드 모델보다 더 복잡하고 위험한 것이다.

적정 용량 Vs. 용량 과다
클라우드 네이티브 애플리케이션 플랫폼은 지속적인 애플리케이션의 요구를 기반으로 배포 시점과 동시에 인프라스트럭처 프로비저닝과 구성, 리소스의 동적 할당 및 재할당을 자동화한다. 클라우드 네이티브 런타임에 빌드하면, 기업 요구에 맞는 규모 조정, 리소스 사용, 가용 리소스 간의 오케스트레이션, 다운타임 최소화를 위한 오류 복구 등을 포함, 전체 애플리케이션 수명 주기 관리를 최적화한다.

그러나 전통적인 IT는 애플리케이션 전용으로 맞춤형 인프라스트럭처 솔루션을 설계하는 구조이므로 애플리케이션 배포는 자연히 늦어진다. 수요는 충족하지만 그 이상의 확장 여유분이 거의 없이 설계돼서, 최저 용량 추정치에 기준했을 때의 솔루션은 보통 용량 과다 상태이다.

공동 작업 Vs. 사일로 방식
데브옵스는 사람, 프로세스, 도구의 결합체로서 개발자와 운영자 간의 긴밀한 협업을 지원한다. 또, 클라우드 네이티브를 통해 완성된 애플리케이션 코드를 신속하고 매끄럽게 프로덕션으로 전환할 수 있다.

그러나 기존의 IT는 개발자가 운영자에게 완성된 애플리케이션 코드를 ‘다짜고짜 떠넘기면’ 그것을 받아 프로덕션 환경에서 실행하는 방식으로 운영된다. 조직의 우선 순위가 고객의 가치에 두므로, 내부 충돌, 절충을 거쳐 늦어진 전달, 직원의 사기 저하 등의 문제가 발생한다.

지속적 전달 Vs. 폭포수형 개발
IT 팀은 각각의 소프트웨어 업데이트 준비와 릴리즈를 동시에 진행할 수 있다. 신속하게 소프트웨어를 릴리즈하는 조직은 좀더 엄격한 피드백을 받기 때문에 고객의 요구에 더 효과적으로 응답할 수 있다. 지속적 전달은 테스트 중심 개발과 지속적 통합을 포함한 기타 접근 방식들과 가장 잘 어울린다.

하지만 기존의 IT 팀은 보통 주나 월 단위의 주기에 맞춰 소프트웨어를 릴리즈해야 한다. 이때 다수의 구성 요소가 이미 완성되어 있고 인위적인 릴리즈 수단 이외에 다른 종속성이 없을 경우에도, 코드가 ‘릴리즈'에 빌드되어야 최종적으로 릴리즈될 수 있다. 자연히 고객이 원하는 기능은 지연되고, 기업은 경쟁력을 확보해 고객을 끌어들이고 수익을 창출할 기회를 상실하게 된다.

독립성 Vs. 종속성
마이크로서비스 아키텍처는 애플리케이션을 느슨하게 결합되어 독립적으로 운영되는 소규모 서비스로 분해한다. 이렇게 분해된 서비스들은 더 작고 독립된 개발 팀에 지정되어 다른 서비스에 영향을 주지 않으면서도 빈번하고 독립적인 업데이트, 크기 조정, 장애 조치/재시작이 가능하다.

반면, 모놀리식 아키텍처는 많은 이질적인 서비스를 하나의 배포 패키지로 묶어 구성했기 때문에 서비스 간에 불필요한 종속성이 생겨 개발이나 배포 단계에서 민첩성을 상실한다.

자동화 스케일링 Vs. 수동 스케일링
인프라 자동화는 인간의 실수가 유발하는 다운타임을 없앤다. 컴퓨터 자동화에서는 배포 크기와 상관없이 동일한 규칙을 일관적으로 적용해 오류 가능성이라는 문제가 없다. 또한, 클라우드 네이티브는 기존의 가상 오케스트레이션 위에 구축된 임시 자동화 수준을 넘어선다. 완전한 클라우드 네이티브 아키텍처는 팀에 맞춤형 자동화를 요구하지 않고, 팀을 위해 작동하는 자동화와 오케스트레이션을 이미 갖추고 있다. 즉, 자동화 기능을 통해 관리하기 편한 애플리케이션을 쉽게 구축하고 실행할 수 있다.

수동 인프라는 수동으로 직접 서버, 네트워크, 스토리지 구성을 담당하고 관리하는 운영 직원을 두어야 한다. 규모와 상관없이, 운영자는 문제를 제때 진단하지 못하고, 또한 복잡도로 인해 규모에 맞는 적절한 구현을 할 수 없게 된다. 수기로 작성한 코드에는 인프라에 인적 오류가 발생할 가능성이 있다.

빠른 복구 Vs. 느린 복구
컨테이너 실행 시간과 오케스트레이터는 가상머신 위에 동적인 고밀도 가상 오버레이를 제공하며, 그래서 호스팅 마이크로서비스와 이상적인 관계다. 오케스트레이션은 가상머신 클러스터의 컨테이너 배치를 동적으로 관리하므로 오류가 발생해도 탄력적인 크기 조정과 복구/재시작 기능을 제공할 수 있다.

반면에 개별 가상머신은 시작/중지가 느리고 애플리케이션 코드를 배포하기 전에도 이미 오버헤드가 크기 때문에 가상머신 기반 인프라는 마이크로서비스 기반 애플리케이션에 비해 느리고 비효율적인 파운데이션이다.
 
ⓒPivotal


클라우드 네이티브 애플리케이션 고려 시 염두에 두어야 할 사항
클라우드 네이티브를 만나고 혁신되는 운영
운영팀은 현재 상황 유지 주의자에서 프로세스 개선과 자동화 챔피언으로 변화해 비즈니스에 직접 가치를 전달하게 된다. 클라우드 네이티브 플랫폼에서는 첫날에 릴리즈하고 이틀째에 애플리케이션을 운영할 수 있으며, 과거 수동 개입이 필요했던 문제를 자동으로 모니터링하고 수정할 수 있다.

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

계약에 따른 코드 작성
클라우드 네이티브 플랫폼의 혜택을 누리기 위해 개발자는 기꺼이 12대 원칙 준수를 위한 규칙을 요구하고, 플랫폼과 서비스를 표준화하려고 할 것이다. 분명 과거 개발자가 관례화한 권한 체계와 설정 변경을 따를 수 있다. 그러나 어떠한 저항도 클라우드 네이티브 플랫폼이 제공하는 혜택을 경감시킬 수는 없을 것이다.

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

혼자보다 협업
예를 들어 Pivotal Labs과 협업하는 동안 몰입해 학습하면 지속적인 전달 등과 같은 애자일(Agile) 제품 개발 실무팀에 온전히 적응하게 되고 새로운 개발 진행을 보강할 수 있다. 이 모델에 대한 정보도 넘쳐난다.  시험삼아 도입해보자. 조직의 민첩성이 충분하지 않다고 느끼는 직원이 75%에 이른다면, 새로운 시도는 그 자체로 새로운 기회다.


2018.11.26

‘모든 면에서’ 클라우드 네이티브 앱이 더 나은 이유 9가지

BrandPost Sponsored by Pivotal Brandpost
Pivotal | Pivotal
ⓒ Pivotal

예측 가능 Vs. 예측 불가능

클라우드 네이티브 애플리케이션은 예측 가능한 행위를 통해 회복력을 극대화할 수 있도록 디자인된 프레임 워크나 ‘계약’을 준수한다. 클라우드 플랫폼에 사용된 자동화율이 높은 컨테이너 중심 인프라는 소프트웨어 작성 방식을 추진한다. 초기에 12 Factor 앱으로 기록된 12원칙은 그와 같은 ‘계약’의 좋은 사례다.

반면, 기존의 애플리케이션은 아키텍처나 개발 방식으로 인해 클라우드 네이티브 플랫폼 실행에 따른 혜택을 모두 누릴 수가 없다. 이 경우 흔히 빌드 시간이 오래 걸리고 용량이 큰 배치 파일 상태로 릴리즈되어 점진적인 확장만 가능하며 오류 요인도 많아진다.

운영체제 추상화 Vs. 운영체제 종속
클라우드 네이티브 애플리케이션 아키텍처에서 개발자는 애플리케이션의 간편한 이전과 규모 조정을 위해 플랫폼을 기본 인프라 종속성을 무시하는 수단으로 사용할 것을 요구한다. 가장 효율적인 추상화 수단은 형식적 플랫폼이다. 예를 들어 피보탈 클라우드 파운드리(Pivotal Cloud Foundry)는 GCP(Google Cloud Platform), 마이크로소프트 애저, 또는 아마존 웹 서비스(Amazon Web Services, AWS)같은 클라우드 기반 인프라에서 운영하기 적합한 플랫폼이다.

반면, 기존의 엔터프라이즈 애플리케이션은 운영체제에 종속되기 쉽다.  기존 애플리케이션 아키텍처를 통한 시스템에서는 애플리케이션과 기본 운영체제, 하드웨어, 스토리지, 지원 서비스 간에 밀접한 종속성이 생성된다. 이런 종속성 때문에 새로운 인프라에 애플리케이션을 이동하고 규모를 조정하는 작업이 클라우드 모델보다 더 복잡하고 위험한 것이다.

적정 용량 Vs. 용량 과다
클라우드 네이티브 애플리케이션 플랫폼은 지속적인 애플리케이션의 요구를 기반으로 배포 시점과 동시에 인프라스트럭처 프로비저닝과 구성, 리소스의 동적 할당 및 재할당을 자동화한다. 클라우드 네이티브 런타임에 빌드하면, 기업 요구에 맞는 규모 조정, 리소스 사용, 가용 리소스 간의 오케스트레이션, 다운타임 최소화를 위한 오류 복구 등을 포함, 전체 애플리케이션 수명 주기 관리를 최적화한다.

그러나 전통적인 IT는 애플리케이션 전용으로 맞춤형 인프라스트럭처 솔루션을 설계하는 구조이므로 애플리케이션 배포는 자연히 늦어진다. 수요는 충족하지만 그 이상의 확장 여유분이 거의 없이 설계돼서, 최저 용량 추정치에 기준했을 때의 솔루션은 보통 용량 과다 상태이다.

공동 작업 Vs. 사일로 방식
데브옵스는 사람, 프로세스, 도구의 결합체로서 개발자와 운영자 간의 긴밀한 협업을 지원한다. 또, 클라우드 네이티브를 통해 완성된 애플리케이션 코드를 신속하고 매끄럽게 프로덕션으로 전환할 수 있다.

그러나 기존의 IT는 개발자가 운영자에게 완성된 애플리케이션 코드를 ‘다짜고짜 떠넘기면’ 그것을 받아 프로덕션 환경에서 실행하는 방식으로 운영된다. 조직의 우선 순위가 고객의 가치에 두므로, 내부 충돌, 절충을 거쳐 늦어진 전달, 직원의 사기 저하 등의 문제가 발생한다.

지속적 전달 Vs. 폭포수형 개발
IT 팀은 각각의 소프트웨어 업데이트 준비와 릴리즈를 동시에 진행할 수 있다. 신속하게 소프트웨어를 릴리즈하는 조직은 좀더 엄격한 피드백을 받기 때문에 고객의 요구에 더 효과적으로 응답할 수 있다. 지속적 전달은 테스트 중심 개발과 지속적 통합을 포함한 기타 접근 방식들과 가장 잘 어울린다.

하지만 기존의 IT 팀은 보통 주나 월 단위의 주기에 맞춰 소프트웨어를 릴리즈해야 한다. 이때 다수의 구성 요소가 이미 완성되어 있고 인위적인 릴리즈 수단 이외에 다른 종속성이 없을 경우에도, 코드가 ‘릴리즈'에 빌드되어야 최종적으로 릴리즈될 수 있다. 자연히 고객이 원하는 기능은 지연되고, 기업은 경쟁력을 확보해 고객을 끌어들이고 수익을 창출할 기회를 상실하게 된다.

독립성 Vs. 종속성
마이크로서비스 아키텍처는 애플리케이션을 느슨하게 결합되어 독립적으로 운영되는 소규모 서비스로 분해한다. 이렇게 분해된 서비스들은 더 작고 독립된 개발 팀에 지정되어 다른 서비스에 영향을 주지 않으면서도 빈번하고 독립적인 업데이트, 크기 조정, 장애 조치/재시작이 가능하다.

반면, 모놀리식 아키텍처는 많은 이질적인 서비스를 하나의 배포 패키지로 묶어 구성했기 때문에 서비스 간에 불필요한 종속성이 생겨 개발이나 배포 단계에서 민첩성을 상실한다.

자동화 스케일링 Vs. 수동 스케일링
인프라 자동화는 인간의 실수가 유발하는 다운타임을 없앤다. 컴퓨터 자동화에서는 배포 크기와 상관없이 동일한 규칙을 일관적으로 적용해 오류 가능성이라는 문제가 없다. 또한, 클라우드 네이티브는 기존의 가상 오케스트레이션 위에 구축된 임시 자동화 수준을 넘어선다. 완전한 클라우드 네이티브 아키텍처는 팀에 맞춤형 자동화를 요구하지 않고, 팀을 위해 작동하는 자동화와 오케스트레이션을 이미 갖추고 있다. 즉, 자동화 기능을 통해 관리하기 편한 애플리케이션을 쉽게 구축하고 실행할 수 있다.

수동 인프라는 수동으로 직접 서버, 네트워크, 스토리지 구성을 담당하고 관리하는 운영 직원을 두어야 한다. 규모와 상관없이, 운영자는 문제를 제때 진단하지 못하고, 또한 복잡도로 인해 규모에 맞는 적절한 구현을 할 수 없게 된다. 수기로 작성한 코드에는 인프라에 인적 오류가 발생할 가능성이 있다.

빠른 복구 Vs. 느린 복구
컨테이너 실행 시간과 오케스트레이터는 가상머신 위에 동적인 고밀도 가상 오버레이를 제공하며, 그래서 호스팅 마이크로서비스와 이상적인 관계다. 오케스트레이션은 가상머신 클러스터의 컨테이너 배치를 동적으로 관리하므로 오류가 발생해도 탄력적인 크기 조정과 복구/재시작 기능을 제공할 수 있다.

반면에 개별 가상머신은 시작/중지가 느리고 애플리케이션 코드를 배포하기 전에도 이미 오버헤드가 크기 때문에 가상머신 기반 인프라는 마이크로서비스 기반 애플리케이션에 비해 느리고 비효율적인 파운데이션이다.
 
ⓒPivotal


클라우드 네이티브 애플리케이션 고려 시 염두에 두어야 할 사항
클라우드 네이티브를 만나고 혁신되는 운영
운영팀은 현재 상황 유지 주의자에서 프로세스 개선과 자동화 챔피언으로 변화해 비즈니스에 직접 가치를 전달하게 된다. 클라우드 네이티브 플랫폼에서는 첫날에 릴리즈하고 이틀째에 애플리케이션을 운영할 수 있으며, 과거 수동 개입이 필요했던 문제를 자동으로 모니터링하고 수정할 수 있다.

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

계약에 따른 코드 작성
클라우드 네이티브 플랫폼의 혜택을 누리기 위해 개발자는 기꺼이 12대 원칙 준수를 위한 규칙을 요구하고, 플랫폼과 서비스를 표준화하려고 할 것이다. 분명 과거 개발자가 관례화한 권한 체계와 설정 변경을 따를 수 있다. 그러나 어떠한 저항도 클라우드 네이티브 플랫폼이 제공하는 혜택을 경감시킬 수는 없을 것이다.

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

혼자보다 협업
예를 들어 Pivotal Labs과 협업하는 동안 몰입해 학습하면 지속적인 전달 등과 같은 애자일(Agile) 제품 개발 실무팀에 온전히 적응하게 되고 새로운 개발 진행을 보강할 수 있다. 이 모델에 대한 정보도 넘쳐난다.  시험삼아 도입해보자. 조직의 민첩성이 충분하지 않다고 느끼는 직원이 75%에 이른다면, 새로운 시도는 그 자체로 새로운 기회다.


X