November 17, 2022

MSA 관련해서 전체적인 정리

어제 클라우드 네이티브 아키텍처라는 용어를 찾아보면서 많은 내용들이 있었다.

지금까지 했었던 프로젝트에서 나왔던 용어들을 기억하면서 복잡한 내용을 정리해봤다.

예전에 IT 트렌드는 통합,재사용으로 서 모듈이 서로 강하게 결합된 하나의 거대 시스템인 모놀리스 서비스 또는 애플리케이션이었다.

이렇게 강한 결합으로 이루어져있다보니 운영시 오류나 버그가 발생했을때 결합되어있는 모든 것을 확인해봐야하므로 수많은 시간과 비용(높은 유지보수 비용)이 들게 되었다.

이러한 문제점들로 인해 강한 결합을 느슨하게 풀기 시작했고, 서비스들이 분리되기 시작했다.

즉, 기존 하나의 큰 단위로 개발/운영되던 애플리케이션을 수십, 수백, 수천개의 작은 서비스 단위로 분리되어 애플리케이션을 개발/운영하는 방식을 MSA라고 한다.

이렇게 이기종으로 개발된 애플리케이션 간에 데이터 통신을 위해서 표준화된 HTTP 프로토콜을 사용하는 RESTful API를 널리 사용한다.

또한, 각 서비스들은 결합이 느슨하고 유연해서 서로 다른 언어, DB를 사용할 수 있다.(폴리글랏 : 특정 서비스를 구축하는데 사용하는 언어나 저장소를 자율적으로 선택할 수 있는 방식)

클라이언트 ------- api ------ 서비스(java) ------ DB(Oracle)

         ------- api ------ 서비스(Node.js) --- DB(Mysql)

         ------- api ------ 서비스(C#) -------- DB(MariaDB)

                RESTful

사용자(클라이언트)들이 수많은 서비스들과 통신을 하게 되는데 분리된 서비스들은 필요에 따라 서로 통신하며 데이터를 주고받고 의존성을 갖게 된다.

이러한 사용자들중에 인증 및 인가를 받은 사용자들만 서비스들을 이용할 수 있도록 하기 위해서 인증/인가 기능을 추가한다.

하지만 서비스들이 나눠져있어서 공통된 기능을 해당 서비스에 각각 추가하는 것은 엄청난 낭비이다.

그래서 인증/인가를 해주는 공통된 작업과 API를 관리(APIM)하게 되는데 그것을 API Gateway이다. (만약 인증실패가 되면 Forbidden 에러 발생)

클라이언트 --- API Gateway(인증/인가)------ 서비스(java) ------ DB(Oracle)

                                 ------ 서비스(Node.js) --- DB(Mysql)

                                 -------- 서비스(C#) ------- DB(MariaDB) 

                RESTful

또한 서비스들이 쪼개짐으로 수많은 커밋과 테스트, 배포가 빈번하게 발생하는데 사람이 작업을 한다면 휴먼에러가 발생할 수 밖에 없다.

따라서 지속적인 통합과 지속적인 배포를 자동화하게 된다.(CI/CD : 코드 통합에서부터 빌드,테스트,배포에 이르는 모든 과정)

메세지 큐 방식을 사용하는 이유(비동기 통신 방식)

REST API      요청                             요청
모바일UI ---- GET/order ----->  주문 ------GET/Customer/01 -------> 고객

         <------200 OK -------      <----------200 OK ------------
               응답                             응답

여러 서비스 간의 연계를 통해 업무를 처리하는 마이크로서비스 구조에서는 장애가 있으면 연쇄적으로 장애가 발생할 수 있다.

위와 같은 동기처리 방식으로는 마이크로서비스별로 비즈니스 기능 처리를 어렵게 한다.

이러한 이유로 비동기 통신 방식을 사용하는데

메시지를 보낸 후(request) 다음 응답(response)을 기다리지 않고 다음 일을 처리하게 된다.

동기 방식처럼 응답을 기다리지 않는다. ---> 결과를 모르니 동기식처럼 완결성을 보장 받진 않는다.

따라서 완결성을 보장 받기 위해서 아파치 카프카, RabbitMQ 등과 같은 메세지 큐 시스템을 활용한다.

클라이언트/게이트웨이 ----- API -----> 서비스1 --- PUB ---> 메세지 큐 ---- SUB ----> 서비스2

                                                                ---- SUB ----> 서비스3

                                                                ---- SUB ----> 서비스4

서로 통신하는 서비스들이 물리적으로 동일한 시스템에 없어도 되고 프로세스를 공유하지 않아도 된다.

즉, 분산 시스템 간에 발신자가 이벤트를 생성/발행(PUB)하고 해당 이벤트를 필요로 하는 수신자가 구독(SUB)을 하면 이벤트를 받아서 처리한다.