궁금한게 많은 개발자 노트

[ Architecture ] Microservice와 Monolithic 본문

Back End

[ Architecture ] Microservice와 Monolithic

궁금한게 많은 개발자 2023. 7. 22. 23:03

하나의 앱을 개발하기 위해서는 우선 목적과 요구사항에 맞는 아키텍처를 설계해야 합니다.

애플리케이션 아키텍처는 기본적으로 애플리케이션을 설계하고 구축하는 데 사용하는 패턴과 기술을 설명합니다. 

아키텍처는 애플리케이션을 구추할 때 따라야할 로드맵과 모범 사례를 제공하여 체계적으로 구성된 애플리케이션을 완성할 수 있게 도와줍니다.

여기서 패턴은 문제에 대한 반복 가능한 솔루션을 의미합니다. 쉽게 설명해서 자주 발생하는 문제들을 미리 예방하기 위해 해결할 수 있는 템플릿을 만들어 적용하여 문제를 해결할 수 있도록 해줍니다. 이러한 패턴을 연결해 일반적인 애플리케이션 아키텍처를 만들 수 있습니다.

애플리케이션 아키테처의 종류 중 대표적으로 Monolithic 구조와 Microservice 구조가 있습니다.

Monolithic vs Microservice

 

 

Monolithic Architecture

소프트웨어의 모든 구성요소가 하나의 프로젝트에 통합되어 있는 서비스입니다. 즉, 하나의 애플리케이션 내에 모든 기능이 포함되어 있는 단일 애플리케이션입니다.

그렇기 때문에 각 필요한 기능을 담당하는 서비스 사이에 상호 작용과 의존성이 긴밀하게 연결되어 있습니다.

과거에는 많이 사용되던 구조로 레거시 코드로 많이 존재합니다.  

 

장점

  • 소규모 프로젝트의 빠른 개발 및 통합 테스트 용이
  • 단일 애플리케이션으로 빌드 및 배포 간편

단점

  • 규모가 커지면 전체 시스템 구조 파악이 어려움
  • 마찬가지로 규모가 커지면 빌드 및 유닛 테스트, 유지 보수, 배포 시간 급증
  • 서비스의 특정 부분만 scale-out하기 어려움 (효율적 자원 관리의 어려움)
  • 부분의 장애가 전체 서비스의 마비로 이어질 수 있음
  • 하나의 프레임워크와 언어에 종속
  • 새로운 기술 적용의 제약

간편하다는 장점이 있지만, 단점 또한 이러한 단순함 때문에 발생합니다. 점점 서버의 규모가 커지고 애플리케이션이 복잡해져감에 따라 Monolithic 구조의 단점이 부각되면서 생겨난 구조가 Microservice구조입니다.

 

 

Microservice Architecture

마이크로서비스란 애플리케이션을 상호 독립적인 최소 구성요로소 분할한 단위입니다. 마이크로서비스는 서로 유연하게 결합되어 배포되므로 서로 영향을 미치지 않습니다. (거의 미치지 않음)

Monolithic 구조의 애플리케이션의 로직을 기능 별로 나누어 책임이 명확한 작은 컴포넌트들로 분해하고 이들 각각을 구현하여 솔루션을 제공하는 구조입니다. 이러한 마이크로서비스는 작고 응집도 높은 책임 영역을 담당하고 완전히 상호 독립적으로 배포됩니다.

또한, 각 마이크로서비스에서 사용하는 프레임워크나 라이브러리, 언어에 종속되지 않는 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하게 통신이 가능합니다. 이에 따라 하나의 애플리케이션을 구성하고 있다고 하더라도 서로 다른 기술과 다영한 언어로 개발이 가능함을 의미합니다. 

MSA의 핵심은 small services, each running in its own process + independently deployable 으로 표현할 수 있습니다. 즉, 스스로 동작하며 독립적으로 배포될 수 있는 구조입니다.

 

장점

  • 기능 별 테스트 및 빌드 시간 단축
  • 독립적 배포 - 무중단 배포가 용이
  • 특정 서비스 확장 용이 (Scale Out 가능) - 클라우드 서비스에 적합
  • 한 기능의 장애가 전체 서비스의 마비로 이어질 가능성 적음 (기능별 대응 가능)
  • 유연한 기술 적용 - 다양한 언어와 기술로 구현 가능

단점

  • 성능 이슈 - 서비스 간 통신 시 API호출로 지연 발생 가능 (네트워크 통신)
  • Transaction 일관성 유지의 어려움 - 여러 서비스로 나뉘어 있어 일관성 유지의 어려움
  • 데이터 관리의 어려움 - transaction과 마찬가지로 데이터가 여러 서비스에 나뉘어 있기에 데이터 관리 복잡성 증가
  • 통합 테스트 어려움
  • 배포의 복잡성 - 독립적 배포는 가능하지만, 일일이 관리해줘야 하는 번거로움 존재
  • 개발 시간 증가 - 서버가 분리됨에 따라 DB 증가 또는 장애 추적/로깅의 어려움 존재

 

Monolithic구조의 대안으로 MSA가 나온 것은 맞지만 무조건 MSA가 좋다고 할 수는 없을 것 같습니다. 

개발하고자 하는 애플리케이션의 목적과 자원, 프로젝트의 규모에 따라 적합한 구조를 선택하는 것이 좋을 것 같습니다. 🙌

 

 

 

 

 

 

 

'Back End' 카테고리의 다른 글

[ FastAPI ] 비동기 메커니즘  (0) 2023.12.11
[ Database ] Elasticsearch vs RDBMS  (0) 2023.07.22
[ Python ] FastAPI에 대한 이해  (0) 2023.07.17
[ Python ] Django에 대한 이해  (0) 2023.07.17
[ Django ] psycopg2 psycopg2-binary 차이  (0) 2023.05.16
Comments