[클라우드 서비스] Microservices_20241205

1. 클라우드 네이티브(Cloud Native)

- 클라우드 컴퓨팅 환경에서 현대적 애플리케이션을 구축, 배포 및 관리하는 접근 방식

- 클라우드 이점을 최대한 활용할 수 있도록 애플리케이션을 구축 및 운영하고, 고객의 요구에 맞게 신속하게 업데이트할 수 있는 확장성, 유연성 및 복원력이 뛰어난 애플리케이션을 구축 및 운영한다.

 

(1) 전통적인 애플리케이션 vs 클라우드 네이티브 애플리케이션

	전통적인 애플리케이션	클라우드 네이티브 애플리케이션
구축/운영	온프레미스(Data center) 환경	클라우드 환경
아키텍처	모놀리스	마이크로 서비스
컴퓨팅 기술	물리적 서버(+가상화)	컨테이너
조직/프로세스	역할별 분리 (개발, 운영, QA 등)	DevOps
빌드/배포	수작업	CI/CD, 자동화 도구

=> 한개로 전체를 통합 vs 여러 개로 작게 쪼겜

 

(2) Monolithic 아키텍처 vs Microservices(MSA) 비교

	Monolithic	Microservice
장점	- 단일 코드 베이스로 애플리케이션 개발이 용이 (어떤 기능이든 개발 환경이 같아서 복잡X) - 실행 파일 또는 디렉토리가 하나여서 배포가 용이 - 분산된 애플리케이션에 비해 테스트를 더 빠르게 수행 - 내부 프로세스 간 통신 지연시간 최소화	- 기능이 추가되거나 수정해야 할 서비스만 빠르게 빌드, 배포할 수 있음(독립성) - 전체 애플리케이션이 중단될 위험 없이 특정 서비스에 대한 변경 사항을 배포(안정성) - 일부 기능 오류가 있으면 해당 기능만 오류가 발생하고, 그 부분만 빠르게 고쳐서 정상화가 가능(높은 유지 관리성) - 해당 기능에 적합한 기술, 언어, 버전, DB 등을 선택하여 사용할 수 있음(기술 유연성)
단점	- 대규모 애플리케이션인 경우 많은 양의 코드를 개발자가 모두 이해하기 어렵기 때문에 추가 개발 및 유지보수가 어려움 - 일부분의 기능 오류가 전체 애플리케이션에 영향, 개별 컴포넌트 쉽게 확장할 수 없음 (안정성, 확장성 저하) - 작은 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야 함 (변경이 어려움)	- 여러 팀이 작은 수많은 서비스를 만들기 때문에 관리하기 어려움 (무분별한 개발 확산의 위험, 표준화 부족 등) - 서비스들끼리 네트워크 상에서 서로 통신을 하는 과정에서 모놀리식 아키텍처에 비해 통신관려 오류 발생 多 - 각각의 서비스별로 테스트 도구, 호스팅 인프라, 모니터링 도구 등에 대한 자체적인 비용이 발생

 

=> 하지만, MSA 도입이 필수적인 것은 아니다. 조직의 필요와 기술 환경에 따라 선택할 수 있다.

- 위 장단점을 보았을 때

- MSA는 애플리케이션의 복잡성이 높고 규모가 큰 곳, 팀이 분산되어 있고 독립적인 작업을 선호, 빈번한 배포와 확장이 필요한 환경, 다양한 기술 스텍과 도구를 활용해야 하는 경우 알맞다.

(ex. Neflix : 전 세계 사용자를 위한 고가용성과 확장성을 확보, 각 서비스는 독립적으로 배포 및 확장이 가능)

- Monolithic의 경우, 작은 규모의 포르젝트이거나 초기 단계에서 빠른 개발이 중요한 경우, 팀 리소스가 제한적이거나, MSA 운영 경험이 부족한 경우, 애플리케이션의 요구 사항이 단순하고 변경이 적은 곳에서 활용하는 것이 알맞다.

(ex. 스타트업 : 빠른 제품 출시가 목표이며, 초기 복잡성을 줄이고, 사용자가 증가하면서 MSA로 전환한다.)

 

