msa란? msa 고도화

msa 개념

• MicroService Architecture(MSA)는 loosely coupled를 기반으로 여러 개의 작은 서비스로 구성되어 각 서비스가 독립적으로 개발되고 빠른 배포주기, 폴리그랏 프로그래밍, 관심사의 집중 등의 장점을 발휘해 Enterprise IT에서 가장 주목받고 있는 아키텍처이다.
• 폴리그랏 프로그래밍 : 단일 언어로 제공되지 않는 추가 기능과 효율성을 극대화 하기 위해 여러 언어로 코드를 작성하는 것

msa 장점

• MSA를 도입하여 느슨한 결합, 관심사의 집중, 단일 책임 원칙, 빠른 배포주기, 폴리그랏, Scalability, 장애의 격리, 유연성, 확장성 등 여러 이점

msa 단점

• Shared 관계형 데이터베이스 장점 사용 불가
  • 데이터를 효율적으로 보관하고 조회/삭제 등 기능의 효율을 높이는 장점
  • 테이블 조인을 통한 통합 뷰 제공
  • ACID 원칙에 따른 트랜잭션 기능
• 서비스가 뭉쳐져 있을 때 발휘되던 장점을 활용하지 못함

현재 서비스의 단점

이 글을 쓰는 이유이자 공유의 목적이다.
현재 서비스가 msa 구조로 나뉘어 질 때 같이 개발하지 않았지만, 인수인계도 없이 현재 서비스를 맡았을 때 이해가지 않거나, 아쉽게 구현된 msa환경의 불편함을 공유하여 같은 실수를 겪지 않았으면 한다.

1. 무분별한 서비스 분리
   • Monolithic한 구조에서 MSA로 가기위해선 서비스를 어떻게 분리할 것인지 기준이 있어야한다.
   • 대표적으로 비즈니스 구조를 기반으로 분리, 도메인간의 결합도, 응집도에 따라 분리
   • 비즈니스 구조를 기반으로 분리한다면 현재 대상 서비스가 세금계산서 하나여서 분리하기 어려움
   • 도메인간 결함도,응집도에 따라 분리해야 하는데, 이게 분리돼야하는 서비스인가?하는 부분까지 별도의 api로 분리돼있음 예를들어 유니크한 문서번호만을 생성하는 api가 있다. 왜 32자리의 대,소문자+숫자 조합의 유니크한 값을 별도의 서비스가 생성해야하는거지?
   • 문서 번호생성은 결국 문서생성 api와 결합도가 생길 것이고 이러한 작은 기능까지 별도의 서비스로 분리하여 관리 할 api가 많아지면 개발복잡도 증가는 물론, 패킷유실, 트랜잭션처리 등 msa의 단점만 커지는것 같다.
2. Database Per Service가 지켜지지 않음
   msa의 목적은 결국 응집력은 높이고 결합도를 낮춰 서비스를 독립적으로 개발,배포 및 확장시키고 서비스간 유기적인 통신을 하는것이다. 하지만 현재 구조는 Database하나를 여러 서비스가 참조하고, 하나의 서비스가 여러 데이터베이를 참조하는 강결합을 보여주고있다.
   서비스가 나눠져있으니 상관없는게 아니냐?라고 생각할 수 있지만 이런 형태는 우선 트랜잭션 처리를 어렵게한다. 트랜잭션은 결국 데이터베이스에서 관장하는데 하나의 요청에 서로 다른 데이터베이스가 변경돼야하면 트랜잭션처리는 할수 없다.(보상 트랜잭션이 있지만... 결국 서비스단에서의 추가 요청이고, 보상트랜잭션이 실패한다면..?)
   또한 데이터베이스의 컬럼추가나 서비스의 변경으로 데이터베이스가 변경되면 관련 서비스들도 전부 개발 및 배포가 이루어 져야한다. 관리 repo가 많아지면 결국 이 DB가 어느 api를 보고있는지, 어디를 고쳐야하는지 찾기힘들어지고 버그 포인트만 늘어나게된다. 이는 결국 비싸고 유실많은 TCP통신을 하며, 코드 검색 및 관리하기도 힘든 api들로 이루어진 초 거대 Monolithic 구조로 개발하는것이다.

MSA 단점 보완(Event Driven MicroService 란?)

위처럼 msa의 단점이 극대화 된 경우 이를 보완하는 다양한 방법으로 EDM을 추천하곤한다.
EDM이란? MSA가 적용된 시스템에서 이벤트 발생시 해당 이벤트 로그를 보관하고 이를 기반으로 동작하며, 비동기 통신을 통해 시스템 내 통합(integration)을 수행하는 Architecture이다.

EDM의 특징

• 이벤트 : 상태의 변경. 즉, 데이터의 변경,생성,삭제(CUD)를 통해 발생하는 서비스의 의미있는 변화
• 비동기 통신 : amqp, mqtt, jms 등 메세징 프로토콜을 통한 메세지 큐 방식이 자주 사용, 서비스에서 데이터의 생성,변경,삭제(CUD)를 통해 이벤트가 발생하면 발행 서비스는 메세지의 형태로 이벤트를 발행하고, 해당 이벤트에 관심이 있는 서비스에서 구독을 수행
• 시스템 내 통합(integration) : Database Per Service를 적용하면 Shared Database 구성의 DBMS 레벨에서 제공하던 기능을 Application 레벨에서 해결해준다.

EDM의 효과

• 비즈니스 흐름에 따른 로직 수행
• 분산 트랜잭션 처리
• 서비스 간 반정규화 데이터 동기 처리
• 적절한 시스템 내 통합
• 최종적인 일관성
• 동기 통신비용의 절감

참고 : https://medium.com/dtevangelist/event-driven-microservice-%EB%9E%80-54b4eaf7cc4a