클라우드 네이티브 인프라스트럭처

Photo by chuttersnap on Unsplash

클라우드 네이티브의 정의

클라우드 네이티브 컴퓨팅 재단(CNCF)에서 다음과 같이 공식적으로 정의하고 있습니다.

클라우드-네이티브 기반 기술을 통해 조직은 퍼블릭, 프라이빗 및 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 구축하고 실행할 수 있습니다. 컨테이너, 서비스 메시, 마이크로 서비스, 불변형 인프라 및 선언형 API가 이러한 접근 방식을 예시하고 있습니다.

이러한 기술을 통해 탄력성, 관리 및 관찰이 가능한 느슨하게 결합된 시스템을 사용할 수 있습니다. 강력한 자동화와 결합되어 엔지니어는 최소의 노력으로 영향을 많이 미치는 변화를 자주 예측 가능하게 되었습니다.

(번역)

클라우드 네이티브의 등장 배경

클라우드 컴퓨팅 환경이 등장하기 이전에 우리는 물리적 자원을 직접 구축하고 관리했습니다. 때문에 이를 유지/보수하는 비용이 함께 동반됐으며 기술적인 투자(자원 확장 및 축소 등)와 리스크까지 감수해야 했습니다.

이제까지 우리는 애플리케이션의 요구사항을 위해 적당한 수준의 물리적 자원을 예측해 준비하고, 그 위에 애플리케이션을 배포했습니다. 즉, ‘어디에 애플리케이션을 배포 할 지’에 대해 고민 하는것이 모놀리틱 구조의 주된 과제입니다. 이 구조는 온-프레미스가 가지는 물리적인 한계 때문에 확장성이 떨어지며 가용성 확보에 대한 부담감이 언제나 동반됩니다.

그러나 클라우드 컴퓨팅 환경의 등장으로 클라우드 컴퓨팅 환경은 가상화된 공유 풀에서 자원을 온디맨드로 할당하고 해제하는 동적인 환경이 되었습니다. 이러한 탄력적 환경은 기존의 온-프레미스 데이터 센터에서 일반적으로 사용되는 초기 리소스 할당에 비해 훨씬 유연합니다.

따라서 우리는 이제 물리적 자원에 대해 염려할 필요가 없습니다. 물리적 자원은 무한합니다. 우리가 집중하고 해결해야 하는 주제는 ‘어디에 애플리케이션을 배포 할 것’이 아니라 ‘어떻게 애플리케이션을 배포 할 것’이라는 것을 꼭 명심해야 합니다.

모놀리틱 구조의 한계

모톨리틱 구조는 애플리케이션들이 서로 강하게 결합된 구조입니다. 이는 작은 배포가 전체 시스템에 영향을 주게 됩니다. 배포에 대한 부담감이 증가하며 배포 주기가 길어지게 됩니다. 그 결과 버그 대응과 기능 추가 속도가 느려지며 애플리케이션이 늙게 됩니다.

모놀리틱 구조는 API 기반으로 동작하는 마이크로서비스와 다르게 지역 함수들의 호출로 동작하게 됩니다. 만약 특정 함수에 문제가 생기면 애플리케이션 전체가 중단되는 문제가 발생합니다. 따라서 개발자에게 전체 시스템에 대한 높은 이해도가 요구되며 작은 실수가 큰 위험 요소가 될 수 있습니다.

왜 마이크로서비스인가?

우리의 애플리케이션을 클라우드 네이티브 환경에 적응시키려면 전통적인 모놀리틱 구조에서 사용하던 패턴은 지양해야합니다. 즉 마이크로서비스 가능토록 애플리케이션의 기반을 재설계 해야합니다.

마이크로서비스가 주는 이점은 다음과 같습니다.

각 마이크로 서비스는 독립적인 라이프사이클을 가지고 있으며 독립적으로 진화하고 자주 배포할 수 있습니다. 분기별 릴리즈에서 새로운 기능 또는 업데이트를 구현할 때까지 기다릴 필요가 없습니다. 전체 시스템을 중단시킬 위험이 적은 복잡한 애플리케이션의 작은 영역을 업데이트할 수 있습니다.

각 마이크로 서비스는 독립적으로 확장할 수 있습니다. 전체 애플리케이션을 단일 단위로 확장하는 대신 더 많은 처리 능력 또는 네트워크 대역폭이 필요한 서비스만 스케일아웃할 수 있습니다. 이러한 세분화된 확장 접근 방식을 통해 시스템을 보다 효과적으로 제어할 수 있으며, 모든 것이 아닌 시스템의 일부를 확장할 때 전반적인 비용을 절감할 수 있습니다.

