“클라우드 퍼스트”라는 용어는 시스템을 구축할 때 클라우드를 우선적으로 고려하는 의미로 오래전부터 사용되어 왔습니다. 반면에 최근 주목을 받고 있는 용어가 “클라우드 네이티브”입니다. 클라우드 네이티브와 클라우드 퍼스트는 어떤 차이점이 있을까요?
클라우드 퍼스트 전략의 등장
클라우드 확산이 본격화하기 몇 년 전, “클라우드 퍼스트”라는 전략이 등장하였습니다. 이것은 시스템을 설계하고 구축할 때, 클라우드 환경에서의 운영을 우선적으로 고려한다는 의미입니다. 온프레미스 환경에서 시스템을 구축할 경우, 시스템 가동 후에 서버의 성능을 확장하거나 스토리지를 고성능화하는 작업은 제약이 많습니다. 따라서 미리 시스템의 처리 능력을 예측하고, 그 예측을 상회하는 규모의 서버와 스토리지를 처음부터 준비해야 하는 편입니다. 이러한 점에서 초기에 하드웨어의 조달 및 설치 등에 상당한 비용과 노력이 필요합니다.
클라우드 환경의 이점
반면 클라우드 환경에서는 시스템이 가동된 이후에도 인스턴스의 성능을 유연하게 조정하거나, 추가 스토리지를 할당하는 것이 상대적으로 간단합니다. 이에 따라 초기에 작은 규모의 인스턴스와 스토리지로 시작하여, 성능이 요구될 상황에서 적절한 규모와 성능의 리소스로 전환할 수 있습니다. 이로 인해 상세한 용량 계획에 많은 시간을 투자할 필요가 없으며, 하드웨어의 조달도 불필요 하므로 빠르고 저렴하게 프로젝트를 시작할 수 있습니다. 또한, 시스템이 더 이상 필요하지 않게 되면, 하드웨어의 감가상각을 기다릴 필요 없이 즉시 리소스를 해제할 수 있습니다. 이러한 장점들이 일반적으로 클라우드 퍼스트 전략의 주요 이점으로 간주됩니다.
클라우드 네이티브의 등장
“클라우드 퍼스트”보다 더 깊이 클라우드의 장점을 극대화하는 시스템을 의미하는 용어로 “클라우드 네이티브”가 등장하였습니다. 클라우드 네이티브는 기반으로 클라우드를 사용하는 것은 물론, 그 이상으로 애플리케이션까지도 클라우드에 최적화되도록 설계합니다. 클라우드 네이티브를 촉진하는 단체인 ‘Cloud Native Computing Foundation'(CNCF)은 Kubernetes 등 다양한 오픈 소스 소프트웨어의 개발을 주도하고 있습니다. 해당 단체는 “CNCF Cloud Native Definition v1.0” (https://github.com/cncf/toc/blob/master/DEFINITION.md) 문서에서 클라우드 네이티브의 정의를 공개하고 있습니다. 일부를 인용하겠습니다.
클라우드 네이티브 기술은 공용 클라우드, 사설 클라우드, 하이브리드 클라우드 등 현대적이고 동적인 환경에서 스케일러블한 애플리케이션을 구축 및 실행할 수 있는 능력을 조직에 제공합니다. 이러한 접근 방식에는 컨테이너, 서비스 메시, 마이크로서비스, 불변의 인프라스트럭처, 그리고 선언적 API가 있습니다.
컨테이너 기반의 아키텍처
다소 추상적인 표현이지만, 클라우드 네이티브에서는 가상 머신 대신 더 세밀한 단위의 컨테이너를 기반으로 합니다. 그 결과로 더욱 스케일러블하고 유연한 애플리케이션을 구축할 수 있으며, 클라우드 퍼스트보다도 훨씬 깊은 수준에서 클라우드의 이점을 누릴 수 있습니다. 추가로, 서비스 메시, 마이크로서비스, 불변의 인프라스트럭처, 선언적 API와 같은 기술을 활용하면, 클라우드 네이티브 시스템을 더 효율적으로 구축할 수 있다는 것이 입증되어 있습니다. 물론 ‘클라우드 네이티브’라는 용어는 다양한 조직, 단체, 개인이 상황에 따라 여러 의미로 사용하고 있습니다. CNCF의 정의는 그중 하나일 뿐이지만, 대체로 IT 엔지니어들 사이에서 클라우드 네이티브에 대한 공감대가 형성되고 있는 정의로 여겨집니다.
클라우드 네이티브를 구성하는 기술 요소
마이크로서비스는 시스템을 세분화된 ‘서비스’로 분해하고, 이러한 서비스들을 상호 연결하여 시스템을 작동시키는 아키텍처입니다. 서비스를 개별적으로 분해함으로써, 각 서비스에 부하 분산 및 스케일러빌리티를 부여할 수 있고, 기능 추가나 변경도 용이하게 할 수 있습니다. 더불어, 특정 서비스에 장애가 발생해도 그 영향을 지역적으로 제한할 수 있다는 장점이 있습니다. 각 서비스는 별도의 컨테이너에 할당되어 운영됩니다. 특정 서비스에 대한 부하가 증가하면 해당 서비스의 컨테이너 수를 증가시킵니다. 이러한 다수의 컨테이너를 하나의 시스템으로 관리하는 메커니즘이 바로 컨테이너 오케스트레이션 도구인 Kubernetes이며, 컨테이너 간의 통신을 관리하는 메커니즘은 서비스 메시인 Istio입니다.
선언적 API
또한, 컨테이너 간의 연결은 각 서비스가 공개하는 API를 통해 이루어지므로, ‘선언적 API’가 사용됩니다. 불변의 인프라스트럭처, 즉 ‘이뮤터블 인프라스트럭처’는 OS나 기타 인프라에 패치를 적용하는 등의 변경이 필요할 경우, 기존 환경을 수정하는 대신 새로운 환경을 구축하고, 기존 환경은 폐기하는 방식을 의미합니다. 이러한 인프라가 불변성을 지니고 있다는 것은, 애플리케이션에게 인프라는 시작부터 종료까지 항상 일정하게 유지된다는 것을 의미합니다. 이런 유연한 리소스의 확보 및 해제가 가능한 것은 클라우드의 유연성 덕분이며, 이뮤터블 인프라스트럭처는 실질적으로 이러한 유연한 리소스 확보가 가능한 클라우드를 지칭합니다.
개발 프로세스와 조직문화 변화의 필요성
개발 프로세스와 조직 역시 변화가 필요합니다. 마이크로서비스 아키텍처를 채택하고, 불변의 인프라스트럭처인 클라우드를 기반으로 Kubernetes와 Istio를 활용하여 애플리케이션을 구현했다고 해서, 그것이 ‘클라우드 네이티브의 완성’이라고 볼 수 없습니다. 예컨대, 다수의 서비스로 구성되는 복잡한 애플리케이션의 빌드와 배포는 수동으로 진행하는 대신 자동화하는 방향으로 발전시키고자 할 것입니다. 따라서 지속적 통합과 지속적 배포(CI/CD)의 파이프라인을 구축할 필요가 있습니다. 이에 Jenkins, CircleCI, Spinnaker와 같은 CI/CD 자동화 도구가 적용되며, 소스 코드의 관리도 GitHub 등을 사용하게 될 것입니다. 그리고 이러한 툴을 능숙하게 다룰 수 있는 팀은 자연스럽게 애자일 개발 방법론이나 DevOps와 같은, 유연한 개발 및 운영 스타일을 채택하게 될 것입니다.