라는 생각을 평소에 갖고 있었는데 오늘은 해당 방식을 어떻게 나누는지에 대해 알아보겠습니다.
모놀리식 아키텍처란?
먼저 모놀리식 아키텍처입니다.
우리가 구현하는 모든 프로젝트는 초반에 모놀리식 아키텍처를 따르게 됩니다.
그렇다면 계속 모놀리식 방법으로 사용해도 괜찮지 않을까?라는 생각이 떠오릅니다. (저도 그랬습니다.)
하지만! 문제는 다음과 같습니다.
간단한 예시로, 자그마한 프로젝트에서 계속하여 기능들이 추가되었다고 생각해봅시다.
처음에는 리스트만 뿌려지는 홈페이지가 나중에는 댓글, 리뷰, 결제 등 기능들이 추가되면서 점점 할 일이 더욱 증가하게 되었습니다.
이런 경우에 내가 다른 기능들은 건드리지도 않았는데 오류가 발생하는 경우가 있습니다.
모든 기능들이 하나의 프로젝트내에서 다 존재하다 보니 생기는 오류입니다.
장점
- End to-End(하나의 프로젝트에 모든 기능들이 존재하는 것을 의미) 테스트가 용이합니다.
- 빠르게 간단한 서비스를 만들 수 있습니다.
단점
- 조그마한 수정사항이 있어도 전체를 빌드하고 배포해야 함.
- 유지보수가 힘들다.
- 덩치가 커지면 구동시간이 늘어난다.
- 일부분의 오류가 전체에 영향을 줍니다.
- 각 기능에 따라 다른 언어를 선택할 수 없습니다.
MSA 마이크로 서비스 아키텍처 방식이란?
이러한 모놀리식 방법의 단점을 극복하고자 나온 방식이 MSA(마이크로 서비스) 방식입니다.
각각의 기능들을 아예 다른 서비스로 구현하여 따로 배포를 한다는 것이 장점입니다.
MSA 방식의 핵심 키워드는 독립성입니다.
각각의 기능별로 구현을 한다는 것이 원칙이죠.
장점
- 대규모 프로젝트에 용이합니다.
- 유지보수에 용이합니다.
- 거대한 서비스도 빠르게 수정 가능합니다.
- 각 기능에 다라 다른 언어를 선택할 수 있습니다.
단점
- 모니터링이 힘듭니다.
- End-to-end 서비스 구동이 불편합니다(즉, 테스트가 불편합니다.)
그럼 어떻게 활용하면 좋을까?
맨 처음 프로젝트를 구현해야 하는 경우에는 모놀리식으로 가되, ex) 스타트업, 개인 프로젝트 등등..
장기적으로 봤을 때 MAS로 갈아타는 것이 맞다고 생각을 합니다. (추가적인 기능들이 많이 생기는 경우) 대부분의 스타트업들의 경우 MSA 방식이 아닌 경우가 많지만 최근에서야 MSA 방식으로 갈아타고 있습니다. 또한 업무를 배분하기 유용하기 때문에 새로운 개발자가 들어와도 부담이 가지 않습니다.
그럼 MSA 설계는 어떻게 하면 좋을까?
일단 모든 기능들을 나열 후 그루핑을 해줍니다. 예를 들어 주문의 로직이 있다고 생각했을 때 주문과 배달기사의 입장에서 바라봅시다.
주문, 손님, 오너, 배달기사의 입장에서 분기하고, 다시 Bounded Context를 정의해줍니다.
이렇게 되면 하나의 service들의 묶음이 되겠죠? 메뉴에 관련된 service, 주문에 관련된 service, 배송에 관련된 service로 나눠지게 됩니다.
