모놀리스란?
여기서 설명할 모놀리스는 주로 배포 단위를 말하는 것입니다.
시스템 기능을 함께 배포해야 할 때, 이를 모놀리스로 간주합니다.
모놀리스 시스템은 최소한 3가지 유형이 있습니다.
단일 프로세스 시스템
분산 모놀리스 시스템
외부 블랙박스 시스템
단일 프로세스 모놀리스
모든 코드가 단일 프로세스로 배포되는 시스템입니다.
이런 단일 프로세스 시스템은 데이터를 거의 항상 데이터베이스에서 읽거나 데이터베이스에 저장하기 때문에, 단순하면서도 독자적인 분산 시스템입니다.
모듈식 모놀리스
단일 프로세스 모놀리스의 하위 집합인 모듈식 모놀리스(modular monolith)는 일종의 변형입니다.
단일 프로세스는 별도 모듈로 구성되어 있으며 각 모듈은 독립적으로 동작할 수 있지만, 모듈식 모놀리스는 배포를 위해서 결합이 필요합니다.
소프트웨어를 모듈로 분해한 모놀리스 유형입니다.
기업에서 모듈식 모놀리스는 좋은 선택이 될 수 있습니다.
모듈 경계가 잘 정의되어 있으므로 병렬 작업을 많이 수행할 수 있지만 배포 고려사항은 훨씬 단순해지기 때문에, 분산 마이크로서비스 아키텍처에서 발생하는 문제를 피할 수 있습니다.
모듈식 모놀리스의 문제 중 하나는 코드 수준에서 지원하는 분해 능력이 데이터베이스 부문에는 부족하므로 향후 모놀리스를 끌어내고 싶을 경우에 중대한 문제에 직면한다는 사실입니다.
분산 모놀리스
분산 모놀리스(distributed monolith)는 여러 서비스로 구성되는 시스템이지만 어떤 이유로든 전체 시스템을 함께 배포해야 합니다.
분산 모놀리스는 분산 시스템의 모든 단점과 단일 프로세스 모놀리스의 단점까지 포함하며, 양쪽의 장점을 충분히 발휘하지 못합니다.
분산 모놀리스는 전형적으로 정보 은닉이나 비즈니스 기능의 응집력 같은 개념이 희박한 환경에서 등장합니다.
또한, 서비스 경계 지점에서 변경이 발생하기에 결합도가 매우 높은 아키텍처를 만들어내며, 지역적인 범위에서 나 쁜 의도가 없는 듯한 변경사항이 외부까지 영향을 미쳐 시스템의 다른 부분을 망가뜨립니다.
외부 블랙박스 시스템
마이그레이션 노력의 일환으로 본해하기를 원하는 몇몇 외부 소프트웨어를 모놀리스로 간주할 수 있습니다.
이런 소프트웨어로는 급여 시스템, CRM 시스템, HR 시스템 등이 있습니다.
이 소프트웨어 시스템들의 공통점은 우리에게는 코드를 변경할 역량이 없는 점입니다.
시스템 자체 인프라에 배포한 상용 소프트웨어거나 사용 중인 SaaS 제품일 수도 있습니다.
모놀리스의 문제점
단일 프로세스 모놀리스나 분산 모놀리스 등은 구현과 배포 결합도의 문제점에 더 취약합니다.
프로젝트를 진행하다 보면, 동일한 코드를 변경하기 원하는 다양한 개발자들이 있습니다.
주체가 누가 되어서 코드를 관리할지 애매한 경우도 있습니다.
모놀리스를 사용한다고 해서 반드시 이 문제에 직면하는 것은 아니며, 마찬가지로 마이크로서비스 아키텍처를 사용한다고 해서 문제를 피할 수 있는 것도 아닙니다.
하지만 마이크로서비스 아키텍처는 각 서비스 중심으로 더 구체적인 경계가 있으므로 이 문제를 줄이기 위한 유연성이 더 뛰어납니다.
그리고 모놀리스는 특정 한 개의 장애가 시스템 전체에 영향을 주게 됩니다.
예상치 못한 결함이 발생하고 그에 따른 높은 테스트 비용과 높은 출시 사이클이 필요합니다.
이러한 장애에 대해 내성이 부족합니다.
모놀리스의 장점
단일 프로세스 모놀리스는 훨씬 더 간단한 개발자 워크플로우를 만들어냅니다.
또한 모니터링, 문제 해결, 전 구간 테스트를 단순화할 수 있습니다.
모놀리스는 모놀리스 자체 내에서 코드 재사용을 단순하게 만듭니다.
분산 시스템 내에서 코드 재사용을 원한다면, 코드를 복사할지, 라이브러리를 분해할지, 공유 기능을 서비스로 분리할지 등을 결정해야 합니다.
모놀리스를 사용하면 필요한 모든 코드가 있으므로 사용하기만 하면 됩니다.
모놀리스는 무조건 안좋은 것인가?
무조건 안좋지 않습니다.
안타깝게도 모놀리스라는 용어를 레거시와 동의어 취급하는 사람들이 많습니다.
모놀리스 아키텍처는 선택이며, 올바른 선택일 수도 있고, 아닐 수도 있습니다.
모놀리스 아키텍처나 마이크로서비스 아키텍처를 선택할 때는 우리가 처한 환경과 시스템 등을 고려하여 유연하게 판단할 필요가 있습니다.
후기
우리는 소프트웨어를 만드는 이유를 다시 생각해볼 필요가 있습니다.
참조 자료: 마이크로서비스 도입 이렇게 한다