MSA의 장점, 단점. 동작 방식, 버저닝 전략

MSA 통신 할때 보안 처리 방법

EKS 같은 쿠버네티스를 사용 할 때는 Istio 같은 솔루션이 도움이 된다.

주소를 외부에 노출하지 않고 pod끼리 http://order-api:3000 이런 식으로 통신 할 수 있다.

 

 

MSA구조의 장점, 단점. 모놀리틱과 비교해서

msa 장점

msa 단점

기술 이기종성 - 분리된 서비스로 개발할 수 있기 때문에 서비스마다 가장 적합한 기술을 선택 할 수있다. 배포 용이성 - 모놀리틱의 거대한 프로젝트를 빌드하는 것보다 마이크로 서비스 1개를 배포하는것이 훨씬 쉽고 빠르다. 확장성 - 새로운 개발항목이 추가되었을때 모놀리틱은 전체 코드에 영향이 있는지를 살피고 개발, 테스트 해야한다. 마이크로 서비스는 코드베이스가 작다. 그리고 새로운 서비스를 독립적으로 만들면 된다. 확장성 - 마이크로 서비스는 각 서비스마다 트래픽이 많은 것은 늘리고 적은 것은 줄일 수 있다. 회복성 - 모놀리틱은 장애가 생겼을때 전체 시스템이 다운된다. 마이크로 서비스는 장애 전파도 막을 수 있고 전체 서비스가 다운되지 않는다. 대체 가능성 - 코드 베이스가 작기때문에 레거시가 되었을때 재개발하기도 쉽다.

트랜잭션 처리가 어려워진다. 각각의 msa 에서 일어나는 일들을 커밋하고 롤백하는 일이 어려워진다. 버그를 찾기가 어려워진다. 문제 발생시 어느 서비스에서 문제가 생겼는지 찾아야한다.

msa 에서의 공용 모듈

공용 모듈을 사용한다면 코드 재사용성이 높아진다.

하지만 진정한 기술 이기종성을 가질 수는 없다.

 

좋은 msa 가 갖춰야 할 항목

1. 느슨한 결합

하나의 서비스가 변경 될 때 다른 서비스가 변경되지 않아도 된다. 

다른 서비스와 독립적으로 배포 될 수 있다.

 

2. 강한 응집력

서로 연관된 행위를 한 곳에 모은다.

다른 경계와 느슨하게 소통할 수 있도록 한다.

 

MSA 통신 방법

- SOAP 

- XML RPC

- REST 

- 프로토콜 버퍼

 

MSA의 통합

- 호환성을 깨트리는 변경 피하기

  - 데이터에 새로운 필드가 추가되었어도 기존 소비자 서비스에는 영향을 미치지 말아야한다.

- 기술 중립적인 api

  - 지금 node로 개발한다고 해서 10년뒤에도 node 로 개발할지는 모른다.

  - 다른 새로운 기술이 나왔을때 쉽게 도입 할 수 있도록 특정 기술에 종속되지 않아야한다.

 

MSA 로직 모델링 방식

오케스트레이션 방식	코레오그래피 방식
중앙에서 프로세스를 호출하는 방식이다. 동기 방식의 요청/응답을 사용하면 각 단계별 수행 상태를 알 수 있다.	비동기 방식이다. 이벤트를 구독하고 동작한다.

오케스트레이션 방식

코레오그래피 방식

이 방식을 활용하면 고객 서비스에서는 동기적으로 각 서비스의 응답을 기다릴 필요가 없다.

이벤트 큐로 메세지를 보내면 그 다음은 구독하고 있는 서비스들이 알아서 일을 한다.

이 방식은 느슨한 결합을 유도해서 좋다.

하지만 모니터링과 추적이 필요하다.

모니터링 시스템을 구축해야한다.

 

MSA 에서 공통 모듈, 코드 재사용의 위험

만약 공통 모듈을 사용하고 모듈에 대한 의존도가 높다면 업데이트시 위험하다.

로깅 같은 모듈은 같이 써도 된다.

비즈니스 로직과 관련된 것은 잘못 쓰면 강한 결합을 가져온다.

 

MSA 버전 관리 

- 가능하면 지연하기

- 필드가 필요 없다고 해서 쉽게 제거하면 불필요한 장애를 만들 수 있다.

- 구독하는 쪽에서 관심없는 데이터의 변경을 무시할 수 있도록 구현한다. - 관대한 독자 패턴

- 견고성의 원칙 (포스텔의 법칙) - 보낼때는 엄격하게. 받을때는 관대하게

    - 무언가 데이터를 보낼때는 엄격하고 정확한 데이터를 보낸다.

    - 받는쪽을 구현할때는 상상가능한 최악의 형태가 올 수 있다고 생각하고 구현한다.

 

호환성을 깨트리는 변경 일찍 찾아내기

서비스 주도 계약 - CDC ( Consumer Driven Contract )

 

유의적 버전관리

 - 버전 관리는 Major . Minor . Patch 형태로 진행된다.

    - 하위 호환성이 깨지는 업데이트는 Major 업데이트

    - Minor 업데이트는 하위호환성을 유지하면서 새로운 기능 추가

    - patch는 버그 수정

 

엔드포인트를 공존하게 하면서 버전관리를 할 수 있다.

서버 측 코드에서 v1으로 들어오는 요청을 v2 쪽 코드로 처리 하게 할 수도 있다.

즉

- 구버전 api 를 유지한채 v2를 배포하고

- v1 트래픽을 v2로 보내고

- v2만 남긴다.