[Architecture] 모놀리식 아키텍쳐 vs 마이크로서비스

 

 

🤔 모놀리식 아키텍쳐란 ? 

 

개념

모놀리식 아키텍처는 하나의 코드 베이스를 사용하여 여러 비즈니스 기능을 수행하는 전통적인 소프트웨어 개발 모델입니다. 

모든 기능이 하나의 프로젝트 내에서 tightly coupled(강하게 결합)되어 있으며, 하나의 애플리케이션으로 배포됩니다.

예를 들어 Java로 작업할 때, 전체 애플리케이션은 단일 코드로 작성되어 단일 데이터베이스에 연결됩니다. 그래서 모놀리식으로 개발한 애플리케이션은 마이크로서비스 아키텍처보다 구현이 쉽고, 덜 복잡하다는 장점이 있습니다.

 

모놀리식 아키텍쳐의 장점

 

✅ 간단한 개발 및 배포

모든 코드가 단일 코드 베이스에 있습니다. 변경 사항이 발생할 경우 필요한 모든 코드가 한곳에 존재한다는 의미로.,애플리케이션을 로컬에서 실행해야 할 경우 단일 애플리케이션만 실행하면 되는 간편함이 있습니다.

단일 프로젝트로 배포하면 되기 때문에 배포가 간단합니다. 새로운 기능이 추가되거나 버그가 수정될 때마다 단일 애플리케이션을 배포하면 됩니다.

✅ 보편성

대부분의 개발자가 모놀리식 아키텍처에서 작업한 경험이 있어, 프로젝트를 쉽게 시작할 수 있다.

✅ 디버깅이 쉬움

모든 코드가 단일 애플리케이션에 있기 때문에 디버깅하기 쉽다. 추가 구성을 수행하지 않고 코드를 실행하여 디버깅하면 된다.

 

모놀리식 아키텍쳐의 단점

 

❌ 규모가 커지면 유지 보수가 어려움

시간이 지남에 따라 애플리케이션이 커지면 관리가 어려울 수 있다. 모놀리식 애플리케이션은 중소형 애플리케이션에선 잘 작동하지만, 애플리케이션이 크고 복잡해지면 문제가 발생할 수 있다.

❌ 유연하지 않은 확장성

모놀리식도 확장할 수 있지만 전체 애플리케이션의 확장만 가능하다. 예를 들어 애플리케이션의 특정 부분에 대해 요청을 받으면, 이 부분만 확장할 수는 없고 전체 애플리케이션을 확장해야 한다.

❌ 대규모 팀 작업이 어려움

모든 팀이 동일한 코드, 동일한 프로젝트에서 작업하기 때문에 코드 병합에 대한 충돌 가능성이 높고, 기능 변경 시 다른 팀이 작업에 영향을 줄 수 있다.

❌ 기술 사용 제한

모놀리식 애플리케이션을 다른 기술로 변경하는 것은 어렵기 때문에, 일반적으로 모놀리식 애플리케이션을 만들면 오랜 기간 동일한 기술을 사용해야 한다.

 

 

모놀리식 아키텍처는 언제 사용하면 좋을까?

• 규모가 작은 애플리케이션인 경우
• 현 비즈니스를 통해 성장할 계획이 없거나, 복잡한 시스템 설계 및 관리가 필요하지 않은 경우
• 아직 아이디어를 구상 중인 단계라면 모놀리식으로 시작하는 것이 유리하다.
• 팀의 규모가 작거나 신생 팀인 경우, 또는 새로운 도메인일 때 적합하다.
• 아직 제품이 MVP 상태라면, 모놀리식은 사용자로부터 피드백을 수집할 수 있는 가장 빠른 방법이다.
• 주된 작업이 CRUD일 경우

 

 

 

🤔 마이크로 서비스 아키텍쳐란? 

 

마이크로서비스는 소프트웨어를 작은 독립 구성 요소 또는 서비스로 구성하는 아키텍처 접근 방식입니다.

각 서비스는 하나의 기능을 수행하고 잘 정의된 인터페이스를 통해 다른 서비스와 통신합니다.

각 서비스가 독립적이기 대문에 기술에 구애받지 않고, 고유한 데이터베이스를 소유할 수 있습니다. 

 

모놀리식 아키텍쳐의 장점

 

✅ 유연한 확장

각 마이크로서비스는 다른 서비스와 독립적으로 확장할 수 있습니다. 예를 들어 애플리케이션의 일부가 요청을 받을 경우, 전체 애플리케이션을 확장하는 대신 특정 마이크로서비스만 확장할 수 있기에 애플리케이션의 고가용성이 필요할 때 매우 유용합니다.

✅ 배포 및 유지보수 용이

마이크로서비스는 느슨하게 결합되어 있으므로 하나의 마이크로서비스만 배포할 수 있습니다. 이렇게 하면 애플리케이션의 작은 부분만 업데이트되므로 전체 애플리케이션의 작동을 멈출 필요가 없습니다.

