MSA : 마이크로 소프트 아키텍처의 약자
모놀리식 아키텍처는 대부분의 프로젝트가 행하고 있는 모습이다.
즉 하나의 서버의 모든 서비스가 들어가있는 마치 일체형 프로그램 이라고 생각하면 편하다.
반대로, MSA는 여러개의 서버로 분리한뒤, 서비스를 여러개로 분산할수있다.
예시를 들어보자면,
유저 서비스 , 매칭 서비스 , 전투 서비스 , 뽑기 서비스, ..등등 기능 별로 나누거나
카카오톡을 예로들면, 카카오 헬스, 카카오 지갑, 카카오 뱅크 , 카카오 맵 등등 예를 들 수 있다.
즉 서비스마다 서버를 하나씩 두어 독립적으로 관리하는 개념이다.
MSA의 장점 :
1. 독립적으로 서비스를 관리할수 있기에, 코드 유지보수가 매우 좋다.
오류가 있다면 모놀리식처럼 집약된것보다 코드나,패키지를 찾기 편하며,
기능 확장도 매우 편하다.
모놀리식 같은경우 기능을 확장하려면 전체서비스를 모두 껏다 켜야하지만,
MSA는 특정 기능만 껏다키면 나머지 90프로의 서비스는 가동중으로 둘 수 있다.
2. 복제의 비용이 현저히 줄어든다.
예를들자면 유저 서비스 또는 이벤트 서비스가 매우 높은 트래픽이 검증이된다면,
모놀리식일경우는 "유저 서비스" 하나때문에 다른 90% 서비스를 필요도없는데 복제를 해야한다.
-> 즉 복제를 할 필요가 없는 서비스의 코스트가 더 들어버린다.
MSA인경우는 이런 문제를 해결할수있다. 간단하게 "유저 서비스"를 복제만 시키면 된다.
남은 서비스는 1개의 복제만 가지지만 유저서비스만 3~4개의 복제본을 가질수 있도록 할수있다.
단점:
그렇다고 MSA가 무조건 좋지 못하다.
앞서 설명한 장점들은 매우 매력적으로 들리지만, 대부분의 기업들은 시도를 하지 않으려한다.
오죽하면 MSA는 "더 나은 서비스를 위한 선택" 이 아닌, "성능과 트래픽 때문에 어쩔수 없는 선택" 이 나왔겠는가?
1. 복잡성이 어마어마하게 올라간다.
프로젝트가 커질수록 기능별로 분리하다보면, 10개는 기본적으로 넘어가는 수가 발생한다.
10개의 서비스끼리 독립적으로 돌아가면서 서로 통신을 해야한다.
서비스끼리의 통신을 Kafka 또는 OpenFeign으로 잡아줘야하는데, 이 수작업과 복잡성 난이도는
모놀리식과는 궤를 달리한다.
2. 테스트가 힘들다.
모놀리식 같은경우는 테스트코드를 짜기 쉽다.
모든 서비스, 기능이 하나의 백엔드 서버 내부에 존재하기에 서버 하나만 켜도 테스트가 된다.
하지만 MSA는 테스트를 하려면 매우힘들다.
주문서비스를 예시로 들자면,
주문 하나를 행하려면 유저서비스가 켜져야하고,
주문이완료되면 배달서비스로 요청을 보내야한다.
당장 시나리오만 봐도 3개의 서버가 켜져야 테스트를 할 수 있다.
3. 통합작업도 꽤 번거롭다.
모놀리식의 경우는 협업자마다 브랜치를 나눈뒤,
git merge 와 , git pull 로 간단하게 병합 및 업데이트를 할 수 있다.
하지만, MSA는 서비스마다 하나의 Repository를 가지기 때문에 업데이트가있으면
배포상태가 아니라면 , 본인 로컬 에다 서비스 마다 git pull를 다 쳐야한다.