# 모놀리식 vs 분산형
현재 아키텍처 스타일은 크게 모놀리식과 분산형, 두 가지로 나눌수 있음. 둘 중에 뭐가 더 좋은지는 상황에 따라 다르다
# 모놀리식
- 레이어드 아키텍처
- 파이프라인 아키텍처
- 마이크로커널 아키텍처
# 분산형
- 서비스 기반 아키텍처
- 이벤트 기반 아키텍처
- 공간 기반 아키텍처
- 서비스 지향 이키텍처
- 마이크로서비스 아키텍처
분산 아키텍처 스타일은 모놀리식에 비해 성능, 확장성, 가용성 측면에서 강력함
하지만 결코 무시 할 수 없는 트레이드 오프가 수반됨
현재 분산 이키텍처 스타일에도 8개의 오류가 적용됨
# 오류#1 : 네트워크는 믿을 수 없다
- 네트워크 신뢰도는 점점 좋아지고 있긴 하나 아직도 미덥지 못한게 사실
- 분산 아키텍처는 특성상 서비스를 오가는, 서비스 간에 이동하는 네트워크에 의존하므로 중요한 문제임
- 네트워크 문제로 인해 응답을 못 받는 경우가 생김
- 타임아웃 장치나 서비스 사이에 회로차단기(서킷 브레이커)를 둠
# 오류#2 : 레이턴시는 0이 아니다
레시턴시란? 하나의 데이터 패킷이 출발지에서 도착지까지 가는 데 걸리는 시간
- 메소드나 함수를 이용해 호출하면 소요시간은 대개 나노 초 ~ 밀리초 단위임
- 동일한 호출을 REST, 메시징, RPC 등으로 호출하면 서비스 액세스 시간이 느림
- t_remote는 항상 t_local보다 클 수밖에 없고 모든 분산 아키텍처에서 레시턴시는 0이 아님
- 분산 아키텍처를 구축하려면 평균 레시턴시는 반드시 알아야함
- 그래야 분산 아키텍처가 실현 가능한지 판단하는 유일한 방법임
# 오류#3 : 대역폭은 유한하다
- MSA 이케텍처에서 시스템이 자잘한 배포 단위(서비스)로 쪼개지면 서비스들 간에 주고받는 통신이 대역폭을 점유하여 네트워크가 느려짐
- 네트워크가 느려짐에 따라 레시던시(오류2)와 신뢰도(오류1)에도 영향을 미침
# 예시)
- 서비스A는 위시 리스트 아이템을 서비스B는 고객 프로필을 관리하는 서비스
- 서비스 A는 위시 리스트를 요청 받으면 서비스 B를 호출해서 고객 이름을 가져옴 2-1. 서비스 A는 고객 정보가 없기에 서비스 B를 호출함
위와 같은 형태의 커플링을 스탬프 커플링이라고 함. 이렇게만 보면 별거 아니겠지만, 위시리스트 요청이 초당 2000번 정도 발생한다면? 엄청난 대역폭이 발생함
스탬프 커플링은 아래와 같은 방법으로 해결 가능함
계약이란 ? MSA에서 서로 다른 서비스 간의 인터페이스를 정의하는 문서 혹은 코드로 서비스 간의 통신방식, 데이터 형식, 요청 및 응답을 정의함 마이크로 서비스 계약에는 다음과 같은 두 가지 주요 유형이 있습니다.
기술 계약: 기술 계약은 마이크로 서비스 간의 통신 방식을 정의합니다. 예를 들어, HTTP, RESTful API, gRPC 등을 사용할 수 있습니다.
비즈니스 계약: 비즈니스 계약은 마이크로 서비스 간의 데이터 형식, 요청 및 응답을 정의합니다. 예를 들어, 특정 데이터 형식을 사용하거나, 특정 HTTP 상태 코드를 반환하는 등의 규칙을 정의할 수 있습니다.
마이크로 서비스 계약을 작성할 때 다음과 같은 사항을 고려해야 합니다.
명확성: 계약은 명확하고 이해하기 쉬워야 합니다. 완결성: 계약은 모든 필요한 정보를 포함해야 합니다. 일관성: 계약은 모든 마이크로 서비스에서 일관되게 구현되어야 합니다. 마이크로 서비스 계약을 구현하는 방법에는 여러 가지가 있습니다. 다음은 몇 가지 >일반적인 방법입니다.
API 스펙: API 스펙은 기술 계약을 정의하는 데 사용되는 일반적인 방법입니다. 프로토콜 버퍼: 프로토콜 버퍼는 비즈니스 계약을 정의하는 데 사용되는 인기 있는 >방법입니다. 코드: 코드는 계약을 구현하는 가장 구체적인 방법입니다. 마이크로 서비스 계약을 사용하면 마이크로 서비스 아키텍처를 성공적으로 구현하고 관리할 수 있습니다.
- 프라이빗 REST API 엔드 포인트를 둔다. 1.1 모든 MSA는 프라이빗 엔드포인트를 사용하여 다른 서비스에 접근 할 수 있다 1.2 이 엔드 포인트는 특정 데이터에만 섹세스 할 수 있도록 제한됨 1.3 단점 : 서비스 간의 통신이 복잡할 수 있음
- 계약에 필드 셀렉터를 사용한다. 2.1 계약에 필드 셀렉터를 사용하며 서비스가 액세스 할 수 있는 데이터를 제한 할 수 있음 2.2 필드 셀렉터는 요청, 응답에서 반환할 데이터를 지정하는데 사용하는 규칙 2.3 단점 : 서비스 간의 통신이 복잡할 수 있음
- GraphQL로 계약을 분리한다. 3.1 이를 사용하면 필요한 데이터만 요청 할 수 있음 3.2 장점 : 서비스 간의 통신이 단순화됨 3.3 단점 : 구현이 어려움
- 컨슈머 주도 계약(CDC)와 값 주도 계약(VBC)를 병용한다. 4.1 CDC : 컨슈머가 필요한 데이터만 제공하는 계약 4.2 VBC : 값을 제공하는 계약 4.3 이 두개를 병용하면 서비스 간의 의존성을 줄일 수 있음 4.4 장점 : 서비스 간의 통신이 단순화됨 4.5 단점 : 구현이 어려움
- 내부 메시징 엔트포인트를 사용한다 5.1 메시징을 사용하면 통신이 가능하고 서비스들간의 의존성을 제거 할 수 있음 5.2 장점: 마이크로 서비스 간의 의존성을 제거합니다. 5.3 단점: 구현하기 어려울 수 있습니다.