2. 컨테이너

- 운영 체제에서 실행되는 프로세스를 격리하여 별도의 실행 환경(SW 서비스 구동을 위한 격리환경)을 제공하는 운영체제 수준의 가상화 기술

- 이식성(이동성), 경량성, 확장성, 운영 효율성 측면에서 장점을 보유한 기술이다.

- 마이크로 서비스 아키텍처(MSA)를 채택한 애플리케이션에 이상적인 선택이다.

 

- 개발, 테스트, 운영 환경에 설치되어 있는 라이브러리 버전이 다를 경우, 로컬에서 개발할 때는 잘 실행되던 애플리케이션이 다른 환경에서는 구동되지 않는 문제가 자주 발생한다.

- 컨테이너는 애플리케이션 코드, 런타임, 라이브러리, 구성을 하나의 객체로 패킹한 것으로,

- 리소스가 격리된 프로세스 형태로 실행되어 서로 다른 환경에서도 빠르고 안정적으로 실행이 가능하다.

 

(1) 가상머신과 컨테이너 비교

이미지 출처 : 가비아

	가상 머신	컨테이너
시작 시간	수분	수초
이미지 크기	GB 단위	MB 단위
플랫폼	하이퍼바이저(Hypervisor)	도커(Docker)
Guest OS	Linux/Windows 등 다양	Host OS 활용

출처 : 오픈마루

 

(2) 컨테이너 실행

출처 : 마이크로소프트

 

- Docker file(컨테이너 이미지를 만드는 명령이 포함되어 있는 템플릿)을 생성한 후 이를 빌드하여 컨테이너 이미지(컨테이너 실행에 필요한 파일과 설정 값 등을 포함) 생성

- 컨테이너 이미지를 Docker Hub와 같은 공용 레지스트리나 Amazon ECR과 같은 프라이빗 레지스트리 저장소로 푸시

- 레지스트리에서 컨테이너 이미지를 가져와서 컨테이너를 실행

 

=> 단일 호스트에서 소수의 컨테이너를 실행하고 관리하는 것은 쉽지만 수십 개 호스트 위에 수백~수천 개 컨테이너가 구동되는 애플리케이션 운영 환경에서는 어떻게 관리해야 할까?

 

3. 쿠버네티스

https://beer1.tistory.com/5?pidx=0

- 컨테이너 오케스트레이션 도구(또는 컨테이너 관리 플랫폼)는 컨테이너 관리, 배포, 확장 등을 자동화하는 데 사용되며 Kubernetes, Docker Swam 등 다양한 제품이 있는데,

- 그 중 쿠버네티스는 벤더나 플랫폼에 종속되지 않고 오픈 소스 생태계의 광범위한 제품과 결합하여 활용할 수 있어 클라우드나 온프레미스 환경에서 널리 활용 중이다.

 

(1) Control Plane & Data Plane

https://www.wallarm.com/what/what-is-the-control-plane

① Control Plane

- 클러스트와 워커 노드 내 Pod을 예약, 상태 감시 및 제어, 관리하는 역할을 담당

② Data Plane

- 컨테이너화된 애플리케이션의 구성 요소인 Pod을 호스팅하는 워커 노드를 생성 및 관리

구분	컨트롤 플레인	데이터 플레인
역할	클러스터 상태 관리, 지시	작업 실행 및 실제 워크로드 처리
구성 요소	API 서버, 스케줄러, 컨트롤러, etcd	노드, kubelet, kube-proxy, 컨테이너 런타임
책임	의사 결정, 상태 감시 및 복구	파드 실행, 네트워크 및 데이터 처리
비유	항공 관제탑	항공기 및 승무원

 

- 퍼블릭 클라우드의 관리형 쿠버네티스 서비스는 고객이 직접 구축 및 관리하기 어려운 쿠버네티스의 Control plane과 Data plane을 설치, 관리하는데 최적화된 환경을 제공해준다.

- 퍼블릭 클라우드 내 다양한 연계 서비스와 유기적으로 통합되어 있어 보다 편리한 쿠버네티스 운영 환경을 제공하며 최근 서버리스 형태로 계속 발전해가고 있다.