시간이 지날 수록 소프트웨어는 Antifragile한 아키텍처를 구성하고자 하였으며, Cloud Native한 아키텍처를 구성하고자 했다. 아래는 그러한 소프트웨어 아키텍처의 특징을 정리한 내용이다.
1. Antifragile 아키텍처
1) AutoScaling (자동확장성)
: 상황에 따라 인스턴스의 갯수를 자동으로 늘리는 등 자동 확장이 가능한 것
2) Microservices
: 세밀한 단위로 모듈과 기능을 세분화한 서비스. 넷플릭스와 아마존에서 가장 잘 구축했음
3) chaos engineering
: chaos, 급격하고 예측 불가한 상황에서도 견딜 수 있을 만큼 안정적인 서비스 구축
4) continuous deployments
: 지속적인 통합/배포를 의미
2. Cloud Native 아키텍처
1) 확장 가능한 아키텍처
: 확장/수평된 형태로 시스템의 부하를 분산해 가용성을 높인다. (Scale-out)
: 컨테이너 기반의 어플리케이션 단위 패키지를 구성하고, 모니터링을 한다.
2) 탄력적 아키텍처
: 각 기능을 분리된 서비스로 구성하고, 자동화 파이프라인을 통해 배포해 배포 시간을 단축시킨다.
3) 장애 격리
: 특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않는다.
3. Cloud Native Application 특징
1) MSA로 개발된다
2) CI/CD : 지속적인 통합과 배포
- 지속적인 통합을 위해 jenkins, Team CI, Travis CI 를 사용할 수 있다.
- 지속적인 배포에는 continuous delivery(수동반영)/continuous deployment(자동반영)가 있다
- 카나리 배포 또는 블루그린 배포 사용 가능
3) Devops : 구현-테스트-배포를 무한 반복
4) Containers : 컨테이너 가상화 기술
아래부터는 MSA 서비스를 위한 12가지 요인들과 MSA의 특징을 정리했다.
4. 12 Factors
MSA 서비스를 위해 필요로 하는 12가지 요인들이다.
피보탈에서 아래에 +3 (Api First, Telemetry(수치화/시각화), Authentication and authorization) 을 더 추가했다.
I. Codebase
One codebase tracked in revision control, many deploys
> 리포지토리에 저장한 각 마이크로 서비스에 대한 단일 코드베이스 / 버전 제어 위함 / 코드는 한 곳에서 배포
II. Dependencies
Explicitly declare and isolate dependencies
> 종속성. 각 마이크로 서비스는 각각의 모듈에 종속적이라 전체 서비스에 영향을 주지 않음
III. Config
Store config in the environment
> 설정
IV. Backing services
Treat backing services as attached resources
> 서비스 지원. 데이터/캐싱/메시징 등을 지원
V. Build, release, run
Strictly separate build and run stages
> 빌드/릴리즈/실행환경을 분리하라. 각 태그 있고 분리되며 자동화된 배포가 이뤄져야한다.
VI. Processes
Execute the app as one or more stateless processes
> 하나의 프로세스는 다른 프로세스와 독립되어야 한다.
VII. Port binding
Export services via port binding
> 포트 바인딩. 각 서비스별로 포트가 달라야한다.
VIII. Concurrency
Scale out via the process model
> 동시성. 하나의 서비스가 여러 인스턴스에 나뉘며 부하 분산 -> 동시성을 가져야 한다.
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
> 확장성. 서비스 인스턴스 등록 및 삭제 / 실행이 쉬워야
X. Dev/prod parity
Keep development, staging, and production as similar as possible
> 개발/운영 분리
XI. Logs
Treat logs as event streams
> 로그를 출력하는 로직을 어플리케이션과 분리해야 한다. (별도의 모니터링)
> Azure 또는 ELK를 사용할 수 있음
XII. Admin processes
Run admin/management tasks as one-off processes
> 적절한 관리. 마이크로 서비스가 어떠한 상태로 사용되며 리소스가 어떻게 쓰이는지
데이터를 정리하고 분석하는 기능을 통해 관리가 가능하다.
5. 모놀리틱 vs Microservice
모놀리틱은 하나에 모든 서비스를 다 넣는다면, MSA는 서비스를 분리해서 개발하고 운영하는 걸 말한다.
유지보수가 쉽다. 필요한 서비스만 독립적으로 배포가 가능하다.
6. MSA 표준 구성 요소
[1] MSA 표준 구성 전반
- 전반적인 프로세스
- 클라이언트 => API gateway => Service Router -> Service Discovery (A서비스 찾음) => Load Banlancing통해 A서비스 중 1번 인스턴스로 접근
- CI/CD Automation
- Backing Service
- Telemetry (Monitoring, 진단)
[2] MSA 기반 기술
- CNCF(Cloud Native Computing Foundation) https://landscape.cncf.io/
Cloud Native Landscape
The Cloud Native Landscape organizes all cloud native open source projects and proprietary products into categories, providing an overview of the current ecosystem
landscape.cncf.io
스프링부트의 Spring Cloud를 사용하면 MSA 환경을 구성할 수 있다.
7. Spring Cloud
https://spring.io/projects/spring-cloud
Spring Cloud는 개발자가 분산 시스템에서 일부 공통 패턴
(예: 구성 관리, 서비스 검색, 회로 차단기, 지능형 라우팅, 마이크로
프록시, 제어 버스, 단기 마이크로서비스 및 계약 테스트)을 신속하게 구축할 수 있는 도구를 제공합니다.
스프링 클라우드의 특징들은 아래와 같으며, 다양한 내부 프로젝트들을 통해 각 특징을 구현할 수 있다.
- 분산/버전 관리 구성
- 서비스 등록 및 검색
- 라우팅
- 서비스 간 통신
- 로드 밸런싱
- 회로 차단기
- 분산 메시징
- 단기 마이크로서비스(작업)
- 소비자 중심 및 생산자 중심 계약 테스트
수업에서는 이들중에서도, 아래의 내부 프로젝트들을 소개했다.
- 중앙 설정 관리 : Spring Cloud Config Server
- Location Transparency : Naming Server(Eureka) = 서비스의 위치 확인 및 검색
- Load Distribution : Ribbon 대신 Spring Cloud Gateway 사용 (최신 버전에서 권장됨)
- Easier REST clients : Feign Client
- Visibility and monitoring : Zipkin Distributed Tracing, Netflix API gateway
- 장애 복구 : Hystrix
[출처]
인프런 - Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)
[참고]
'Framework > Spring' 카테고리의 다른 글
Spring Cloud - Netflix Eureka, Spring Gateway (1) | 2024.04.27 |
---|---|
[Spring Cloud & MSA] Spring Cloud Netflix Eureka (0) | 2024.01.10 |
[스프링] Build.Gradle & application.yml 관련 메모 (0) | 2022.10.28 |
[스프링] @AutoWired 동작 원리 및 DI injection 관련 설명 모음 (0) | 2022.10.20 |
[HTTP] @RequestParam vs @RequestBody (0) | 2022.10.19 |