애완동물 vs 가축 모델

애완동물 모델

애완동물 모델은 애완동물처럼 시스템 관리자로 부터 사랑 받으며 소중히 다뤄졌습니다. 이들에게 이상이 없는지 24시간 감시했습니다. 심지어 제우스, 포세이돈 그리고 아테나 처럼 고유한 이름까지 지어주는 경우도 허다했습니다. 서버 확장이 필요하면 크기를 키워 해결해야 합니다. 지속적인 관심을 받으며 점차 거대해진 애완동물 서버는 대체 할 수 없게되었으며 문제가 생길시 모두가 알 수 있습니다.

애완동물 모델의 대표적인 사례는 데이터베이스, 방화벽 그리고 로드 밸런서 등입니다.

가축 모델

가축 모델에서 서버들은 귀에 서버1, 서버2, 서버3 그리고 서버50 처럼 번호를 부여 받습니다. 이는 서버들을 무리지은 가축과 같이 동등하게 취급하며 누군가 아프면 다른 번호가 이를 대체합니다. 서버 확장은 가축의 수를 늘려 대응합니다. 때문에 특정 서버에 문제가 생겨도 아무도 인지 하지 않습니다. 이는 마이크로서버스에 적합합니다.

가축 모델의 예시는 웹 서버, No-SQL 클러스터 그리고 큐 클러스터 등입니다.

가축 모델은 불변성 인프라스트럭처를 수용하고 있습니다. 서버는 수리되거나 고쳐지지 않습니다. 만약 문제가 생기거나 업데이트가 필요하면 이를 내리고 새롭게 공급합니다. 또한 이 과정은 모두 자동화되어있습니다.

The Twelve-Factor Application

이제 클라우드 네이티브 환경에 적합한 애플리케이션의 구조를 살펴봅니다. 클라우드 기반 애플리케이션을 구축하는 데 널리 인정되는 방법론은 The Twelve-Factor Application 입니다. 이는 현대 클라우드 환경에 최적화된 애플리케이션을 구축하기 위해 따르는 일련의 원칙과 실천에 대해 설명합니다. 특히 환경 간 이동성 및 선언적 자동화에 주의를 기울입니다. 아래 지표는 The Twelve-Factor 의 방법론을 요약한것입니다.

Codebase: One codebase tracked in revision control, many deploys

Dependencies: Explicitly declare and isolate dependencies

Configuration: Store configuration in the environment

Backing Services: Treat backing services as attached resources

Build, release, run: Strictly separate build and run stages

Processes: Execute the app as one or more stateless processes

Port binding: Export services via port binding

Concurrency: Scale out via the process model

Disposability: Maximize robustness with fast startup and graceful shutdown

Dev/prod parity: Keep development, staging, and production as similar as possible

Logs: Treat logs as event streams

Admin processes: Run admin/management tasks as one-off processes

[출처: Beyond the Twelve-Factor App]

컨테이너

마이크로서비스를 컨테이너화 시키는것은 간단합니다. 코드, 종속성 및 런타임은 컨테이너 이미지라는 이진 파일로 패키징됩니다. 이미지는 컨테이너 레지스트리에 저장되며, 이미지의 리포지토리 또는 라이브러리 역할을 합니다. 레지스트리는 여러분의 개발용 컴퓨터, 데이터 센터 또는 공용 클라우드에 위치할 수 있습니다. Docker 자체는 Docker Hub를 통해 공용 레지스트리를 유지합니다.

컨테이너 모델은 The Twelve-Factor Application의 두번째 원칙인 Dependencies를 아우릅니다.

요소 #2 “각 마이크로 서비스는 자체 종속성을 격리 및 패키징하여 전체 시스템에 영향을 주지 않고 변경 사항을 수용합니다.”

컨테이너는 환경 전반에 걸쳐 이식성과 일관성을 보장합니다. 모든 것을 단일 패키지로 캡슐화하면 마이크로서비스와 그 종속성을 기본 인프라에서 분리할 수 있습니다.

