01_모놀리스에서 MSA로 - 서문
서론
우리는 모노 레포지토리에 모놀리스 구조로 탄탄한 백엔드를 운영 하고 있었습니다.
백엔드, 프론트엔드, 비동기 워커도 하나의 서버에 구축 할 수 있게 한 온전한 모놀리스 서버였습니다.
아키텍쳐와 배포 전략이 잘 맞아 떨어져서 개발에서 배포까지 빠른 경험을 할 수 있었습니다.
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
문제의식
우리 팀은 개발과 배포 속도가 매우 좋았습니다.
그래서 아키텍쳐에 대해 매우 만족하고 있었는데,
어떤 요구사항들은 현재 시스템에 구현하기 어려웠습니다.
회고해보면 그러한 요구사항에 맞는 기반이 되어 있지 않았고,
모놀리스 구조에서 너무 쉽게 다른 클래스를 참조 할 수 있다보니
참조 관계에 대해서 크게 중요하게 생각하지 않았던 것 같습니다.
특히 Django 는 Model 이 DB와 맵핑되고,
Model 에 메소드를 추가하던지 Mixin 패턴을 사용하던지 쉽게 덩치가 커질 수 있습니다.
그리고 데이터를 정규화 하다보면 서로 다른 도메인으로 볼 수 있는 모델들도 연결시키기 십상입니다.
이러한 구조로 계속 개발을 하다보면 서로간의 참조 관계가 너무 심해져서 수정이 어려워지게 됩니다.
그래서 데이터 구조든 클래스든 계층 구조로 만들어야 합니다.
모놀리스 구조에서는 의식적으로 분리하지 않으면 복잡한 메쉬 형태의 참조가 발생합니다.
MSA는 자연스럽게 서비스를(도메인) 분리하긴 하니까 이러한 문제가 해결 되기를 기대 하며 선택 할 것입니다.
그러나 MSA라고 해서 이런일이 발생하지 않는 다는 보장은 없을 것입니다.
~~마치 C++ 로 개발한다고 해서 객체지향이 아닐 수도 있는 것처럼요. ~~
쉽게 빠질 수 있는 함정
- 서비스를 작게 나누었어도 서비스 안에서 참조 구조를 염두에 두지 않으면 복잡도가 증가하는건 마찬가지
- 모든 구조는 한 방향으로 흐르고 메쉬형이 아닌 계층적 구조가 되게 해야 함