드디어 Cloud Native Architecture를 배울 차례이다.
이걸 배우기 위해 지난 시간 총 14개의 Section을 통해 개념을 공부한 것이다.(진짜 포기하고 싶었다.... 공부할 거 너무 많고)
그렇다면 지금부터 이번 카테고리의 핵심, Cloud Native Architecture에 대해 자세히 알아보도록 하자.
Cloud Native Architecture
Cloud Native Architecture란?
Cloud Native Architecture를 직역하자면 "본질적인 클라우드 아키텍처"정도가 될 것이다.
말 그대로 Cloud 컴퓨팅 모델을 최대한 활용함으로써 클라우드 컴퓨팅 시스템의 장점을 100% 활용할 수 있게 하는 Architecture(개발 방식)이라고 할 수 있을 것이다.
Cloud Native Architecture를 처음 정의한 CNCF는 클라우드 네이티브 아키텍처를 아래와 같이 설명했다.
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
클라우드 네이티브 기술을 통해 조직은 현대의 동적 환경에서 확장 가능한 Application을 구축하고 실행시킬 수 있다.
컨테이너, 서비스 매쉬, 마이크로서비스, 불면 Infra와 선언적 API는 이를 가능하게 한다.
클라우드 네이티브를 위한 4가지 핵심 요소는 위 사진에도 나와 있듯 DevOps, Microservice, Container, 그리고 CI/CD이다.
우리는 이전에 DevOps, Containers, Microservices, CI/CD를 모두 공부했었다.
참고로 CI/CD를 빼고 Service Meshes를 핵심 요소로 간주하는 Case도 있다. 서비스 매시란 프록시를 활용하여 MSA에서 잘게 쪼개진 Service끼리 원활히 통신하게 할 수 있는 인프라 계층을 말한다.
서비스 매시랑 가장 비교되는 것이 앞서 설명했던 API Gateway이다.
API Gateway는 Microservice의 Component를 외부 Client에게 전달하기 위한 중간 과정이다.
즉, 마이크로서비스 외부 고객들이 Application에 접속할 수 있게 도와주는 역할을 수행하는 것이다.
Service Mesh는 MSA 내부에서 Component 사이에서 식별, Routing 및 Load Balancing, 인증(인가), 보안 등의 역할을 담당한다.
Service Mesh는 아키텍처를 구성하는 서비스 블록을 서비스 메시라는 형태로 구성해야 한다. 그리고 이 서비스 메시를 관리해주는 Application에서 메시 사이의 이벤트를 관리해주는 것이다. 대표적인 서비스 메시가 Docker와 Kubernetes인데, 개발자는 서비스 블록을 Container Image라는 서비스 메시로 만들고 만들어진 Container들을 모두 Kubernetes를 통해 관리해주는 방식이다.
간단히 말하자면, API Gateway는 MSA의 서비스와 User 사이를 중재하는 역할, Service Mesh는 MSA의 서비스 사이를 중재하는 역할을 수행하는 SW인 것이다.
Cloud Native Architecture 특징
확장 가능한 아키텍처
클라우드 네이티브 아키텍처는 수평적인 확장에 유연하다.
수평적인 확장이란 필요에 따라 서버를 늘이고 줄일 수 있는, Scale-Out뿐만이 아닌 서버를 줄이는 Scale-In까지 수행할 수 있어 서버의 트래픽에 유연하게 대응할 수 있다는 의미이다.
클라우드 네이티브 아키텍처는 Auto Scaling을 통해 시스템의 부하를 분산시킬 수 있고 이에 따라 가용성을 보장한다.
또한 Docker를 활용하여 새로운 서버에 Service를 손쉽게 배포 및 제공할 수 있게 된다.
탄력적 아키텍처
서비스의 생성, 통합, 배포에서 반복적인 작업을 자동화하고 최대한 과정을 간소화시킴으로써 비즈니스 환경에 변화에 대응하는 시간을 단축한다. 이를 위해 CI/CD 자동화를 활용한다.
클라우드 네이티브 아키텍처에서는 MSA를 활용하는데 자동화된 CI 및 CD를 통해 개발자는 매번 모든 서비스를 통합 배포해야 하는 수고가 없어지며 Service 개발에 조금 더 집중할 수 있게 된다.
추가적으로 MSA를 활용할 수 있기 때문에 서비스 간의 종속성을 줄일 수 있으며 서비스의 추가, 삭제, 변경 등을 감지하여 알아서 처리할 수 있게 된다.
장애 격리(Fault Isolation)
MSA에서는 서비스가 서로 낮은 결합도를 가지고 있기 때문에 특정 서비스에 오류가 발생하더라도 다른 서비스에 영향을 미칠 확률이 매우 낮고, 이를 장애 격리라고 한다.
클라우드 네이티브 아키텍처가 각광받는 이유
어디까지나 여러 사이트에서 클라우드 네이티브 아키텍처에 대해 조사해본 결과 도출된 개인적인 생각이라는 것을 명시하고 가겠다.
필자는 클라우드 네이티브 아키텍처가 각광받는 이유는 클라우드 컴퓨팅이 각광받았기 때문이라고 생각한다.
사실 MSA나 DevOps, Container같은 것이 장점만을 가지지는 않는다. 이전에도 말했듯이 오히려 Monolithic이나 Waterfall Model이 더 좋은 경우도 많다.
하지만 3가지 개념에 대한 공통점이 존재하는데, 바로 클라우드 환경과 매우 잘 맞는 개념이라는 것이다.
Cloud 환경은 사용양에 비례하기 때문에 당연히 작은 서비스를 구축하는 것이 비용적으로 절약되고, 이 때문에 MSA라는 Architecture가 도입되었다. 그리고 작은 서비스를 계속해서 개발하는 MSA에 있어서 고객의 피드백을 자주 받을 수 있고 서비스를 개발하자마자 빠르게 User에게 제공할 수 있는 DevOps가 유리했을 것이다.
또한 Cloud가 유명해지며 DevOps가 유명해졌고 개발팀은 운영에 대한 지식도 필요해졌다. 이런 운영에 대한 부담을 가장 줄여줄 수 있는 Container는 당연히 큰 관심을 끌게 되었다고 생각한다.
즉, MSA와 DevOps, Container는 각자 단점도 명확한 기술이다.
하지만 Infra에 있어서는 Hosting이나 On-Premise가 Cloud를 절대 따라올 수 없다고 (개인적으로) 생각하며, 이에 따라 기업들은 Cloud 서비스를 적극 도입하였다. 이 과정에서 Cloud 기술과 찰떡궁합인 MSA, DevOps, Container의 인기가 급부상하며 Cloud Native Architecture라는 것이 각광받았다고 생각한다.
Cloud Native Architecture에 사용되는 기술들
-
출처 : http://drive.google.com/uc?export=view&id=1xmp0PX3CnsUpNiYWtL-flkV9M06quKV4
-
Gateway
- API Gateway를 의미함
- MSA에서 Component끼리 통신하는 것을 도와주는 역할
- 대표 : NGINX, AWS API Gateway, apigee, NETFLIX OSS(Spring Cloud에서 이전에 활용했음)
-
Servie Mesh
- Service 사이의 통신을 위한 기술
- 대표 : NETFLIX OSS, Istio(쿠버네티스와 잘 연동됨), Consul
-
Runtime
- Service를 배포하여 운영할 환경 설정에 대한 기술
- 대표 : Docker, Kubernetes, AWS EC2, Google Container Engine(GCE)
-
Frameworks
- SW(서비스)를 개발하기 위해 활용하는 기술
- 대표 : Spring Boot, Spring Cloud, Flask, AxonFramework
-
Automation
- 자동화를 통해 CI/CD에 필요한 반복 작업을 줄여줄 수 있는 기술
- 대표 : Maven, Jenkins, Ansible, Gradle
-
Telementry
- 서비스의 모니터링을 위해 지표를 수집하거나 로그를 수집할 수 있게 도와주는 기술
- 대표 : fluentd, Datadog
-
Backing Services
- 애플리케이션이 실행되는 과정에서 네트워크를 통해 활용할 수 있는 모든 서비스
- DB는 애플리케이션이 실행되는 과정에서도 접속 가능하므로 대표적인 Backing Service라고 할 수 있음
- 대표 : RabbitMQ, redis, kafka
그림으로 보는 MSA 상세 Architecutre
- 출처 : Gartner
지금까지 설명한 내용을 모두 제대로 이해했다면 매우 쉽게 위 그림 파악이 가능할 것이다.
위 사진에서 먼저 봐야할 것은 Legend의 Inner Architecture와 Outer Architecture Capability이다.
Outer Architecture라는 것도 존재하는데, Outer Architecture Capability가 Outer Architecture의 역할을 수행하는 능력을 가진 기술들이므로 사실상 Outer Architecture Capability가 실행되는 것을 Outer Architecture라고 이해하면 될 것이다.
Inner Architecture는 Domain과 관련된 구성 요소이다.
이를 쉽게 풀어보자면 고객에게 제공하는 Service와 비즈니스 로직에 직접적으로 관련된 기술이라고 할 수 있겠다.
Outer Architecture는 Inner Architecture가 수월하게 동작할 수 있도록 도와주는 Supporting 기술을 말한다.
Outer Architecture를 보면 CI/CD 툴이나 Load Balancing 등의 기술이 존재함을 알 수 있다. 이런 기술이 없다고 고객에게 Service를 제공 못하지는 않지만, 고객에게 서비스를 안정적이고 쉽게 제공할 수는 없을 것이다.
정리하자면 Inner Architecture는 없을 경우 고객이 서비스를 아예 활용할 수 없는 핵심 기술들, Outer Architecture는 없어도 고객이 서비스를 사용할 수는 있으나 안정적이고 만족도 높은 서비스를 제공받을 수는 없게 되는 기술들이다.
사진을 보며 간단히 보자. 지금까지 배웠던 내용의 복습 정도니 빠른 이해가 가능할 것이다.
고객(User) 측면
- 고객이 다양한 단말기를 통해 Service를 사용하려고 접근한다
- API는 고객에게 안전한 서비스를 제공하기 위해 SSL 같은 인증서를 검사하고, 원하는 서비스를 활용할 수 있도록 API Gateway를 활용해 요청한 서비스와 연결시켜주며 필요에 따라 고객에게 인증을 요구하기도 할 것이다.
- External Gateway 과정
- 고객의 요청이 서비스 내부로 오면 작게 분할된 Service Mesh 중 고객의 요청을 처리할 Inner Architecture를 선택함으로써 데이터를 처리할 준비를 마친다.
- Service Mesh 과정
- Load Balancing을 통해 Inner Architecture끼리 최대한 공평하게 자원을 분배받은 상태에서 핵심 서비스(Inner Architecture)가 실행되며 고객의 요청에 맞게 데이터를 처리한 이후 결과값을 고객에게 반환한다.
- 이 과정에서 DB 등의 외부 서비스와 접근할 수도 있다.(Backing Services)
- Application은 Telemetry에 실행 로그를 남기고 실행 시간이나 메모리 같은 성능 관련 정보를 보고하기 때문에 서비스 운영자는 성능 및 동작 상황을 실시간으로 모니터링할 수 있다(Telemetry)
- Runtime Platform 과정
개발자 측면
CI/CD 자동화 Tool을 활용하여 고객에게 최대한 빠르고 쉽게 안정적인 서비스를 제공할 수 있게 된다.
- CI/CD Automation 과정
