📌 분산 모놀리식 VS MSA
가장 최근의 인프라스트럭처에서 가장 핫한 이슈라고 한다면 단연코 Micro Service라고 말할 수 있다.
Micro Service Architecture(이하 MSA)는 커다란 하나의 Monolithic구성이었던 서버 시스템을 각각의 서비스 단위로 찢어두면서, 분리된 서비스들을 각자 유지보수하거나, Scale-Out하는 방식으로 Scalability를 끌어올려주는 방식이다. 시스템이 단일로 존재하는 것이 아니다보>니, 배포할 때에도 각 서비스 단위로 배포가 가능하며, 리소스들을 각자 가지고 있기 때문에 장애에 대응하기에도 좀 더 적절한 방식이라고 볼 수 있다.
📎 분산 모놀리식은 무엇일까?
분산 모놀리식(Distributed Monolithic)방식은 MSA와 Monolithic의 중간 방식이라고 할 수 있다. 서비스들이 자원을 공유 한다던지, 코드베이스를 공유한다던지, 서비스들간의 통신이 잦지 않은 방식이라던지, 배포시 한번에 전부 배포하는 방식등의 완전히 분리되지 않고 연결되어있다면 분산 모놀리식이라고 할 수 있다.
MSA를 위해서는 전체적인 아키텍쳐 변화 뿐만이 아니라, DBA, 복잡한 커뮤니케이션 망을 이해하고 리드할 수 있는 테크리드와 전반적인 팀 구조적으로도
MSA와 같이 따라줘야 완성할 수 있다.MSA는 실질적으로는매우 비용이 많이 드는 아키텍쳐라고 할 수 있다. 따라서 규모가 매우 거대한 기업이나 전문가가 많은, 인적자원이 풍부한 기업이 아니면 꺼리게 되는 점도 사실이다.
🤦 분산 모놀리식의 문제점
분산 모놀리식은 MSA와 모놀리식의 장점과 단점을 전부 아우르는 방식의 아키텍쳐이다.
📌 장점
- 모놀리식처럼 전체적인 서비스의 흐름을 파악하기 유용하다
- 차후의 MSA로 넘어가기에 좋다
- 위의 존재하는 분산 모놀리식 체크리스트에서 MSA에 가까운 특징들이 존재한다면 모놀리식보다 유지보수에서 편리함을 가져갈 수 있다
📌 단점
Scalability에 있어서 문제가 존재한다- 서비스간의
종속성이 존재한다 - 결국은 전체적으로
Monolithic의 단점을 가지게 된다 - 애매한 방식으로 나눠놨을 경우,
분산하기도 힘들고 유지보수도 힘든 계륵일 수 있다
차후의 MSA로 넘어가기 위한, 혹은 Monolithic의 배포방식보다는 서비스간의 분산된 배포를 위해서, 등등의 의도된 경우가 아니고, 완전한 MSA로 넘어가기 위해서는 몇가지 꼭 체크해야하는 리스트가 존재한다. 다음과 같은 리스트를 확인해보면, 의도적으로 MSA로 디자인된 시스템이 과연 정말로 MSA인지에 관래서 고찰할 필요가 있다.
📌 서비스들이 데이터를 분리하여 가지고 있는가?
다음과 같이 데이터베이스를 공유하고 있다면 그것은 분산 모놀리식을 의심해봐야한다. MSA는 각 서비스가 각자의 DB가 존재하고 그렇기 때문에 서비스 간의 커뮤니케이션이 요구된다.
📌 코드베이스와 라이브러리의 공유 -> 서비스간의 의존성
MSA의 서비스들은 각각의 라이브러리가 존재하면서, 코드베이스를 공유하지 않아서 서로에 대해서 종속성을 가지고 있지 않다. 하지만 분산 모놀리식의 경우 이런 부분에서 의존성을 남겨놓는 경우가 많다. 따라서, 일부의 수정 -> 전체의 변화로 이어지는 경우가 발생한다.
📌 동기적인 통신
MSA의 핵심은 서비스들간의 통신이다. 전체 서비스가 전부 찢어져 있기 때문에 서비스들이 서로 계속해서 소통하면서 Flow가 흘러간다. 만약 서비스들간의 통신방식이 동기적이라면, 한 서비스가 다른서비스를 기다리는 정체가 일어나게 된다. 이러한 방식은 MSA의 취지에 부합하지 않으며, 크게 봤을때 하나의 시스템으로 돌아가는 Monolithic과 크게 다르지 않다고 볼 수 있다.
📌 Event Sourcing을 사용하지 않는 시스템
Event Sourcing은 현재, 최신의 상태만 저장하는 방식이 아니라, 발생한 모든 이벤트에 대해서 저장하는 방식이다. MSA의 경우 비동기적 통신을 사용하기 때문에 이러한 이벤트를 기반으로 통신하는 경우가 존재한다. Event들은 수정될 수 없고, 재생성하기 쉬우며, 시스템 전반에 걸쳐서 존재하기 때문에 MSA는 이 소싱된 이벤트들을 하나의 Log처럼 이용한다. 이런 이벤트들은 DB와는 또 다른 개념으로 동작한다. 시스템 전반에 걸쳐서 메시징처럼 동작하기 때문에 서비스들이 서로에 대해서 신경쓸 필요 없이 자신에게 존재하는 이벤트를 쭉 처리하면 되는 것이다.
분산 모놀리식은 반대로, 이러한 이벤트를 필요로 하지 않는다. 분리되어 있지 않은(혹은 분리되어 있으나 느슨하게 결합된) 형태의 DB는 굳이 이벤트를 전반에 제공할 필요 없이 DB와 다이렉트로 소통하는 것이 훨씬 유용하기 때문에 Event Sourcing을 필요로 하지 않는다
📖 참고자료
https://scoutapm.com/blog/distributed-monoliths-vs-microservices
https://sarc.io/index.php/cloud/2091-event-sourcing
https://ssup2.github.io/theory_analysis/Event_Sourcing_Pattern/