Docker 런타임 엔진이 있는 모든 환경에 동일한 컨테이너를 배포할 수 있습니다. 또한 컨테이너형 워크로드를 통해 프레임워크, 소프트웨어 라이브러리 및 런타임 엔진을 사용하여 각 환경을 사전 구성해야 하는 비용을 절감할 수 있습니다.

기본 운영 체제 및 호스트 리소스를 공유함으로써 컨테이너의 설치 공간이 전체 가상 시스템보다 훨씬 작습니다. 크기가 작을수록 특정 호스트가 한 번에 실행할 수 있는 밀도 또는 마이크로서비스 수가 증가합니다.

[출처: Containers vs. Virtual Machines (VMs): What’s the Difference?]

컨테이너 오케스트레이션

컨테이너 이미지를 생성하고 실행시킬 준비가 됐다면 이들을 관리해야합니다. 컨테이너 관리는 컨테이너 오케스트레이터라는 특별한 도구를 사용해야합니다.

아래는 컨테이너 오케스트레이터가 제공하는 기능입니다.

Scheduling: Automatically provision container instances.

Affinity/anti-affinity: Provision containers nearby or far apart from each

Health monitoring: Automatically detect and correct failures.

Failover: Automatically reprovision failed instance to healthy machines.

Scaling: Automatically add or remove container instance to meet demand.

Networking: Manage a networking overlay for container communication.

Service Discovery: Enable containers to locate each other.

Rolling Upgrades: Coordinate incremental upgrades with zero downtime deployment. Automatically roll back problematic changes.

[출처: Defining cloud native]

이들은 The Twelve-Factor Application의 규칙인 Disposability와 Concurrency를 충족시킵니다.

요소 #8 “서비스는 가장 강력한 시스템에서 단일 대규모 인스턴스를 확장하는 대신 다수의 동일한 프로세스(복사본)에 걸쳐 확장됩니다.”

요소 #9 “서비스 인스턴스는 폐기 가능해야하며, 빠른 스타트업을 선호하여 확장 가능성을 높이고 시스템을 올바른 상태로 유지하도록 해야 합니다. 도커 컨테이너와 오케스트레이터가 기본적으로 이 요구 사항을 충족합니다.”

여러 컨테이너 오케스트레이터가 존재하지만, 컨테이너형 워크로드를 관리하기 위한 확장 가능한 휴대용 오픈 소스 플랫폼인 Kubernetes는 클라우드 네이티브 환경의 실질적인 표준이 되었습니다.

백엔드 서비스

클라우드 기반 시스템은 데이터 저장소, 메시지 브로커, 모니터링 및 ID 서비스와 같은 다양한 보조 리소스에 의존합니다. 이러한 서비스를 백엔드 서비스라고 합니다.

애플리케이션은 설정 파일을 통해 URL을 참조해 백엔드 서비스에 접근합니다. The Twelve-Factor Application의 배포는 코드를 수정하지 않고 MySQL에서 서드파티 DB로 전환할 수 있어야합니다. 이 경우 설정 파일에 있는 값만 변경하면됩니다.

각각의 백엔드 서비스는 모두 리소스입니다. 예를 들어, 하나의 MySQL은 하나의 리소스입니다. 애플리케이션 레이어에서 샤딩을 한 두 개의 MySQL도 두 개의 서로 다른 리소스입니다. Twelve-Factor Application은 이러한 데이터베이스들을 첨부된 리소스로 다룹니다. 이는 느슨한 결합을 암시합니다.

[출처: Backing services]

또한 백엔드 서비스는 Twelve-Factor Application의 “무상태' 원칙을 증진시킵니다.

요소 #6 “각 마이크로서비스는 실행 중인 다른 서비스와 격리된 자체 프로세스에서 실행되어야 합니다. 필요한 상태를 분산 캐시 또는 데이터 저장소와 같은 백업 서비스로 외부화합니다.”

결론

결국 클라우드 네이티브 환경의 목적은 비용 절감과 가용성 확보입니다. 비용 절감을 위해서 물리적인 자원은 클라우드 환경에 조성하고 우리의 애플리케이션을 어떻게 가용성을 확보하며 배포할지 고민합니다. 그 결과로 애완동물 서비스 모델에서 가축 서비스 모델의 전환이 이루어지고, 이들을 민첩하게 확장하고 무중단 배포를 가능하게 해주는 오케스트레이션 툴이 등장했습니다.

관련 글

Defining cloud native — Microsoft

Pets vs Cattle | DevOps Concepts

The Twelve-Factor App

awesome-cloud-native