✅ 독립적인 기술 선택 가능

각 마이크로서비스는 서로 다른 기술을 가질 수 있습니다. 하나는 Java, 다른 하나는 Node 등에서 수행될 수 있습니다.

✅ 장애 격리 가능

특정 마이크로서비스가 중단되더라도 전체 애플리케이션에 영향을 미치지 않고, 해당 마이크로서비스에만 영향을 미칩니다. 다른 부분은 정상적으로 작동될 수 있습니다.

 

 

모놀리식 아키텍쳐의 단점

 

❌ 개발 생산성 필요

여러 개의 마이크로서비스 중 하나에 새로운 기능을 구현해야 할 때, 다른 서비스에 접근할 수 있도록 로컬에서 많은 애플리케이션을 실행할 수 있는 환경을 갖춰야 합니다.

❌ 복잡한 운영 및 관리

서비스 개수가 많아질수록 모니터링, 로깅, 트랜잭션 관리 등의 운영 부담이 커짐.

❌  오류 식별의 어려움

마이크로서비스 아키텍처에서 오류를 식별하는 것은 모놀리식보다 훨씬 복잡하고 어렵다. 특히 비동기 통신일 때 더욱 어렵다. 애플리케이션을 디버깅하고 문제를 찾아야 하는 경우 로컬에서 둘 이상의 마이크로서비스를 실행해야 할 수 있다.

 

 

 

마이크로서비스 아키텍처는 언제 사용하면 좋을까?

• 비즈니스가 계속 성장하고 있는 경우
• 비즈니스 도메인에 대해 잘 알고 있거나, 요구 사항이 명확한 경우
• 복잡한 애플리케이션이 될 것임을 식별할 수 있는 경우
• 가용성 및 유연한 확장이 요구사항인 경우
• 서비스를 만드는 서로 다른 독립적인 팀이 존재하는 경우

 

 

마틴 파울러는 2014 년에 " Microservices – a definition of this new architectural term” 에서 ㅏ이크로서비스를 다음과 같이 정의했습니다. 

“마이크로서비스 아키텍처는 여러 개의 독립적인 서비스로 구성된 애플리케이션 구조로, 각 서비스는 독립적으로 배포 및 운영될 수 있다.”

그는 마이크로서비스 아키텍처의 핵심 요소로 독립적인 배포 가능성, 각 서비스의 자율성, 분산된 데이터 관리 등을 강조하며, 여러 장점들을 언급했습니다.

하지만 그는 MSA의 단점도 분명히 인식하고 있었으며, 무조건적인 MSA 도입을 경계했습니다.

 

🔥 마틴 파울러의 결론: MSA는 ‘필요할 때만’ 도입해야 한다

그는 MSA가 “출발점”이 되어서는 안 되며, 모놀리식 아키텍처에서 출발한 후 필요할 때 마이크로서비스로 전환하는 것이 올바른 접근법이라고 주장했습니다.

 

 

마틴 파울러는 모놀리식 아키텍처를 부정적으로 보지 않았으며, 오히려 다음과 같은 상황에서는 모놀리식이 더 나은 선택이라고 강조했습니다.

모놀리식 아키텍처는 규모가 커질수록 배포의 어려움, 코드베이스 관리의 복잡성 증가, 팀 협업의 어려움 등의 문제를 겪게 됩니다.

이를 “Big Ball of Mud(진흙 덩어리)” 라고 표현하며, 초기에 잘 설계되지 않은 모놀리식 애플리케이션이 시간이 지나면서 유지보수하기 어려운 구조가 된다고 경고했습니다.

 

🔥 마틴 파울러의 결론: 모놀리식으로 시작하고, 필요하면 MSA로 이동하라

그는 모놀리식 아키텍처가 대다수의 프로젝트에서 더 나은 출발점이라고 보았으며, 시간이 지나 확장성과 유지보수가 문제가 되면 마이크로서비스로 분할하는 것이 더 합리적이라고 주장했습니다.

 

 

트위터나 우버의 경우 모놀리식 기반의 MVP로 앱을 개발한 후 비즈니스 모델의 가치를 인정받고, 비즈니스가 확장됨에 다라 마이크로서비스로 전환한 사례입니다. 이런 사례를 참고해, 우선적으로 시작하는 단계에서는 모놀리식으로 개발하는 것을 권고하며, 서비스가 성장하면서 확장성과 유지보수 문제에 직면하면 점진적으로 MSA로 전환하는 것이 이상적인 선택이라고 말합니다. 

 

마치며 

아키텍쳐를 선택할 때는 프로젝트의 규모, 시장에서 얼마나 인정받았느냐 등 비즈니스적인 상황을 고려하여 설계해야한다는 것을 알게 되었습니다. 최근 마이크로서비스가 대세라지만, 그렇지 않는 케이스들도 있기 때문에 초기 아키텍쳐를 결정할 때는 다양한 상황을 고려해서 설계해야겠습니다.