[SpringCloud MSA]MicroService 와 SpringCloud의 소개
0
이 글은 인프런 강의 "Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)"를 정리한 글입니다. 문제/오류가 있을 시 댓글로 알려주시면 감사드리겠습니다
Microservice와 Spring Cloud 소개
| 변화 과정
- 1960 ~ 1980 : 하드웨어 중심, fragile
- 1990 ~ 2000 : 분산 중심
- 2010 ~ : anti-fragile, cloud native/ 탄력적
-> devops라는 문화 발생, 변화에 적응이 빠르고 비용절감 | anti fragile의 특징
- auto scaling : 서버의 댓수 등을 자동으로 조절할 수 있음
- microservice : cloud native의 핵심으로 전체 서비스를 구성하는 모듈을 독립적으로 개발, 배포가 가능
- chaos engineering : 시스템이 불확실한 상황에 대해서도 안정적으로 구축되어야 한다
- Continuous deployments : 서비스의 빌드-테스트-배포를 자동화된 시스템으로 구축하고 연계 과정을 파이프라인으로 만든다
Cloud Native Architecture
| 확장 가능한 아키텍처
- 시스템의 수평적 확장으로 더 많은 사용자 요청 처리 가능
- 확장된 서버로 부하분산, 가용성 보장
- 시스템 또는 서비스 애플리케이션 단위 패키지(컨테이너 기반 패키지)
- 모니터링
| 탄력적 아키텍처
- 분리된 서비스로 개발-통합-배포(CI/CD), 자동화로 시간 단축
- discovery service로 마이크로서비스 관리
| 장애 격리(Fault isolation)
- 장애가 생겨도 전체 서비스를 재배포 해야하는 것이 아니라 특정 서비스만 배포해도 되므로 다른 서비스에 대한 영향 최소화
Cloud Native Application
- Microservice
- CI/CD
- DevOps
- Containers
| CI/CD
- 지속적인 통합, 지속적인 배포
- 지속적 통합 : 형상관리, 통합된 코드 배포 자체를 말할 수 있다
- 지속적 배포
- Continuous Delivery
- Continuous Deployment
- 카나리 배포, 블루그린 배포 등의 배포 방식 사용
| DevOps
- 운영과 개발을 통합해 고객의 요구사항을 빠르게 반영
| Container 가상화
- 하드웨어 가상화/서버 가상화에 비해서 적은 리소스 사용
- 각자 필요한 부분에 대해서만 독립적으로 가상화를 하게 된다
12 Factors + 3
- 클라우드 서비스의 가이드라인
+ API first
+ Telemetry
+ Authentication and authorization Monolithic vs Microservice
| 모놀리스
- 모든 서비스의 내용이 어플리케이션 내에서 서로 의존성을 가지고 개발됨
- 어플리케이션에서 가지고 있는 DB도 하나의 DB에 집중되어있음
- 시스템의 일부만 수정한다 하더라도 전체 어플리케이션을 빌드-테스트-배포를 해야한다
| 마이크로서비스
- 여러 서비스들의 묶음이 전체 서비스
- 서비스는 비즈니스 중심, 완전히 자동화된 배포 방식을 사용해야한다
- 각 서비스는 최소한의 중앙집중식 관리가 되어야하고, 서로 다른 프로그래밍 언어와 다른 데이터베이스를 사용할 수 있다(최적화된 언어, DB 사용 가능)
Microservice
아마존에서의 리소스 사용 방식
1. 모든 데이터는 서비스 인터페이스를 통해 공개되어야한다
2. 팀은 서비스 인터페이스를 통해서만 통신을 해야한다 (계정을 이용한 직접 DB 읽기, 백도어, 공유 데이터 절대 안됨)
3. 다른 방식은 허용되지 않는다
4. 언어, DB, 프로토콜은 중요치 않다
5. 서비스 인터페이스는 처음부터 외부에 공개될 수 있는 것처럼 설계되어야한다.
6. 이것을 지키지 않으면 해고~
7. 좋은 하루 보내세요~| 마이크로서비스의 특징
1. Challenge - 이전과 패러다임을 바꿔야한다
2. Small Well Chosen Deployable Units
3. Bounded Context
4. RESTful- restapi로 통신을 하는 것을 권장한다
5. Configuration Management - 환경설정은 코드로 가지고 있지 않고, 외부에서 전달해줄 것이다
6. Cloud Enabled
7. Dynamic Scale Up And Scale Down - 서비스마다 다른 instance의 갯수를 가질 수 있다
8. CI/CD
9. Visibility - 시각화 관리 도구가 필요 - 마이크로서비스 구현 전에 고려해야 할 것들
1. 기존대비 얼마만큼의 시간이 들 것인가
2. 독립 라이프 사이클?
3. 독립적인 확장 가능?
4. 오류사항이 독립적인가?
5. 외부 종속성과의 상호작용을 최소화할 수 있도록 서비스가 구분되어있는가
6. polyglot 기술을 지원하는가?
- 팀은 딱 피자 두판 나눠먹을 정도의 인원으로 꾸려지는 것이 이상적이라고 한다
MSA VS SOA(Service Oriented Architecture)
둘다 서비스를 지향한다는 점에 대해서는 같다
| SOA
- SOA는 서비스 재사용을 통한 비용 절감에 목적이 있다
- 서비스 버스(ESB)에 모아 서비스를 제공
- SOAP이라는 웹서비스 사용
| MSA
- MSA는 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응하는 것에 목적이 있다
- 각 독립된 서비스가 노출된 REST API를 사용
- kafka를 이용해 DB간의 동기화를 이루어낸다
| REST API 성숙도 모델
- LEVEL0 : 리소스를 웹서비스 상태로써 제공하기 위해 url만 mapping
- LEVEL1 : 의미있고 적절한 url로 표현하지만, 아직 메소드별로 서비스를 구분해서 사용하지는 않는다(get, post, put, delete, errorcode를 적절히 하지 않는다)
- LEVEL2 : Level1 단계에서 http method를 적절히 붙이게 된 것
get : 데이터 읽기
post : 새로운 데이터 추가
put : 기존의 데이터 변경
delete : 기존의 데이터 삭제 - LEVEL3 : Level2 + HATEOS 혹은 DATA + NEXT POSSIBLE ACTIONS
HATEOS : Hypermedia AS The Engine Of Application State
자원에 호출 가능한 API 정보를 자우너의 상태를 반영하여 표현하는 것 | RESTful Web Service
- API 는 개발자 관점에서 개발하는 것이 아니라 소비자 관점에서 개발해야한다
Request methods : get, post, put, delete
Response Status : 200, 404, 400, 201, 401
uri에는 예민한 정보 x
uri에 대해서는 복수의 형태를 권고 : users/1
resource는 명사형태로 표현한다
일괄적인 endpoint를 사용하는 것이 좋다(apigateway를 이용해서 처리)MSA 표준 구성요소
- client 혹은 다른 서비스가 api 요청
- apigateway에 들어오게 됨
- 라우터는 Service discovery에 서비스의 위치(혹은 등록여부)를 물어보게 된다
- 로드밸런서는 서비스의 어떤 instance로 요청을 할 지 결정한다
환경 설정 정보는 config Store과 같은 외부에 저장,
마이크로서비스는 컨테이너 기반 가상화 방식으로 개발되어있을 것 - 배포를 하기 위해서는 CI/CD를 사용할 수 있고, DevOps 엔지니어를 위해 api를 제공하게 된다
- Telemetry를 통한 모니터링
| Service Mesh
- MSA의 내부 통신을 할 수 있게 하는 infra structure layor
- 위 계층에서 기능과 서비스를 제공해주게 된다
| MSA 표준 구성요소
CNCF(Cloud native Computing Foundation)라는 가이드를 사용할 수 있다
Spring Cloud
- Spring boot + Spring Cloud
- 버전에 따라 springcloud 일부 서비스 호환이 안될 수 있다 (버전을 잘 맞춰야 한다)
환경 설정 -> Spring Cloud Config Server
서비스 등록, 위치정보 확인 -> Naming Server(Eureka)
로드밸런싱 -> Ribbon(Client side), Spring Cloud Gateway
데이터 통신 -> FeignClient
시각화, 모니터링 -> Zipkin Distributed Tracing, Netflix API gateway
장애 복구 회복성 패턴 -> Hystrix
나는야 누워있는 개발머신