MSA 마이크로아키텍처 알아보자(1)

먼저 SOA (Service Oriented Architecture)에 대해 알아보자.

쉽게 말해 여러 서비스(비지니스)들을 모듈화해서 각각의 모듈들을 조립해서 사용하는 아키텍쳐이다.

MSA(Micro Servie Architecture) 란 무엇인가?

 

MSA는 SOA의 모듈화 패러다임을 상속을 한 개념이다.
MSA란 하나의 큰 모놀로틱 어플리케이션에서 여러개의 작은 서비스로 분리하고 독립적으로 관리하는 아키텍쳐이다.

 

두개 모두 서비스를 분리한다는 공통점이 있다.

 

두개의 차이점은 무엇일까?

가장큰 차이점은 SOA는 서비스들의 재사용성에 중점, MSA는 서비스들의 독립성을 추구.

예를들어 A팀에서 a서비스를 B팀에서도 사용할수 있다. MSA는 서비스가 공유되기보단 독립적 실행되는것을 지향

디비의 경우도 SOA는 같이 사용하지만, MSA는 서비스마다 DB지향한다.

 

통신방법이 다르다.

SOA의 경우는 SOAP(http(s), smtp 등등), ESB 서비스간 통합적이고 공통적인 방식으로 구성되고 통신하다. 서비스가 결합도가 높다.

MSA는 rest, grpc 처럼 가벼운 프로토콜을 사용해 결합도 없이 독립적인 환경과 통신 가능

---

장점

지속적인 CI/CD가능

서비스가 크기가 작다보니 지속적으로 테스트 할수있음

일부만 쉽게 배포,

• 서비스(조직)간의 결합도가 낮으므로 개발이 빠름
• 서비스가 작아 개발자가 코드를 이해하기 쉬움

서비스를 독립적으로 배포/확장 가능

서비스마다 각각의 스펙으로 서버를 확장하거나 할수있따.

 

결합(장애) 고립

특정 서비스가 장애시 격리되고, 다른 서비스들은 정상 작동

의존성이 있는 서비스는 서킷브레이커 패턴등을 이용하 장애 대응한다.

모놀로식의 경우 전체로 장애 확장됨

 

단점

여러 서비스로 분리 되니 복잡도 증가

rest api통신에 대한 latency 상승

분산 환경에서의 트랜잭션 관리의 어려움

---

서비스의 분리

 

마이크로서비스는 기술적 관심사보단 비지니스 능력, 하위 도메인등의 비지니스 관심사 위주로 분리된다.

 

서비스를 분리하는 방법은 두가지가 있다.

• 도메인 따른 분리
  • DDD의 boundery context을 토대로 기반에 도메인 모델 경계로 구분
• 비지니스 능력에 따른 분리
  • 비지니스에  따라 서비스분리
  • ex) 온라인 쇼핑몰
    • 주문 접수 이행 : 주문후 배송까지 처리 서비스
    • 소비자 관리 : 소비자 컴플레인, 소비자 정보 관리 등을 처리 서비스

---

통신 방법

동기 통신

 

동기 통신 방법에는 무엇이 있을까.

• rest api, gpc

처리 실패 : 서킷브레이크

• 분산 처리 환경에서 다른 서비스의 호출에 블로킹이 되면 현재 서비스에 영향을 주기때문에 연속 실패, 횟수에 대한 임계치를 줘서 즉시 거부하는 패턴이다.
• 실패시에 어떻게 조치할지는 결정이 필요 => 캐시를 이용하도록 하는법도 방법이다.

서비스 디스커버리

• 서비스의 위치 정보를 등록하고 다른 서비스의 위치를 동적으로 전달받아 사용할수 있도록 한다.

비동기 통신

 

이벤트 기반의 통신이다.

• ex) 주문 생성,취소 이벤트

동기 방식은 블로킹때문에 가용성에 영향을 미친다.

 

서비스 간에 결합도를 낮출수 있다.

 

메세지 (pub/sub)방식이 있다.

• 구독하는쪽에서 중복에대한 방어 필요
• 메세지 순서에 대한 지원이 필요할 경우 카프카와 같은 브로커 사용

트랜잭션

분산환경에서는 트랜잭션이 어렵다. 모놀리틱에서는 DB 트랜잭션이 단순하지만, 각각의 서비스가 분리된 상황에서는 관리가 어렵다.

메세지 기반의 통신에서는 실패에 대한 이벤트를 전달해야되고, 실패에 대한 구독과 롤백시나리오를 구성해야한다.

격리수준을 높이기 위해 여러가지 방식이 있다.

 

ex) 주문을 결제 승인을 진행하기 전에, 주문 취소요청이 들어와 결제 승인을 취소하는 요청이 발생될수 있다

• 주문 요청 트랜잭션이 진행되는 도중에는 취소 트랜잭션이 불가능하도록 해야한다

ex) 

 

 

• 시맨티락
  • 어플리케이션단에서의 락
  • 플래그를 셋팅
  • 현재 요청이 진행중인 상태를 저장해두고, 취소 이벤트를 전달 받을시 진행중인 플래그를 보고 대기하거나 거부한다
• 다시 읽기
  • 특정 액션을 실행하기전에, 실행 가능한지 API같은것들은 통해 다시 읽는다.
  • 위의 케이스에 취소가 가능한 상태인지 확인해볼수있다.
• 버전 파일
  
  • 레코드의 수행한 작업을 하나하나 기록하여 순서가 맞는지 확인
  • 순서가 맞지 않을경우 기록해두고 추후에 정확한 순서로 실행한다.