Cloud Native Architecture란
- 기존의 온프레미스 인프라가 아닌 클라우드에 존재하도록 설계된 서비스의 설계 방식이다.
Cloud Native Architecture 특징
확장 가능한 아키텍처
- 시스템의 수평적 확장에 유연
- 확장된 서버로 시스템 부하분산, 가용성 보장
- 시스템 또는 서비스 애플리케이션 단위 패키지(컨테이너 기반 패키지)
- 모니터링
- scale up: 하드웨어 사양을 업그레이드하여 시스템을 확장
- scale out: 여러 대의 서버를 추가하여 시스템을 확장(각 서버에 걸리는 부하를 균등하게 해주는 로드밸런싱이 필수적)
탄력적 아키텍처
- 서비스 생성-통합-배포, 비즈니스 환경 변화에 대응 시간 단축
- 분할된 서비스 구조
- 무상태 통신 프로토콜
- 서비스의 추가와 삭제 자동으로 감지
- 변경된 서비스 요청에 따라 사용자 요청 처리(동적 처리)
장애 격리 (Fault isolation)
- 특정 서비스 오류 발생해도 다른 서비스에 영향 주지 않음
Cloud Native Application (Cloud Native를 위한 4가지 핵심 요소)
CNCF에서 제시한 클라우드 네이티브는 4가지의 핵심 요소들을 포함하고 있다.
- DevOps
- CI / CD
- Containers 가상화
- MSA(Microservice Architecture)
1. DevOps
- Development + Operations + QA
- 개발조직과 운영조직의 통합을 의미한다.
- 고객의 요구사항은 수시로 변경될 수 있으므로 바로 수정이 가능하도록 구성하는 것이 중요하다.
- 고객의 요구사항을 수시로 반영한다는 것은 개발 일정을 더디게 하는 원인이 될 수도 있지만 결과적으로 개발하고 있는 애플리케이션은 오류 없는 안정적인 시스템이어야 한다.
2. CI / CD
지속적인 통합 CI (Continuous Integration)
- 통합 서버, 소스 관리(SCM), 빌드 도구, 테스트 도구
- ex) jenkins, Team CI, GitHub Action
지속적 배포
- Continuous Delivery: 지속적인 전달, 패키징 된 소스를 수작업으로 배포하는 경우
- Continuous Deployment: 지속적인 배포, 실행 환경까지 자동적으로 배포하는 경우
- pipe line
3. Container 가상화
컨테이너 가상화란 클라우드 환경으로 이전해서 적은 비용으로 탄력적으로 시스템 환경을 구성하는 것이다.
컨테이너 가상화는 클라우드 네이티브 아키텍처의 핵심으로 기존 서버 가상화보다 적은 자원을 사용하여 가상화 서비스를 구축할 수 있다.
1. 전통적인 시스템: 하드웨어 - 운영체제 - 여러 앱
2. 가상화 개발 시스템: 하드웨어 - 운영체제 - 가상머신 - 여러 앱
- 가상머신에서 작동되는 앱들은 Host System이 가지고 있는 물리적인 하드웨어를 나누어 사용하기 때문에 호스트 하드웨어에 많은 부하가 존재하며 시스템 확장의 한계가 존재한다.
3. 컨테이너 가상화 기반 시스템: 하드웨어 - 운영체제 - Container Runtime(공용 라이브러리) - 여러 앱
- os위에 컨테이너 가상화를 위한 소프트웨어(docker 등)를 기동한다.
4. MSA (Micro Service Architecture)
MSA(Micro Service Architecture)는 하나의 애플리케이션을 여러 서비스로 작게 나누고 서비스들끼리 통신하는 형태의 아키텍처로 구축하는 것을 의미한다.
기존 모놀리식 구조의 경우 전체 애플리케이션이 1개로 이루어져 있어 한 부분을 수정하면 전체 애플리케이션을 재배포해야 한다는 단점이 있다.
반면에 MSA는 서비스 별로 개발, 배포, 확장이 가능하고 서비스마다 언어와 인프라를 개별적으로 사용할 수 있다는 장점이 있으며 개발 중간에 새로운 요구사항에 대해서 빠르게 대응할 수 있고 하나의 서비스에서 장애가 생겨도 전체 시스템의 장애로 연결되지 않는 장점이 있다.
단점으로는 서비스 간 통신을 하는 구조이기 때문에 속도가 모놀리식보다는 느리다.
12 Fators
https://12factor.net
클라우드 네이티브 앱을 구축하면서 고려할 사항 12가지 요소
- Codebase : 버전 제어, 형상관리 목적으로 코드의 통일적 관리가 필요, 코드를 한 곳에서 배포하게 리포지토리 설정
- Dependency Isolation: 각 msa는 자체 종속성을 가지고 패키징 됨, 전체 시스템에 영향을 주지 않고 변경이 가능하도록 코드를 구성
- Configurations: 시스템 외부에서 구성관리 서비스로 환경설정이 가능해야 함
- Linkable Backing Services: 추가적 기능 지원 가능하도록 분리해야 함
- Build, release, run: 빌드, 배포, 실행환경의 분리
- Processes: 자체 프로세스에서 운영될 수 있어야 한다(독립성). msa는 각각 분리되어 실행되어야 한다.
- Port Binding: msa 간 통신하는 포트가 존재해야 한다.
- Concurrency: 하나의 서비스가 여러 인스턴스에 동일한 형태로 복제되어 부하 분산이 가능해야 한다.
- Disposability: 서비스 인스턴스 삭제가 가능해야 하고 확장성 및 정상 종료가 되어야 한다.
- Dev & Production parity: 개발, 프로덕션 단계 구별이 필요하다.
- Logs: 앱이 실행되지 않아도 로그는 지속적으로 출력되어야 한다.
- Admin Processes: 기동 된 msa 자원이 어떻게 사용되는지 상태 파악을 하는 관리 도구가 필요하다.
- API first: msa 간 api로 통신해야 한다.
- Telemetry: 모든 지표는 수치화, 시각화되어야 한다.
- 인증과 인가
- 위 13번부터 15번은 피보탈회사가 3개를 더 추가함.
해당 포스팅은 인프런 사이트의 Spring Cloud로 개발하는 마이크로서비스 애플리케이션 강의를 기반으로 작성한 내용입니다.
'MSA' 카테고리의 다른 글
[MSA] Spring Cloud Gateway(SCG)에서 Rate Limiter 구현 (feat, redis & docker) (1) | 2024.12.07 |
---|---|
[MSA] Spring Cloud Gateway를 활용한 API Gateway 구현 (0) | 2024.05.31 |