상명대학교 / 서광규 교수
2. 클라우드 네이티브 개요
2-1. 클라우드 네이티브 및 클라우드 네이티브 애플리케이션 소개
클라우드 네이티브는 소프트웨어 설계, 개발, 배포, 실행 및 관리 과정에서 클라우드 컴퓨팅의 기능을 최대한 활용하는 클라우드 컴퓨팅 기반 소프트웨어 방법론이다. 클라우드 네이티브는 특정 속성과 일련의 비기능적 특성을 가진 소프트웨어 설계 원칙으로 정의된다.
"클라우드 네이티브"라는 것은 응용 프로그램이 클라우드 컴퓨팅에서 성장하고 수명 주기가 가능한 한 클라우드 컴퓨팅 내에서 발생하며 특정 원칙을 따르고 일반적인 기술을 사용한다는 것을 의미한다. 클라우드 컴퓨팅은 애플리케이션 비즈니스 로직 코드를 제외하고 클라우드 인프라 기능, 플랫폼 기능, 보안, 유지 관리 등 애플리케이션 요구 사항에 대한 모든 것을 제공한다.
클라우드 네이티브의 목표는 애플리케이션 구축, 제공, 관리 및 최적화 속도를 높이고, 애플리케이션을 가볍고 유연하며 자동으로 만들고, 애플리케이션 개발자 및 유지관리자의 작업을 단순화하는 것이다.
클라우드 네이티브 애플리케이션은 클라우드 서비스의 기능과 환경 내에서 실행되고 이를 활용하도록 명시적으로 설계된 클라우드 애플리케이션 유형이다.
다음 그림은 전통적인 애플리케이션 개발과 클라우드 네이티브 방법론에 따른 클라우드 애플리케이션 개발 간의 차이점을 보여준다.
[그림2. 애플리케이션을 개발하고 관리하는 전통적인 방법]
애플리케이션 코드는 일반적으로 세 부분으로 구성된다.
- 핵심 비즈니스 로직을 구현하는 비즈니스 로직 코드
- 비즈니스 로직은 없지만 고객이 만든 애플리케이션의 상용 제품에 필요한 비즈니스 로직 기능(예: 경보, 로그, 보안, 신뢰성 등에 관한 코드)
- 코딩 라이브러리, 데이터베이스 소프트웨어, 방화벽 소프트웨어 등과 같이 응용 프로그램 기능을 구현하는 데 의존하는 타사 소프트웨어
그림에서 볼 수 있듯이 애플리케이션을 개발하는 전통적인 방식에서는 애플리케이션 개발자가 코드의 세 부분을 모두 작성한다. 전통적으로 개발된 애플리케이션을 관리하려면 애플리케이션 유지관리자가 필요하다.
인프라 관리, 애플리케이션 인스턴스 및 상태 관리, 애플리케이션 수명주기 관리 등을 포함하는 애플리케이션 수명주기 내의 모든 단계와 작업을 관리한다.
이러한 방식은 개발자와 유지관리자가 애플리케이션을 개발하고 관리하는 데 어려움을 겪는다. 그리고 애플리케이션이 성장하고 복잡해지고 애플리케이션 실행 환경이 다양해짐에 따라 애플리케이션 개발자와 유지관리자는 더 많은 기술을 확보해야 하므로 기술적 어려움과 인적 자원 비용이 증가한다.
[그림3. 클라우드 네이티브 방법론에 따라 클라우드 애플리케이션 개발 및 관리]
클라우드 네이티브 방식으로 클라우드 애플리케이션을 개발하는 경우 CSC 애플리케이션 개발자는 비즈니스 로직 코드를 작성하고 타사 소프트웨어 사용 방법을 명하게 하기만 하면 된다.
비즈니스 로직 기능과 타사 소프트웨어는 클라우드 컴퓨팅의 IaaS 및 PaaS를 통해 CSP에서 제공하고 관리한다. 이는 CSC 애플리케이션 개발자가 관심을 갖는 기술 범위를 줄이고 비즈니스 로직을 넘어서는 모든 복잡한 작업을 CSP에 맡긴다.
※ 참고 : CSP가 처리하는 비즈니스 로직 이상의 복잡한 작업에는 일반적으로 클라우드 서비스 제공, 신뢰성 보장, 처리 확장, 보안 관리, 소프트웨어 업그레이드, 호환성 관리, 다중 환경으로의 마이그레이션, 프로세스 자동화 등이 포함된다.
2-2. 클라우드 네이티브 애플리케이션을 달성하기 위한 원칙
클라우드 네이티브를 더 잘 달성하기 위해 클라우드 네이티브 애플리케이션을 설계, 개발, 배포, 실행 및 관리할 때 일반적으로 다음 원칙을 따른다.
- 관리형 클라우드 서비스 사용: 대부분의 CSP는 다양한 관리형 클라우드 서비스를 제공하므로 이러한 클라우드 서비스를 사용하면 애플리케이션 개발자 및 유지관리자가 백엔드 소프트웨어 또는 인프라를 관리하는 데 드는 수고가 줄어든다. 클라우드 네이티브가 되려면 애플리케이션이 먼저 클라우드 서비스를 사용한다.※ 참고 : 관리형 클라우드 서비스는 CSP가 부분적으로 또는 완전히 관리하는 클라우드 서비스이다. 관리 개체에는 클라우드 서비스 수명 주기, 구성, 최적화, 보안, 모니터링이 포함되지만 이에 국한되지는 않는다.
- 자동화를 위한 설계: 자동화는 클라우드 서비스 제공과 사용 모두의 핵심 기능이므로 클라우드 네이티브에서는 애플리케이션을 자동으로 테스트, 배포, 복구, 확장할 것을 제안한다. 애플리케이션이 성장하고 더 많은 클라우드 서비스를 사용함에 따라 애플리케이션 소프트웨어 통합, 테스트 및 제공의 복잡성이 증가한다. 애플리케이션 라이프사이클의 자동화를 통해 클라우드 네이티브의 더 많은 장점이 드러난다.
- 애플리케이션 상태 처리: 클라우드 네이티브에서는 애플리케이션 상태 데이터(예: 사용자 데이터, 비즈니스 컨텍스트 데이터)를 독립적인 데이터베이스에 저장하여 상태 비저장 애플리케이션 구성 요소를 최대한 설계하도록 제안한다. 상태 비저장을 사용하면 애플리케이션이 클라우드 컴퓨팅에서 쉽게 확장, 복구, 롤백, 로드 밸런싱 및 마이그레이션할 수 있다.
- 회복력 : 회복력은 비정상적인 상황을 방어하고 계속 실행하는 응용 프로그램의 능력이다. 클라우드 네이티브에는 애플리케이션 복원력이 필요하다. 이는 애플리케이션 개발자와 유지관리자가 애플리케이션의 자체 보호 및 중복성 설계를 고려한다는 의미이다.※ 참고 : 비정상적인 이벤트의 예로는 하드웨어 장애, 가상화 자원 장애, 자원 고갈, 소프트웨어 버그, 해킹, 업무 처리 능력 부족, 데이터 센터 정전 등이 있다.※ 참고 : 애플리케이션 자체 보호에는 애플리케이션의 상태, 성능 및 경고 모니터링, 실패한 작업 재시도, 작업량이 많은 경우 애플리케이션 구성 요소에 대한 액세스 제한, 실패 시 중단, 전달 전 테스트 등이 포함된다.
- 제로 트러스트: 기존 아키텍처의 애플리케이션은 일반적으로 액세스 엔터티를 "신뢰할 수 있는" 엔터티와 내부 공격 및 외부 위협에 취약한 "신뢰할 수 없는" 엔터티로 분리한다. 클라우드 네이티브는 모든 애플리케이션 구성 요소 간에 제로 트러스트 원칙을 실천한다. 즉, 모든 애플리케이션 구성 요소가 자체 보안과 복원력을 보장하고 외부 엔터티에 제로 트러스트를 제공한다는 의미이다. 이는 애플리케이션, 특히 분산 아키텍처의 애플리케이션이 클라우드 컴퓨팅 내에서 강력하고 쉽게 배포되도록 돕는다.
- 아키텍처의 유연성: 소프트웨어 요구 사항, 기술, 조직 구조, 클라우드 서비스가 항상 진화함에 따라 영구적으로 적용 가능한 완벽한 소프트웨어 아키텍처를 정의하기는 어렵다. 따라서 아키텍처가 유연하면 애플리케이션 개발 후에 발생할 수 있는 변경 사항을 더 쉽게 처리할 수 있다. 이는 또한 완전한 기능 설계를 기다리지 않고도 애플리케이션이 더 빠른 개발 및 제공을 달성하는 데 도움이 된다.
2-3. 클라우드 네이티브를 구현하는 기술
클라우드 네이티브 애플리케이션 제공에는 다음과 같은 일반적인 기술이 선호된다.
- 컨테이너: 소프트웨어 실행을 위한 격리되고 이식 가능한 실행 환경인 컨테이너는 애플리케이션 소프트웨어와 모든 종속성을 패키지화하여 애플리케이션이 더 이상 환경에 의해 제한되지 않고 다양한 컴퓨팅 환경 간에 전체 기능으로 실행되도록 한다. 컨테이너를 사용하면 클라우드 네이티브 애플리케이션을 클라우드 컴퓨팅에서 쉽게 생성, 확장 및 마이그레이션할 수 있다.※ 참고 : 컨테이너는 애플리케이션의 가상화 처리를 위한 격리, 자원 제어 및 이식성을 제공하는 소프트웨어 세트이다.※ 참고: 일반적인 클라우드 네이티브 기술로 컨테이너를 선택한다고 해서 컨테이너가 유일한 선택이라는 의미는 아니다. 클라우드 컴퓨팅의 컨테이너와 가상 머신은 모두 CSC의 요구 사항에 따라 클라우드 네이티브 애플리케이션을 제공하는 데 사용된다.※ 참고 : 클라우드 네이티브 애플리케이션을 제공하기 위해 컨테이너를 사용하는 이유는 컨테이너가 가상 머신보다 이식성이 우수하기 때문이다.
- 마이크로서비스: 마이크로서비스를 사용하는 클라우드 네이티브 애플리케이션은 신속하게 배포되는 기능 독립적인 여러 모듈로 구분된다. 이는 가장 유연한 애플리케이션 소프트웨어 아키텍처를 보장한다. 가장 유연한 협업을 통해 최소한의 개발자가 최소한의 애플리케이션 코드로 마이크로서비스를 구현하므로 구현된 애플리케이션에 어떤 변화가 발생할 수 있다. 또한 애플리케이션이 더 많은 클라우드 서비스를 사용할 수 있게 된다.
- 서비스 메시: 서비스 메시는 클라우드 네이티브 애플리케이션을 위한 마이크로서비스 간의 모든 트래픽 조정을 제공하고 마이크로서비스 연결 및 상호 작용을 프로그래밍 가능한 인프라 리소스로 오프로드한다. 서비스 메시를 사용하는 클라우드 네이티브 애플리케이션 개발자는 더 이상 네트워크 인프라를 다룰 필요가 없으며 비즈니스 로직에만 집중할 수 있다. 이는 사용하기 쉬운 마이크로서비스를 사용하는 클라우드 네이티브 애플리케이션을 지원한다.
- 자동화 도구: 자동화 도구는 클라우드 네이티브 애플리케이션에 지속적인 통합, 지속적인 배포 및 지속적인 전달 기능을 제공하는 소프트웨어 그룹으로, 자동화 파이프라인을 형성하고 유연한 아키텍처에서 클라우드 네이티브 애플리케이션의 수명 주기 관리 어려움을 줄여준다.
2-4. 클라우드 네이티브 애플리케이션과 PaaS의 관계
클라우드 네이티브 애플리케이션이 원하는 만큼 최대한 많은 클라우드 서비스를 사용하려면 클라우드 네이티브 애플리케이션 수명주기의 주요 단계(코딩, 테스트, 배포, 유지 관리 등 포함)가 클라우드 컴퓨팅 내에서 발생하는 것이 선호되며 이는 PaaS가 완벽하게 충족한다.
예를 들어, PaaS의 IDE 및 개발 도구를 사용하면 클라우드 컴퓨팅에서 CSC 코딩 및 클라우드 네이티브 애플리케이션 테스트가 가능하다.
PaaS의 애플리케이션 호스팅 환경을 통해 CSC는 물리적 및 가상 리소스, 애플리케이션 종속 소프트웨어 등을 포함하여 클라우드 네이티브 애플리케이션 배포 및 실행을 위한 모든 것(애플리케이션 비즈니스 로직 코드 제외)을 얻을 수 있다.
PaaS의 서비스 제공 플랫폼은 PaaS 서비스 관리를 처리하고 CSC가 복잡해지는 것을 방지한다. 클라우드 서비스 운영. PaaS는 클라우드 네이티브 애플리케이션에서 가장 많이 선택하는 클라우드 서비스이다.
온프레미스 애플리케이션을 비교하면 CSC는 애플리케이션 개발 환경, 개발 도구, 애플리케이션 호스팅 환경 등 애플리케이션 라이프사이클 내에서 필요한 모든 것을 제공하고 관리해야 한다.
CSC는 클라우드 서비스를 사용하지 않기 때문에 사내 애플리케이션은 클라우드 네이티브 애플리케이션이 아니다.
IaaS 서비스를 사용하는 클라우드 애플리케이션을 비교하면, CSC는 CSP에서 제공하는 인프라 리소스만 사용하는 반면, CSC는 여전히 부분적인 애플리케이션 호스팅 환경(운영 체제, 런타임 등), 애플리케이션 개발 환경, 개발 도구 등을 제공하고 관리해야 한다.
IaaS를 사용하는 것은 필요하지만 클라우드 네이티브 애플리케이션을 구현하기에는 충분하지 않다.
참 고 문 헌
- ITU-T Y.3532 (2023) Cloud computing - Functional requirements of Platform as a Service for cloud native applications
- ITU-T Y.3501 (2016) Cloud computing - Framework and high-level requirements
- ISO/IEC TS 23267 (2020) Information technology ? Cloud computing ? Common technologies and techniques
- ITU-T X.1601 (2015) Security framework for cloud computing
저작권 정책
K-ICT 클라우드혁신센터의 저작물인 『국제표준문서에서 클라우드 네이티브 애플리케이션을 위한 PaaS(Platform as a Service)의 기능적 요구 사항』은 K-ICT 클라우드혁신센터에서 상명대학교 서광규 교수에게 집필 자문을 받아 발행한 전문정보 브리프로, K-ICT 클라우드혁신센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.