클라우드 네이티브(Cloud Native) 란?

• 간단히 보는 클라우드 네이티브(Cloud Native) 란?

RedHat과 CNCF(Cloud Native Computing Foundation)는 클라우드 네이티브에 대해 아래와 같이 정의 했습니다.

• "클라우드 네이티브" 애플리케이션은 프라이빗, 퍼블릭 및 하이브리드 클라우드 환경 전체에 지속적인 개발과 자동화된 관리 환경을 제공하기 위해 특별히 설계된 애플리케이션을 뜻합니다. - RedHat
• 클라우드 네이티브 기술을 사용하는 조직은 현대적인 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같이 동적인 환경에서 확장성 있는 애플리케이션을 만들고 운영할 수 있다. 컨테이너, 서비스 메시, 마이크로서비스, 불변의 인프라스트럭처, 그리고 선언적 API가 전형적인 접근 방식에 해당한다. 
  
  이 기술은 회복성이 있고, 관리 편의성을 제공하며, 가시성을 갖는 느슨하게 결합된 시스템을 가능하게 한다. 견고한 자동화와 함께 사용하면, 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다. 
  
  Cloud Native Computing Foundation은 벤더 중립적인 오픈소스 프로젝트 생태계를 육성하고 유지함으로써 해당 패러다임 채택을 촉진한다. 우리 재단은 최신 기술 수준의 패턴을 대중화하여 이런 혁신을 누구나 접근 가능하도록 한다. - CNCF(Cloud Native Computing Foundation)

 

클라우드 네이티브에 대해 검색하면 전형적인 문서 형식의 글이 많고 클라우드 네이티브에 대한 설명이 조금씩 차이가 있는데, 공통적인 부분은 Container + CI/CD + DevOps + Micro Service 이렇게 4가지가 있으며 이러한 환경들을 잘 융합하여 구성한것을 클라우드 네이티브라고 볼 수 있습니다.

 

간단히 4가지의 기술들을 소개하겠습니다.

 

• Container & Container Orchestration

하이퍼 바이저 기반의 가상화 기술보다 훨씬 경량화된(오버헤드가 적은) 기술 이며 정확히는 가상화가 아닌 프로세스를 격리 시키는 기술 입니다. 코드로 관리되다 보니 이미지의 이력 관리에 유리하며, 일관된 개발 환경, 가상화 기술에 비해 가볍고 빠르다는 장점 등이 있습니다. 

좌: 하이퍼 바이저 기반 가상화, 우: Docker Container

 

또한 Kubernetes와 같은 Container Orchestration Tool을 도입하여 중앙화 관리, 자동화된 장애 대응(self-healing), 리소스에 따른 scale in/out, 무중단 배포 등 굉장히 많은 이점을 제공 받을 수 있습니다.

 

• CI/CD

CI/CD는 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포를 뜻 합니다. jenkins와 같은 툴을 사용해 CI/CD 파이프라인을 구축해 개발 단계를 자동화하고 애플리케이션의 통합, 테스트 단계, 제공 및 배포에 이르는 모든 라이프 사이클 전체에 걸쳐서 지속적인 모니터링과 자동화를 제공 합니다.

일명 통합 지옥(integration hell)이라 불리는 팀 구성원들이 각자의 코드를 통합할 때 발생하는 문제를 해결하기 위한 솔루션으로써 대표적인 툴은 jenkins가 있습니다. 일반적으로 이러한 환경을 CI/CD pipeline 이라고 부릅니다.

 

• DevOps

DevOps는 개발(Dev)과 운영팀(Ops)의 중간 포지션에서 두 팀을 잘 융합시키고 의사소통을 이끌어내는 문화로 시작 하였지만 우리나라에 넘어오면서 그런 문화보다는 특정 직책의 성향이 많이 강해졌습니다.

회사마다 조금씩 다르지만 현재 우리나라에서의 DevOps는 개발팀과 운영팀을 융합 시킨다기보다는 인프라 자동화 + Cloud + Container + CI/CD Pipeline 또는 백엔드 개발 + Cloud + Contaier + CI/CD Pipeline의 업무를 맡아 진행하는 직책으로 거의 굳어진 상태 입니다.

 

클라우드 네이티브에서 말하는 DevOps는 우리나라에 넘어오기 전의 조직/문화의 개념으로써 표현 됩니다.

 

• Micro Service

마이크로 서비스는 보통 MSA(Micro Service Architecture) 라고도 불립니다.

마이크로 서비스의 반대되는 개념인 모놀리틱 아키텍처(Monolithic Architecture)가 있는데 모든 코드가 하나로 묶여있어 서비스의 복잡도가 증가할수록 아주 작은 기능 하나를 추가하기 위해 여러개의 코드를 수정하고 여러개의 코드를 수정함으로써 영향을 미치는 범위가 증가하여 테스트 및 검증하기 위한 시간과 인력이 많이 소비됨은 물론 배포 시간의 증가, 안전성 감소 등의 문제가 있었습니다.

 

이러한 문제를 해결하기 위해 나온 방법론이 마이크로 서비스 아키텍처(MSA) 입니다. 독립적인 역할을 수행하는 서비스를 작은 단위로 분리하여 설계함으로써 규모가 커지고 복잡도가 높아질수록 많은 이점을 갖습니다.

독립적이므로 서비스의 코드 수정에 따른 영향 범위가 적으며, 특정 서비스별로 독립적인 배포가 가능한것이 가장 큰 특징 입니다. 또한 특정 서비스에서 많은 양의 리소스를 필요로 하거나, 특정 서비스에서는 아주 적은양의 리소스가 필요하다면 각각의 환경에 맞게 리소스를 할당하여 사용할 수 있기에 서버의 리소스를 효율적으로 사용할 수 있게 됩니다.