[SW 개발] MSA vs 모놀리식

Monolithic Architecture (모놀리식 아키텍쳐)

👉 장점

• 서비스의 개발 환경이 동일해 복잡하지 않다.
• End-to-End 테스트와 개발 및 관리가 용이

 

👉 단점 

• 프로젝트의 규모가 커지면 작은 부분을 수정하더라도 전체를 다시 빌드 & 배포 해야 한다.
• 특정 부분의 오류로 인해 전체 서비스에 문제가 생길 수 있다.
• 시스템이 거대해질 수록 코드를 이해하기 어려워지고, 유지보수하기가 어려워진다.

 

MSA (Micro Service Architecture)

👉 장점

• 서비스별로 독립적으로 모듈을 나눠 구현함으로서, 개발이 용이 (빌드 및 테스트 시간 단축)하다.
• 특정 서비스가 버그가 생겨 중단되더라도, 전체 서비스에는 영향을 미치지 않는다.
• 폴리그랏 아키텍쳐 구성이 가능하여 (폴리그랏 : 여러 언어(프레임워크)를 구사하는 것) 서비스별 최적의 기술 사용이 가능하다.
• ex) 읽기 작업이 많은 서비스에는 Node + Redis를 트랜잭션 및 안정성이 중요한 서비스는 Spring + RDB 적용
• 서비스마다 선택적인 확장 (특정 서비스 사용률이 높다면 해당 서비스만 Scale out 가능)
• (추가) 배포 단위가 작아지고, 결합도가 낮아 후에 설계 변경시 부담이 비교적 적다.

 

👉 단점

• 성능이슈가 있을 수 있음. (모놀리식의 Method로 호출하던 것을 REST 방식으로 Network I/O를 거치기 때문에 )
• DB가 서비스 별로 분리되어 있을 수 있어, 트랜잭션이 불편하다.
• 관리 포인트가 많다는 점 (서비스 별 로깅, 모니터링, 배포, 테스트, 인프라 등..)

 

결론

개인적으로는 MSA 서비스가 관리포인트가 많고, Method 대신 API로 사용하면서 굳이 불필요하게 Network I/O를 탄다는 점이 조금 부담스럽게 느껴졌다.

 

하지만, 기존 기본적인 파일 구조가 복잡한 Django의 app이 3개 이상만 되도 눈을 부릅뜨고 수정하고자 하는 파일을 찾아야 했던 기억을 떠올리면, 서비스 단위로 분리해 작업하는 것을 추구하는 MSA는 매우 매력적인 것 같다.

 

만약 추가적인 Network I/O로 인해 Client 입장의 Response Time Delay가 크게 체감되는 부분이 아니라면, MSA 방식의 아키텍쳐 구성을 좀 더 긍정적으로 고려해도 좋을 것 같다. 

 

 

 

참고 문헌

• https://dongsik93.github.io/til/2019/07/10/til-etc-msa/
• https://lion-king.tistory.com/entry/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%84%9C%EB%B9%84%EC%8A%A4-vs-%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9D-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-MicroService-vs-Monolithic-Architecture-%EA%B0%84%EB%8B%A8-%EC%86%8C%EA%B0%9C-%EB%B0%8F-%EC%A3%BC%EA%B4%80%EC%A0%81-%EC%9D%98%EA%B2%AC

 

(+ 추가) Django에서 MSA 구성시 USER 관련 서비스 (로그인, 회원가입, 인증, 인가 등)는 코어 서비스랑 같이 있는 경우가 많음. 단 USER 관련 서비스가 규모가 크고 기능이 많이 요구되는 경우 (인증 인가 등) 따로 하나의 Service로 뺄 수도 있는 것 같다.