monorepo를 적용하며

Sellernote 구조

 현재 지금 우리 구조는 왼쪽의 구조와 같았다. Ship-da API, Admin API, 이메일&문자&잔디 알람 발송, 크론잡 코드들이 Monolith하게 구성되어있었음 그리고 여기서 이제 신규 WMS서비스에 대한 repository가 추가되고 이메일, 문자 발송에 대한 기능과 거래명세서, 견적서 생성 기능을 별도 서버를 분리하자는 움직임이 있었다. (이 기능은 신규 WMS에서도 사용을 해야하니깐) 그리고 이에 따라 MSA스러운 성격을 띄게 되었는데 MSA 구조를 도입하진 않을 예정이지만 이러한 구조를 더 편히 관리하기 위하여 모노레포를 도입하기로 하였다. 

 

이 전에 기존 모노리스 (Monolith), 멀티레포 (Multirepo), 모노리포(Monorepo)의 특징과 성격을 정리하고자 한다.

 

 

모노리스 (Monolith)

> 기존 전통적인 구조로 하나의 어플리케이션 내에 여러 역할들을 하는 코드들이 전부 들어간 대규모 구조를 의미한다. 

 

• 한계점 
  1. 대형 시스템 개발시 문제가 발생한다.
      > 빌드, 배포 시간도 오래걸리게 되고 모든 기능이 들어간 만큼 특정 서비스의 개편이 있어 수정하다가 에러가 나면 다른 서비스들까지 영향을 준다.
      > 개발자가 전체 시스템 구조를 파악하고 개발을 하기가 어려워지고 특정 컴포넌트가 성능 장애 이슈가 발생할 수 있음
  2. 생산성이 추후 떨어질 수 밖에 없다.
      > 모노리스 구조를 사용하면 서비스 간에 공통으로 사용하는 함수가 생기게 되는데 이렇게 여러 목적의 서비스가 한 곳에 모이면 추후 서비스의 복잡도가 올라가면 생산성은 떨어질 수 밖에 없고 레거시하게 된다. 
      Ex) 특정 의뢰에 대해 조회를 하는 함수가 있고 이를 공통으로 사용 중에 있었는데 특정 서비스에서는 A, B table의 정보를 Join해서 같이 가져와야해서 Join 쿼리를 적용한다면, 다른 서비스에서는 join해서 가져올 필요가 없는데 불필요하게 복잡해진 쿼리를 사용하여 데이터를 조회하게 된다.
• 모노리스가 잘못된 건 아니다. 복잡성이 낮고 서비스 초기, 기획이 손바닥 뒤집 듯 자주 바뀌는 상황이라면 모노리스로 빠르게 대응하고 리팩토링하는게 정답

출처 : https://martinfowler.com/bliki/MicroservicePremium.html

 

멀티레포 (Multirepo)

> 일반적으로 각 프로젝트에 대해 하나의 repository로 구성하는 것을 말한다. 

• 한계점 
  1. version 통일이 어렵다.
      > 각 repository별 node, 프론트라면 react같은 것들의 버전을 통일하기가 어렵다. 
      > 버전이 전부 달라지면 읽어야할 wiki 문서들도 자연스래 많아진다. 
  2. 다른 repository의 개발 히스토리나 어떻게 돌아가고 있는지 전혀 알 수가 없어진다.
      >  모노레포라고 해서 완전 밀접하게 알게 되는건 아니지만 멀티레포는 진짜 아예 모른다. 내가 WMS가 지금 어떻게 돌아가고 있는지 모르는 것 처럼
  3. 배포관리하기가 어려워진다. 
      > 예를 들어 Common-interface로 따로 또 공용으로 쓰는 interface를 정리해놓은 repository가 있는데 이렇게 multirepo로 하면 반드시 common-interface를 먼저 배포하고 shipda를 배포해야한다. 
      > 위의 예시는 2개지만 만약 서비스가 더 복잡해지고 이 안에서 반드시 지켜야할 순서가 생긴다면 멀티레포로 하면 꼭 한번쯤은 휴먼에러가 날 수 밖에 없다.
• 그래도 멀티 레포로 하면 각 서비스가 서로 영향을 주지않고 각 레포지토리의 크기들이 작아 배포가 빠르고 용이하다.

 

모노레포 (Monorepo)

> 하나의 repository안에 여러 프로젝트를 구성하고 있는 구조를 말한다. 

> 위의 내용에서 계속 다룬 것처럼 서비스가 많아지고 각각의 서비스가 고도화되게 되면 코드의 복잡도는 2차함수를 그리면서 더 증가할 수 밖에 없음. 이러한 복잡성을 줄이기 위해 패키지 버전 관리, 빌드, 배포, 개발 일관성 유지 등을 통일시켜버리는 것

• 장점 (요약하면 멀티레포와 모노리스의 장점들을 섞어놨다.)
  1. 통합된 버전 관리와 코드 공유 및 재사용이 가능해진다. 
  2. 개발자간 협업이 쉬워진다. (같은 repository사용하니깐)
  3. 브레이킹 체인지 전파 
      > 멀티리포의 경우 repository 별로 소스를 관리하기 때문에 브레이킹 체인지가 일어 났을 경우 의존하는 모듈에 자동으로 전파가 되지 않는다. 허나 모노리포의 경우 하나의 repo에서 작업을 하기 때문에 브레이킹 체인지가 발생했을 경우 즉시 에러로 검출이 가능하다.
  4. 의존성 관리를 한 곳에서 전부 할 수 있기 때문에 용이하다.
• 단점 
  1. 버전 관리가 상당히 힘들어진다.
      > 여러 프로젝트의 개발자들이 동시에 하나의 master, develop branch를 향해 개발하고 있으니 그럴 수 밖에 없다. 
  2. repository 크기가 크기 때문에 repo기반으로 동작하는 도구들의 속도가 느려짐 
      > 우리는 해당이 안 될 듯하다. 배포도 그 안에 서비스별로 하도록 쪼개져있다.