Monolithic 아키텍처는 안티패턴일까?

어플리케이션을 설계하고 배포하는 방식을 결정하는 구조에는 크게 MSA와 Monolitic 아키텍처가 존재한다.

한때 정말 많은 국내 기업들이 MSA으로 Migration을 했다. 정말 장점 밖에 없어서 MSA로 다 옮겨간 것일까?

실제로 MSA 만능 주의가 있을 정도로 맹목적인 MSA 사랑을 보여주시는 개발자 분도 계실 정도로 MSA가 매력적인 것은 맞다. 하지만 Monolithic 패턴은 안티패턴인 것일까?

MSA에 대한 시리즈 포스팅을 시작하기 전에, 정확한 두 아키텍처의 장단점이 무엇이고 Monolithic 패턴에 대한 오해를 풀고자 해본다.

Monolithic Architecture

• 전체 기능을 단일 코드베이스로 개발하여, 해당 대규모 코드베이스를 통해 빌드/배포 하는 아키텍처이다.
• 일반적으로 하나의 중앙 데이터베이스를 사용하여 데이터를 공유한다.
• 하나의 단위로 배포가 되기에, 관리가 용이하다는 장점이 있다.
  • 이는 단점으로도 작용할 수 있는데, 하나의 단위로 배포된다는 것은 배포의 단위가 크기에 빌드/배포 시간이 오래걸릴 수 있다.
  • 또한 작은 수정에도 전체 시스템이 배포되어야한다.
• 내부적으로 호출할 수 있기에 네트워크를 사용하지 않는다.
• 하나의 시스템으로 동작하기에, 하나의 버그로도 전체 시스템에 영향을 줄 수 있다.
• 또한, scale-out이 불리하다는 점이 존재한다.
  • 시스템 전체를 확장해야하기에 어찌보면 당연하다.
• 하지만, 트랜잭션 관리가 용이하다는 장점이 뚜렷하게 존재한다.
  • MSA의 경우에는 분리된 데이터베이스를 사용하기에 트랜잭션을 관리하기가 어렵다는 단점이 존재한다.
  • 데이터의 일관성 부분에서는 Monolithic architecture가 유리할 수 있다.

Microservice Architecture

• MSA는 어플리케이션을 독립적으로 배포할 수 있는 작은 서비스 단위 로 나누어 각 서비스가 자신의 기능과 데이터를 책임지게 하는 아키텍처이다.
  • 그렇기에 각 서비스는 별도로 배포, 개발, 유지보수가 가능하다.
  • 이는 scale-out을 할때에도, 트래픽이 몰리는 특정 서비스만 확장이 가능하다는 뜻이다.
• 또한, 각 서비스별로 서로 다른 기술 스택 및 적절한 언어와 프레임워크를 선택할 수 있다.
• 각 서비스가 분리되어 있기에, 서비스간의 요구에 따라 신속하게 대응 및 배포가 가능하며, 이는 애자일에 부합하다.
• 결과적으로 보았을 때, 빠르게 변화하는 비즈니스 환경에 민첩한 대응이 가능하다.
  • 최근 비즈니스 환경은 빠르게 급변하고, IT 기술에 의존하는 케이스가 많기에 빠른 성장을 위해 민첩한 IT기술이 필요하기 때문이다.
• 하지만 장점만 존재하는 것이 아니라, 서비스 간 호출시에 네트워크를 사용하므로 통신 비용이나 latency이슈가 존재한다.
• 또한, 서비스가 분리되어 있어 트랜잭션의 복잡도가 증가하고 데이터 일관성을 유지하기 쉽지 않다.

결론

• 위의 두가지 아키텍처는 서로 장단점이 매우 뚜렷하다.
• 그렇기에 MSA가 굉장히 뜨겁지만, Monolitic은 레거시한 아키텍처도 아닐 뿐더러 안티패턴도 아니다.
• 마틴 파울러는 “Don't even consider microservices unless you have a system that's too complex to manage as a monolith.” 라고 얘기했다.
  • 그냥 모놀리식으로 관리할 수 있을 정도의 시스템이면 MSA는 고려하지도마라는 뜻이다.
• 아래는 절대적인 것은 아니지만, 시스템 복잡도 단계에 따라 아키텍처에 따른 개발 생산성을 그래프로 도식화 한 것이다.
  • 즉, MSA에 대한 무조건적인 찬성 보다는 각각의 장단점을 이해하고 알맞은 아키텍처를 적용하면 되는 것이다.

• 직면한 프로덕트의 특징과 요구사항에 따라 비용, 생산성, 운영 등의 비용을 고려하여 알맞는 아키텍처를 고를 수 있어야하고, 이를 위해서는 서로의 관점을 확실하게 이해할 필요가 있다.