해당 포스팅은 오레일리의 책, 클라우드 아키텍트 트랜스포메이션을 보며 정리한 내용입니다.
최종 업데이트 : 2024-01-12
클라우드 네이티브는 단순한 도구 모음 이상의 의미가 있다. 완벽한 아키텍처로, 컴퓨팅을 최대한 활용하는 클라우드 애플리케이션을 구축하기 위한 철학적인 접근 방식이다.
" 클라우드 네이티브"는 " 클라우드 " 가 아니다.
클라우드 컴퓨팅을 단순히 "클라우드"라 하면 인터넷을 통해 인프라스트럭처를 주문형 방식으로 제공하는 것을 의미한다. AWS, GCP, Azure 등의 클라우드 서비스 플랫폼에서 제공하는 경우가 많으므로 실제로 소비하는 자원에 대해서만 요금을 지불할 수 있다.
클라우드 네이티브는 위의 모든 클라우드 기반 구성요소를 클라우드 환경에 최적화된 방식으로 조립하기 위한 아키텍처이다. 서버가 아닌 서비스에 대한 것이며, 기업의 목표는 사례에 적합한 클라우드 기술을 효율적으로 선택하는 데 있다.
클라우드 네이티브 마이그레이션 목적에 도달하기 위한 경로는 수없이 많고, 조직의 요구에 따라 다양한 방법이 있기 때문에 방향을 잃어버리기 쉽다. 이를 위해서는 전체 구현 및 배포 전에 설계를 이해하고 우선순위를 정해야 한다.
클라우드 네이티브 패턴 언어를 개발하는 것은 유용하고 재사용 가능한 로드맵을 작성하는 다음 단계이다. 개발자가 best practice를 논의하고 학습,적용할 수 있도록 공통 context를 식별하고 협의하기 위한 언어가 필수적이다.
클라우드 네이티브 개요
클라우드 네이티브 컴퓨팅이란, 오픈소스 소프트웨어 스택을 사용해 애플리케이션을 마이크로서비스로 배포, 각 부분을 자체 컨테이너에 패키징, 컨테이너를 동적으로 조정해 리소스 활용도를 최적화하는 것이다.
-CNCF(Cloud Native Computin Foundation)-
기본적으로 클라우드 네이티브는 특정한 접근 방식의 이름이며, 아키텍처는 CI를 할 때 IaaS에 의존한다. 일반적인 목표는 속도 향상이며, 이를 통해 새로운 아이디어를 몇 시간 내 운영 환경에 투입할 수 있다. 실제로 클라우드 네이티브로 마이그레이션하는 대부분의 기업은 속도를 주요 이동 요인으로 꼽는다.
클라우드 네이티브를 어떻게 알 수 있을까?
클라우드 네이티브의 기본 원칙을 컨테이너 패키징, 동적 관리 및 모듈식 분산 아키텍처라 하는 경우가 많지만 실제로는 다섯가지의 아키텍처 원칙과 두가지 문화적 원칙이다.
<아키텍처 원칙>
- 컨테이너화 : 애플리케이션과 종속성/운영 환경을 함께 캡슐화해 단일 패키지로 구성할 수 있다. 테스트, 이동/배포가 쉬워진다.
- 동적 관리 : 온디맨드 방식으로 유연하게 프로비저닝할 수 있는 서비스를 사용한다. 일반적인 public cloud에서는 사용한 리소스에 대해서만 비용을 지불한다.
- 마이크로서비스 : 애플리케이션을 분리된 소규모 구성 요소 서비스의 집합으로 서비스한다. 각 마이크로서비스는 다른 서비스와 독립적으로 작동하며 최종 사용자에게 영향을 미치지 않는다. 마이크로서비스는 팀이 동시에 개발하면서 독립적으로도 개발할 수 있도록 해 개발 속도를 높이는 데 도움을 준다.
- 자동화 : 유지보수 및 업데이트와 같은 수동 작업을 스크립트나 코드로 교체해 원활하고 안정적으로 수행할 수 있다.
- 오케스트레이션 : 컨테이너형 애플리케이션의 배포, 확장 및 관리를 자동화해 모든 것을 하나로 묶는다. 특히, 쿠버네티스 또는 오케스트레이션 도구를 사용하여 인프라 전반에서 컨테이너의 로드 밸런싱, 스케일 업다운 등의 작업을 제어 및 자동화한다.
<문화적 원칙>
- 위임 (Delegation) : 개인이 안전하게 변경하도록 필요한 도구, 교육 및 재량권을 제공하고 되도록 자율적으로 배포 및 모니터링하게 한다.
- 동적 전략 : 팀에게 전략을 전달하지만 결과에 따라 전략을 수정할 수 있다. 이것이 클라우드 네이티브가 제공하는 빠르고 실험적인 배포의 궁극적인 목적이다.
궁극적으로 클라우드 네이티브는 어디에서가 아니라 어떻게 생성하고 제공하느냐에 대한 것이다. 클라우드 네이티브의 목적은 실용적인 접근이다. CD처럼 빠르고 현대적인 소프트웨어 방식과 연동하여 시간을 단축하고, 쉽게 확장하며 효율적으로 운영하기 위함이다. 또한 클라우드 네이티브 아키텍처를 통해 복잡한 시스템을 독립적 팀이 구축한 소규모 구성 요소로 나눌 수 있다. 기존의 모놀리식 애플리케이션의 복잡성과는 다르다.
가장 중요한 점은 클라우드 네이티브가 위험을 줄이는 데 도움이 된다는 것이다. 빠르지만 작고, 변경이 잘못될 경우 폭발 반경을 제한하고, 변경사항을 즉시 롤백하는 방식이다.
서비스에 대한 모든 것
퍼블릭 클라우드 기반 서비스가 제공하는 서비스 유형이다.
- IaaS (Infrastructure as a Service) : 외부 하드웨어, 데이터 스토리저 및 네트워킹을 포함한다. 인프라를 소유하며, 임대하면 중앙 아키텍처팀의 기능으로 한정되지 않아 각 팀의 창의성을 극대화할 수 있다.
- PaaS (Platform as a Service) : 모든 가상화된 인프라를 관리하고 유지해 운영 및 플랫폼 팀의 부하를 크게 줄일 수 있다.
- SaaS (Software as a Service) : 기존 비즈니스 소프트웨어에서 가상 인프라 관리 도구에 이르기까지 모든 구성 요소 애플리케이션을 선택할 수 있다. 이 모든 애플리케이션은 웹을 통해 제공/운영되며, 프로바이더는 보안, 가용성, 성능을 보장한다.
- CaaS (Container as a Service) : 컨테이너 엔진, 오케스트레이션 및 모든 기본 컴퓨팅 리소스를 클라우드 프로바이더의 서비스로 사용자에게 제공할 수 있다.
- As a Service : 위에 언급된 서비스 외에도 많은 서비스들이 생겨나고 있으며, 조금씩 발전하고 있다.
클라우드 네이티브 원칙의 이해
앞서 이야기한 클라우드 네이티브의 다섯가지 원칙에 대해 이야기해보려 한다.
컨테이너화
서비스 기반 아키텍처를 정의한 후에는 모든 곳, 모든 사람을 위해 컨테이너화해야 합리적이다 컨테이너는 응용 프로그램을 실행하는 데 필요한 모든 것을 포함하는 경량의 독립 실행형 소프트웨어 패키지다. 모든 의존성을 가지고 코드를 패키징해 어느 컴퓨팅 환경에서든 실행할 수 있다.
이런 가상 시스템은 애플리케이션과 애플리케이션을 자체 운영 체제에 이르기까지 어느 플랫폼에서든 실행할 수 있는 독립형 유닛으로 격리시킨다. 전 세계적으로 동일한 컨테이너를 IaaS를 통해 호스팅하고 배포할 수 있으므로 운영이 유연하고 안정적이며 빠르다.
동적 관리
컴퓨팅, 네트워크 및 스토리지 리소스는 사전 비용 없이 표준화된 API를 사용해 온디맨드 방식으로 프로비저닝되며, 실제 비즈니스 요구에 실시간으로 대응할 수 있다. 컴퓨팅, 네트워크 및 스토리티 리소스 운영은 전문 기술이 필요한 어려운 작업이기에 기술 습득은 시간이 많이 걸리고 비용이 많이 든다. 하지만 속도가 더 중요하기에 클라우드 플랫폼을 통해 고가용성, 안정성 및 보안 표준에 따른 리소스 수명 주기가 자동으로 관리되는 것을 기대할 수 있다.
마이크로서비스
마이크로서비스 아키텍처는 대규모 애플리케이션이 모듈식 구성 요소 또는 서비스 제품군으로 구축되는 애플리케이션 개발에 대한 접근 방식이다. 각 서비스는 고유 프로세스를 실행하고 자체 데이터베이스를 관리한다. 마이크로서비스는 API를 통해 통신하며 각 서비스를 독립적으로 분리,재구성,재배포 및 관리할 수 있다.
또한 소프트웨어를 구축하기 위해 비계층적 기능적 접근 방식을 취하여 모놀리식 엔티티를 더 작은 개별 조각으로 분할하고 프로세스를 독립적으로 제공할 수 있다.
각 마이크로서비스는 특정 목적에 가장 적합한 언어로 작성될 수 있으며, 필요에 따라 독립적으로 scale-up 또는 scale-down할 수 있다. 그리고 모놀리식 애플리케이션과 달리, 블래스트 래디우스(the blast radius) 는 마이크로서비스의 기록에 포함된다.
- 블래스트 래디우스 : 스케일업과 스케일다운이 발생한은 최대/최소 범위
자동화
스크립트 또는 코드에서의 수동작업은 자동화된 단계로 대체된다. 그 예로 테스트 프레임워크, 구성 관리, CI/CD 도구 등이 있다. 자동화는 반복적인 작업과 운영 통합 절차를 통해 휴먼에러를 제한하고 시스템 신뢰성을 향상시킨다. 그로 인해 인간은 유지보수 작업 대신 비즈니스에 집중할 수 있게 됐다.
클라우드 네이티브를 적용할 때 자동화를 하지 않으면 혼란에 빠지기 쉽다. 클라우드 마이그레이션 이후 기업은 더욱 빠르게, 자주 배포하게 되는데 배포 프로세스를 완전히 자동화하지 않으면 온프레미스 서버를 운영하지 않아 새롭고 빠른 운영주기로 배포하는 데 시간을 사용할 수 있다. 배포 빈도가 높을수록 실수할 가능성도 높다.
배포 자동화는 지속적인 CI/CD를 단순하게 만들고, 자동화된 테스트를 통해 이슈가 되기 전에 문제를 조기 발견할 수 있다.
오케스트레이션
MSA(MicroService Architecture) 구축 이후 컨테이너화를 마친 후에 각 컨테이너들을 조율해야 한다. 엔터프라이즈 레벨 애프리케이션은 여러 컨테이너에 걸쳐있으며, 이러한 컨테이너는 여러 서비스를 포함해 포괄적인 컨테이너 인프라를 구성하는 여러 서버 호스트에 구축해야 한다.
오케스트레이션은 아키텍처를 계획할 때 공통 패턴을 사용할 수 있도록 지원하므로 엔지니어링 노력이 줄어든다. 개발자는 낮은 수준의 추상화를 해결하는 데 자유로워지고 아키텍처에 집중할 수 있다.
쿠버네티스가 이러한 것을 담당하며 cloud native migration에서 마지막으로 수행되는 중요한 일이다. 오케스트레이터를 먼저 구현하면 어렵다. 따라서 클라우드 인프라, 동적관리, 자동화 등의 다른 클라우드 네이티브 원칙을 먼저 수립해야 한다.
모든 것을 함께 조정하라
다섯가지 원칙 모두 필수적이지만 마이크로서비스는 그 중 제일 중요하다
마이크로서비스는 중심적인 역할을 한다. 컨테이너, 동적관리, 자동화, 오케스트레이션은 MSA와 결합해야만 진정한 힘을 발휘한다.
마이크로서비스가 클라우드 네이티브 원칙의 중심인 이유는 마이크로서비스가 모든 기업의 차별화 요소인 비즈니스 로직을 캡슐화한다는 점이고, 기업은 이를 통해 고객에게 가치를 제공하는 프로세스를 나타낼 수 있다.
무엇이 잘못될 수 있을까?
누구나 퍼블릭 클라우드 서비스에 회원가입을 한 다음 AWS, GCP, Azure 등의 서비스를 사용할 수 있다는 것은 놀라운 일이다. 경쟁은 점점 더 치열해지고, 가격은 떨어지고, 기능들은 늘어나고 있다.
하지만 그 대신 문제점 또한 쉽게 발생할 수 있는데 크게 아래와 같다.
- 분산 시스템이 복잡해서 어렵다.
- 방대한 도구 및 플랫폼으로 구성된 클라우드 네이티브 에코 시스템이 상대적으로 미성숙하다.
- 변화하는 기술과 전달되는 기대치에 맞춰 조직 문화를 발전시키지 못했다.
분산 시스템의 충격
사용자는 빠르게 심리스하며 상시 접속 가능한 환경을 원한다. 이러한 기대를 충족시키고자 클라우드 네이티브의 많은 기능들은 발전해왔다. 분산 시스템에 대해 생각할 수 있는 방법은 여러 독립적 기능을 함께 사용하여 최종 사용자에게 단일 통합 환경으로 제공하는 것이다.
분산 시스템의 주요 이점은 신뢰성이다. 컴퓨팅 프로세스가 전체 시스템 네트워크에 분산되어 있을 때 서로 독립적으로 발생한다.
배포를 통해 필요에 따라 노드와 기능을 쉽게 추가할 수 있어 시스템의 확장성이 크게 향상된다.
그러나 이 모든 이점은 복잡성을 수반한다. 시스템이 복잡해지면 설계, 구축, 디버깅이 어려워지고 장애는 필수적이다. 이러한 장애를 이해하기 위해 정교한 관측성이 필수적이다.
미성숙함으로 인한 충격
퍼블릭 클라우드 플랫폼은 솔루션으로 제공되지만 플러그 앤 플레이와는 거리가 멀다. 전체 솔루션이라고 주장하지만 정말 모든 기능이 있지는 않다.
클라우드 네이티브는 계속 발전하므로 서비스 환경도 계속 발전하고 있다.
요약
클라우드에서 최선의 결과를 얻으려면 마이크로서비스, 컨테이너, 오케스트레이션, 자동화 등의 클라우드 네이티브 아키텍처를 사용해야 한다. 자동화는 가장 먼저 시행되어야 한다.
마이크로서비스와 클라우드 서비스는 그를 위한 핵심 요소이다.
클라우드 네이티브는 강력하고 전도유망한 기술이다. 이 이점을 활용하려면 클라우드 네이티브 아키텍처의 원리를 기반으로 견고한 기반을 구축해야 한다.