[TIL] MicroServices Architecture(MSA) vs Monolithic Architecture

 

기본 개념

Monolithic Architecture: 한 프로젝트 안에 모든 것이 다 들어 있는 형식

MicroServices Architecture(MSA): 여러 프로젝트를 만든 뒤, 프로젝트들을 연결하여 사용

ex) 모놀리식은 네이버 웹 서비스 전체를 하나의 프로젝트를 만든 것이라 하면, MSA는 메일 프로젝트, 카페 프로젝트, 블로그 프로젝트 등등 으로 나누어 이를 연결한 형태

 

왜 MSA를 사용할까?...  MSA의 장단점??

반대로 네이버같은 유저 트래픽과 기능이 크고 많은 서비스를 모놀리식으로 구현했다고 가정할 때,

네이버 메일 기능을 업데이트하기 위해 서버를 내렸다가 다시 올렸는데 버그가 발생해서 몇시간 동안 서버가 먹통이 된다 라는 시나리오가 가능하다. 반면 MSA 구조라면 메일 기능은 마비될지언정 다른 서비스들은 멀쩡할 것이다 왜냐? 애초에 다른 프로젝트로 돌아가기 때문이다. 즉 서비스 격리를 통해 서비스의 안정성을 확보할 수 있고 문제 발생시 해결도 빠르게 할 수 있다.

 

이외로 MSA의 장점으로는 프로젝트 별로 독립성이 있다는 점이다. 이러한 독립성 덕분에 개발자들이 자율성이 높아지고 파트별 개발 속도의 차이로 생기는 병목현상이 줄어든다.

프로젝트의 크기가 줄어드니 각 팀의 코드 이해도가 높아지고 팀의 프로젝트 내부에서는 유지보수의 난이도가 낮아진다.

프로젝트의 성격에 맞는 신기술이나 구조를 도입하기 쉽다

 

이러한 장점들이 있으면 너무나 당연하게 단점도 있다

MSA 구조는 많은 프로젝트들간의 연합으로 서비스가 돌아가기에 각 프로젝트간의 통신이 필요하다.

그렇기에 만약 유지보수하고자 하는 프로세스가 한 팀의 프로젝트에서 끝나는 것이 아닌 여러 프로젝트를 거처셔 수행된다면, 유지보수의 난이도가 오히려 증가한다. 팀에서 해결하지 못하고 다른 팀에게 물어보고 다녀야 하기 때문이다. 도메인을 제대로 이해하지 못하여 서비스의 경계를 잘못 설정한다면 이러한 일이 더욱더 늘어날 것이다. (프로세스가 잘 분리되지 못하고 복수의 프로젝트를 거치는 일이 많아질 것) 

또한 각 프로젝트들간의 통신이 원활해야 서비스가 정상 작동하기 때문에 API 관리에 신경써야한다.

프로젝트가 많아질수록 한번 업데이트하기 위해서 손이 많이 가게 된다. 

 

+ 메시징 시스템(Feat. Kafka)

MSA 아키텍처를 사용하는 경우 앞서 말한대로 많은 프로젝트들간의 호출이 많아지기에 메시징 시스템을 많이 사용하게 된다.

MSA 구조로 나누어진 프로젝트들이 중앙의 메세징 시스템에 메시지를 전송하면

메세징 시스템이 올바른 목적지에 메시지를 전달해주고, 메시지를 받은 프로젝트가 이를 처리하는 방식으로 동작한다.

(최근에 디자인 패턴에서 배운 옵저버 패턴에 해당하는 구조인 것 같다) 

 

메시징 시스템 사용함으로서 얻을 수 있는 장단점은

• 장점
  • 서비스간의 결합도를 낮춰 비즈니스 로직에만 집중할 수 있음
  • 메시지 처리 방식은 Message Broker가 담당하고 각 서비스는 메시지만 보내면 됨
  • 각 서비스가 비동기 방식으로 메시지를 보내기만 하면, Message Broker가 순서 보장과 전송을 보장함
• 단점
  • Message Broker 운영을 위한 자원 소모
  • 전체 시스템 복잡해짐
  • 호출 구간 늘어나 신뢰성 떨어짐, 네트워크 비용 추가 발생