서론
우리는 모노 레포지토리에 모놀리스 구조로 탄탄한 백엔드를 운영 하고 있었습니다.
백엔드, 프론트엔드, 비동기 워커도 하나의 서버에 구축 할 수 있게 한 온전한 모놀리스 서버였습니다.
아키텍쳐와 배포 전략이 잘 맞아 떨어져서 개발에서 배포까지 빠른 경험을 할 수 있었습니다.
CTO 가 교체 되면서 MSA 전환 논의가 시작되었고 그로부터 경험한 것들을 정리하고자 합니다.
아마 모놀리스로 개발했더라면 MSA로 전환하고 싶은 순간이 있을 것 입니다.
그런데 반대로 MSA로 개발했다면 모놀리스로 전환하고 싶은 순간이 있을까요?
그렇다고 해서 MSA 가 더 우월하다는 증거는 아닐 것입니다.
MSA 전환 논의 후 스터디도 하고 여러 아티클을 찾아봤습니다.
공통적으로 많이 보이는 문구는 “점진적으로 하나씩 전환”한다는 것입니다.왜냐면 모든 빅뱅은 잔해만 남는 다는것이 이 바닥의 진리기 때문이죠.
아무튼 실행을 하기 위해서는 왜 해야하는가 당위성부터 설득시켜야 합니다.
이러한 사항들은 조직마다 다를 것이므로 저는 제가 겪은 기술적인 사항들에 대해 집중하겠습니다.
또한 개인적인 경험이기 때문에 django 로 만든 경험에 한정된 다고 말씀드리겠습니다.
| - | 장점 | 단점 |
|---|---|---|
| 모놀리스 | 직관적 아키텍쳐로 초기 개발 속도 빠름 테스트, 배포 및 운영이 상대적으로 쉬움. 네트워크 호출로 인한 오버헤드가 적음. |
규모가 커질수록 코드 관리가 복잡해짐. 작은 변경사항도 전체 배포를 요구하여 배포 시간이 길어짐. 특정 모듈의 장애가 전체 시스템 장애로 확산될 가능성이 큼. 기술 변경 및 신기술 적용이 어렵고 비용이 많이 듦. 유지보수와 기능 추가가 점점 어려워짐. |
| MSA | 독립적인 서비스 단위로 개발, 배포 및 유지보수가 가능. 장애 발생 시 전체 서비스가 아닌 특정 서비스로 제한되어 장애 격리가 쉬움. 서비스 단위로 확장(Scale-out)이 가능하여 자원 활용 효율이 좋음. 서비스별로 다양한 기술 스택 선택 가능. 새로운 기술 도입이 용이함. |
서비스 간 통신이 많아 네트워크 레이턴시가 증가할 수 있음. 데이터 관리, 트랜잭션 처리, 일관성 유지가 복잡해짐. 서비스가 많아질수록 관리 및 모니터링이 복잡해짐. 인프라와 운영이 복잡하고 초기 구축 비용과 시간이 많이 듦. 분산 시스템이기 때문에 장애 대응 및 복구 로직이 복잡함. |
아마 이러한 비교표를 많이 보셨을 것 같습니다.
그러나 모놀리스의 단점이 MSA에서 발생하지 않을까요?
근본적으로 설계와 코드 품질에 대한 지속적인 개선과 관리가 없으면 MSA를 해도 같은 어려움을 겪을 겁니다.
하지만 현재 프로그램의 발전을 위해서도 MSA와 비교는 필요하고 서로의 장점을 취하는 전략이 필요하겠습니다.
참고자료
마이크로서비스 아키텍처 구축 샘 뉴먼 저자(글) | 정성권 번역 https://product.kyobobook.co.kr/detail/S000202596905
마이크로서비스 도입, 이렇게 한다 샘 뉴먼 저자(글) · 박재호 번역 https://product.kyobobook.co.kr/detail/S000001932752
MS 클라우드 패턴 https://learn.microsoft.com/ko-kr/azure/architecture/patterns/
가상 면접 사례로 배우는 대규모 시스템 설계 기초 2
1편 내용이 좋아서 2편도 봤는데 2에는 MSA에서 참조 할 만한 내용이 더 많습니다.
https://product.kyobobook.co.kr/detail/S000211656186