Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)
Monolithic VS Microservice
- Monolithic
- 어플리케이션 개발에 필요한 모든 요소를 하나의 소프트웨어에 포함시켜 개발하는 방법
- DB 로직, 비즈니스 로직, 프론트엔드 등 모든 서비스들이 유기적으로 연결되어있고, 배포 시에도 서로 의존성을 가진 채 패키징된다.
- Microservice
- 어플리케이션을 구성하는 각각의 구성 요소 및 서비스의 내용을 분리해서 개발하고 운영하는 방식이다.
- 유지보수 및 변경 사항을 적용하는데 더 유리하다.
Monolith Architecture
- 모든 업무 로직이 하나의 어플리케이션 형태로 패키징
- 어플리케이션에서 사용하는 데이터가 한 곳에서 참조되어 서비스 되는 형태
- 어느 한 서비스를 수정 및 변경하면 모든 서비스를 전체적으로 다시 패키징하여 배포해야한다는 단점이 있다.
Microservice
- HTTP Resource API 통신을 할 수 있는 작은 규모의 여러 서비스들의 묶음 → 이게 모여 하나의 어플리케이션이 된다.
- 이러한 서비스들은 비즈니스 기능을 중심으로 구축되어야 함
- 완전하게 자동화 된 배포 시스템을 사용해야 함(CI/CD)
- 각각의 서비스들은 최소한의 중앙 집중식 관리가 되어야 함
- 서로 다른 프로그래밍 언어와 서로 다른 데이터 베이스를 사용할 수 있다.
Microservice Architecture란?
- Microservice 특징
- Challenges : 기존의 개발 방식이나 패러다임을 상당 수 바꿔야 한다.
- Small Well Chosen Deployable Units : 독립적으로 배포 가능한 형태의 작은 서비스로 이루어짐
- Bounded Context : 서비스 경계를 잘 구분해야하며, 이 서비스 경계로 인해 두 개의 서비스가 하나의 서비스가 되기도 함
- RESTful : 각 서비스들은 서로 상태에 대해 REST API로 통신해야한다.
- Configuration Management : 마이크로서비스와 관련된 설정 정보들은 코드 내에 있는게 아니라 외부에 두어 관리한다.
- Cloud Enabled : 클라우드 네이티브 기술을 최대한 활용해서 서비스 제공
- Dynamic Sacle Up And Scale Down : 인스턴스들의 부하분산을 Sacle Up이나 Scale Down 등을 동적으로 처리할 수 있어야 한다.
- CI/CD : 자동화 된 배포 시스템
- Visibility : 마이크로서비스와 관련된 것들을 시각화해서 관리할 수 있어야 함
SOA VS MSA
서비스의 공유 지향점
- SOA - 재사용을 통한 비용 절감
- MSA - 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응
기술 방식
- SOA - 공통의 서비스를 ESB에 모아 사업 측면에서 공통 서비스 형식으로 서비스 제공
- MSA - 각 독립된 서비스가 노출된 REST API를 사용
RESTful 성숙도 모델
- Level 0 : The Swamp of POX
- REST 방식을 전혀 고려하지 않음
- 리소스를 단순하게 웹 서비스로 제공하기 위해 uri을 매핑한 형태
- Level 1 : Resources
- 외부에 노출하는 리소스에 대해 의미있고 적절한 uri로 표현하는 단계
- HTTP Method를 사용하진 않음
- Level 2 : HTTP Verbs
- Level 1 + HTTP Method 사용
- Level 3 : Hypermedia Controls
- Level 2 + HATEOAS
- DATA + NEXT POSSIBLE ACTIONS
REST API 설계 시 고려사항
- Consumer first : 소비자 입장에서 간단 명료하고 직관적인 API를 설계해야 함
- Make best use of HTTP : HTTP Method와 header 값 등의 HTTP의 장점을 최대한 살려서 개발
- Request methods
- GET
- POST
- PUT
- DELETE
- Response Status : API 요청에 따라서 적절한 응답 코드를 보내줘야 함
- 200번대 - 클라이언트의 요청이 정상적으로 처리됨
- 400번대 - 클라이언트쪽으로부터 발생된 오류
- 500번대 - 서버쪽으로부터 발생된 오류
- No secure info in URI
- Use plurals : 복수형태의 uri를 사용
- prefer /users to /user
- prefer /users/1 to /user/1
- User nouns for resources : 모든 리소스는 되도록 명사 형태로 표현
- For exceptions
- define a consistent approach : 일관된 endpoint를 사용하는 것이 좋음
Microservice Architecture Structures
- 넷플릭스, 아마존, 트위터, 나이키 등이 채택한 아키텍처
- 요청 전달 흐름
- 다양한 디바이스나 다른 마이크로서비스의 요청이 API를 통해 한 곳에 모아진다.
- 이 수집한 요청들을 Service Router에게 전달하고, Service Router는 Service Discovery에서 목적지 관련 정보를 찾는다.
- 목적지를 찾았다면 Load Balancing을 통해 진한 남색으로 표시된 마이크로 서비스들에게 요청이 전달된다.
Service Mesh Capabilities
- Service Mesh
- Microservice arhitecture를 적용한 시스템의 내부 통신
- service mesh를 통해서 서비스들 간의 통신을 추상화하고 안전하고 빠르고 신뢰성있게 만들어주는 Infra Structure의 Layer
- MAS 인프라 → 미들웨어
- 프록시 역할, 인증, 권한 부여, 암호화, 서비스 검색, 요청 라우팅, 로드 밸런싱
- 자가 치유 복구 서비스
- 서비스 간의 통신과 관련된 기능을 자동화
CNCF(Cloud Native Computing Foundation)
- Cloud Native Interactive Landscape
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란?
Spring Cloud
Spring Cloud is an umbrella project consisting of independent projects with, in principle, different release cadences. To manage the portfolio a BOM (Bill of Materials) is published with a curated set of dependencies on the individual project. Go here to r
spring.io
Spring Cloud는 개발자가 분산 시스템에서 일부 공통 패턴(예: 구성 관리, 서비스 검색, 회로 차단기, 지능형 라우팅, 마이크로 프록시, 제어 버스, 일회성 토큰, 글로벌 잠금, 리더십 선거, 분산 세션, 클러스터 상태). 분산 시스템의 조정은 상용구 패턴으로 이어지며 Spring Cloud를 사용하는 개발자는 이러한 패턴을 구현하는 서비스 및 애플리케이션을 신속하게 구축할 수 있습니다. 개발자의 노트북, 베어메탈 데이터 센터, Cloud Foundry와 같은 관리형 플랫폼을 포함한 모든 분산 환경에서 원활하게 작동합니다.
즉, MSA 구성을 지원하는 Springboot 기반의 Framework이다. 그래서 Spring Cloud를 사용하기위해선 Springboot를 같이 꼭 사용해야한다. 그래서 홈페이지에서 잘 찾아보면 springboot와 spring cloud의 연동 버전 정보가 올라와있다.
사용할 프로젝트
- Centralized configuration management → Spring Cloud Config Server
- 다양한 마이크로서비스에서 사용할 수 있는 환경 정보들을 Spring Cloud Config Server를 통해 외부 저장소(Git 등)에 보관할 수 있다.
- 환경 정보들을 외부 저장소가 아닌 내부에 하드 코딩으로 저장하게되면 설정이 변경될 때마다 재배포를 해야함
- Location transparency → Naming Server(Eureka)
- 서비스의 등록과 위치 정보 확인, 검색과 같은 기능을 사용할 수 있음
- Load Distribution(Load Balancing) → Ribbon(Client Side), Spring Cloud Gateway
- 서버에 들어오는 요청 정보를 분산하기 위해 사용
- Easier REST Clients → FeignClient
- 마이크로서비스 간의 통신을 위해서 사용
- Visibility and monitoring → Zipkin Distributed Tracing, Netflix API gateway
- Fault Tolerance → Hystrix
- 장애가 발생했을 시 복구를 위한 회복성 패턴
- 출처 : 인프런 Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) 강의
