Spring) 아키텍처(3) 모노리스 VS MSA

Monolithic Architecture

---

Monolithic Architecture(모노리스 아키텍처)는 애플리케이션을 하나의 큰 단위로 구성하는 아키텍처 스타일입니다. 이 구조에서는 모든 기능이 단일 코드베이스 내에서 하나의 애플리케이션으로 빌드되고 배포됩니다. 일반적으로 웹 애플리케이션에서는 프론트엔드, 비즈니스 로직, 데이터베이스 계층이 모두 하나의 애플리케이션으로 구성됩니다.

다들 이렇게 시작한다.

설명은 어렵지만 그냥 단순하게 Spring boot 뿐만 아니라 서버를 처음 개발하면 가장 먼저 개발하는 아키텍처 방식입니다.

서버하나를 만들어서 해당 서버에서 Database, Nosql, MQ 등등 여러 구성체에 중심해서 전계해주는 서버입니다.

 

 

모놀리식 애플리케이션은 보통 다음과 같은 구조로 이루어져 있습니다:

출처 : https://mozzi-devlog.tistory.com/34

• 사용자 인터페이스(UI) 계층: 사용자가 인터페이스를 통해 애플리케이션과 상호작용할 수 있는 프론트엔드 계층입니다.
• 비즈니스 로직 계층: 애플리케이션의 핵심 기능과 규칙을 정의하는 계층입니다. 데이터 처리 및 다양한 로직이 포함되어 있습니다.
• 데이터 액세스 계층: 데이터베이스와 상호작용하여 데이터를 생성, 읽기, 업데이트, 삭제(CRUD)하는 계층입니다.

이 구조에서는 모든 계층이 하나의 코드베이스에 포함되어 있으며, 빌드 시에 단일 아티팩트(JAR, WAR 등)로 패키징됩니다. 이 패키지는 하나의 서버 또는 여러 서버(로드 밸런싱)에서 배포될 수 있지만, 애플리케이션 자체는 하나의 단일 프로세스로 실행됩니다.

장점

출처 : https://velog.io/@heachanlee/MSA-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

모노리스 아키텍처는 다음과 같은 장점을 가집니다.

• 단순한 개발과 배포: 모든 기능이 하나의 코드베이스에 포함되어 있어, 전체 애플리케이션을 빌드하고 배포하는 과정이 비교적 간단합니다. 특히 초기 개발 단계에서는 이 방식이 효율적입니다.
• 일관된 성능: 모노리스 애플리케이션은 하나의 프로세스에서 실행되므로, 네트워크를 통해 데이터를 주고받을 필요 없이 빠르게 기능을 호출하고 실행할 수 있어 성능이 일정하게 유지됩니다.
• 쉬운 테스트: 모든 기능이 한 곳에 모여 있기 때문에 테스트가 단순하고, 테스트 환경도 통합적으로 관리할 수 있습니다.
• 개발 환경 세팅이 간단: 모든 코드가 단일 프로젝트에 있기 때문에 초기 개발 환경을 설정하거나 프로젝트에 새로 합류한 개발자가 빠르게 개발에 참여할 수 있습니다.

단점

출처 : https://velog.io/@heachanlee/MSA-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

모노리스 아키텍처의 단점은 다음과 같습니다.

• 유지보수 어려움: 애플리케이션이 커짐에 따라 코드베이스가 방대해지고 복잡해지므로, 특정 기능을 수정하거나 추가하는 데 시간이 많이 걸립니다. 특히, 모듈 간 의존성이 강해질수록 유지보수가 어려워집니다.
• 배포의 위험성: 작은 기능 하나를 수정해도 전체 애플리케이션을 다시 빌드하고 배포해야 합니다. 이는 새로운 버그나 문제를 야기할 수 있으며, 빠른 기능 추가 및 배포에 제약이 됩니다.
• 확장성의 한계: 모노리스 아키텍처에서는 모든 기능이 하나의 프로세스에서 동작하므로 특정 기능의 트래픽이 증가해도 독립적으로 확장할 수 없습니다. 예를 들어, 주문 관리 기능이 많이 사용된다고 해서 주문 관리 기능만 확장할 수 없습니다. 전체 애플리케이션을 수평적으로 확장해야 하며, 이로 인해 불필요한 리소스가 소모될 수 있습니다.
• 기술적 유연성 부족: 모노리스 아키텍처에서는 특정 기능에 맞춰 기술을 변경하는 것이 어렵습니다. 예를 들어, 데이터 처리 기능에 맞춰 새로운 기술 스택을 도입하려고 해도 전체 애플리케이션이 하나로 묶여 있기 때문에 제한적입니다.

모노리스 구조에 적합한 프로젝트

모놀리식 구조는 소규모 및 중소 규모의 애플리케이션이나 초기 개발 단계의 프로젝트에 적합합니다.

이 구조에서는 모든 기능이 하나의 코드베이스에 통합되어 있으므로, 프로젝트가 복잡해지지 않으면서도 빠른 개발과 배포가 필요한 경우에 특히 유리합니다. 다음과 같은 프로젝트에 모놀리식 구조가 적합합니다.

1. 스타트업 초기 단계 애플리케이션

스타트업의 초기 제품 개발 단계에서는 빠른 프로토타이핑과 기능 추가가 중요합니다. 모놀리식 구조는 하나의 코드베이스로 모든 기능을 구현하고 배포할 수 있어 초기 개발 속도가 빠르고, 단일 서버나 소규모 인프라로도 운영할 수 있습니다. 이는 개발 리소스가 제한된 상황에서 효율적입니다.

• 예시: 기본적인 사용자 인증, 데이터 입력 및 출력, 간단한 비즈니스 로직을 포함한 웹 애플리케이션 또는 모바일 애플리케이션 API 서버.

2. 중소 규모의 웹 애플리케이션

중소 규모 애플리케이션은 트래픽이 많지 않고, 복잡한 비즈니스 로직이나 다양한 서비스 통합이 필요하지 않은 경우가 많습니다. 이 경우 모놀리식 구조로도 충분히 효율적으로 운영할 수 있으며, 관리와 유지보수가 간편해집니다.

• 예시: 블로그, 포트폴리오 사이트, 간단한 전자상거래 애플리케이션 등. 이러한 애플리케이션은 기본적인 데이터 처리, 검색 기능, 상품 목록, 결제 기능 등을 포함할 수 있습니다.

3. 사내 사용을 위한 관리 애플리케이션

사내 관리용 애플리케이션은 사용 범위가 제한적이며, 대규모 트래픽을 처리할 필요가 없는 경우가 많습니다. 또한, 이러한 애플리케이션은 사용자가 고정되어 있고 기능 변경이 빈번하지 않기 때문에 유지보수도 비교적 쉽습니다.

• 예시: 재고 관리 시스템, 직원 출결 관리 시스템, 간단한 프로젝트 관리 도구 등. 이 경우 모놀리식 구조로 구현하여 모든 기능을 하나의 애플리케이션에서 관리하면 유지보수에 유리합니다.

4. 긴 수명이 필요하지 않은 단기 프로젝트

단기 프로젝트나 PoC(Proof of Concept)와 같은 프로젝트에서는 초기 설계가 복잡할 필요가 없습니다. 기능을 빠르게 구현하고 배포하는 것이 목적이므로, 모놀리식 구조로 개발하는 것이 적합합니다.

• 예시: 이벤트 관리 시스템, 한시적으로 제공되는 프로모션 웹사이트, 짧은 기간 동안 사용될 데이터 수집 및 분석 도구.

5. 단일 기능 또는 단일 도메인 중심의 애플리케이션

특정 기능만 제공하는 애플리케이션은 복잡한 아키텍처 없이 모놀리식 구조로 충분히 관리할 수 있습니다. 다양한 도메인 로직을 처리할 필요가 없고, 주요 기능을 일관되게 처리하는 데 중점을 둔 애플리케이션이 이에 해당됩니다.

• 예시: 이미지 처리 애플리케이션, PDF 변환기, 특정 API 서비스 제공 시스템 등. 단일 기능에 집중하여 빠르고 안정적인 성능을 제공할 수 있습니다.

6. 프로젝트 구성원이 적은 소규모 팀

소규모 팀에서는 모놀리식 구조가 협업 측면에서 효율적입니다. 하나의 코드베이스로 모든 기능이 통합되어 있어 개발자 간 의사소통과 협업이 용이하고, 개발 환경 설정이 단순해 팀 전체의 생산성을 높일 수 있습니다.

• 예시: 작은 스타트업이나 프로젝트 초기 단계의 팀에서 관리하는 고객 관리 시스템(CRM), 간단한 커뮤니티 포럼 등. 팀 내 협업을 단순화하고 관리의 복잡성을 줄이는 데 도움이 됩니다.

 

MSA (Microservices Architecture : 마이크로서비스 아키텍처)

---

마이크로서비스 아키텍처(Microservices Architecture)는 시스템을 여러 개의 작은 서비스로 나누어 구성하는 아키텍처 스타일입니다. 각 서비스는 특정 기능을 독립적으로 수행하며, 이 서비스들이 모여 하나의 시스템을 이루는 방식입니다. 각 서비스는 개별적으로 배포, 운영, 확장될 수 있으며, REST API, 메시지 브로커 등 다양한 통신 방식을 통해 서로 상호작용합니다.

출처 : https://mozzi-devlog.tistory.com/34

마이크로서비스 아키텍처의 구조와 특징

마이크로서비스 아키텍처에서는 시스템을 여러 작은 서비스로 분리하여 각 서비스가 독립적으로 관리될 수 있습니다. 각 서비스는 독립적인 비즈니스 도메인을 담당하며, 필요한 경우 독립적인 데이터 저장소도 가지게 됩니다. 이러한 구조는 애플리케이션이 복잡해질수록 더 유연한 관리와 확장을 가능하게 합니다.

1. 독립적인 배포
   각 서비스는 독립적으로 개발, 테스트, 배포될 수 있습니다. 한 서비스의 업데이트가 전체 시스템에 영향을 주지 않으므로 특정 기능에 대한 배포 주기를 다른 기능과 별개로 설정할 수 있습니다.
2. 각 서비스의 개별 확장 가능성
   특정 서비스에만 리소스를 집중하여 확장할 수 있습니다. 예를 들어, 사용량이 높은 서비스만 개별적으로 확장하여 필요 리소스를 할당함으로써 성능을 최적화할 수 있습니다.
3. 다양한 기술 스택 사용 가능
   각 서비스가 독립적이므로, 각 서비스가 특정 언어나 프레임워크에 얽매이지 않고 적합한 기술 스택을 사용할 수 있습니다. 예를 들어, 이미지 처리 서비스는 Python을, 사용자 관리 서비스는 Java를 사용할 수 있습니다.

장점

1. 유연한 배포와 빠른 개발 주기
   마이크로서비스는 독립적으로 배포할 수 있어 개발 주기가 빨라집니다. 이는 CI/CD(지속적 통합 및 지속적 배포)와 함께 사용되면 변경 사항을 빠르게 반영할 수 있는 장점이 있습니다.
2. 장애 격리와 높은 가용성
   하나의 서비스에 문제가 발생하더라도 다른 서비스에 영향을 미치지 않도록 격리할 수 있습니다. 특정 서비스에 장애가 생겨도 전체 시스템이 다운되는 것을 막을 수 있어 안정성과 가용성이 높습니다.
3. 수평 확장에 유리
   특정 서비스에 높은 부하가 걸리는 경우, 해당 서비스만 별도로 수평 확장하여 필요한 리소스를 늘릴 수 있습니다. 서비스별로 부하를 분산시키는 것이 용이하여 시스템 확장성이 뛰어납니다.
4. 팀 간 독립성 보장
   각 서비스가 독립적으로 운영되므로, 여러 팀이 동시에 다양한 기능을 개발하는 것이 용이합니다. 팀별로 분리된 서비스를 관리하며 작업이 가능하므로 팀 간의 작업 충돌이 줄어듭니다.

단점

1. 복잡한 운영 및 배포
   서비스가 분리되어 있으므로 배포와 운영이 복잡해질 수 있습니다. 각 서비스가 독립적으로 배포되기 때문에 CI/CD 파이프라인을 통한 자동화가 필요하며, 관리 포인트가 늘어나면서 배포 인프라 구축에 많은 노력이 필요합니다.
2. 데이터 일관성 관리가 어려움
   각 서비스가 독립적인 데이터베이스를 사용할 수 있기 때문에 데이터 일관성을 유지하는 데 어려움이 있습니다. 데이터가 여러 서비스에 분산되면 트랜잭션 관리와 데이터 동기화가 복잡해집니다.
3. 서비스 간 통신으로 인한 성능 부담
   각 서비스가 독립적이기 때문에 서비스 간 통신이 네트워크를 통해 이루어집니다. 이로 인해 REST API나 메시지 큐를 사용해야 하고, 네트워크 지연이나 장애가 발생할 경우 성능 저하가 일어날 수 있습니다.
4. 모니터링과 로깅의 복잡성 증가
   여러 서비스가 독립적으로 운영되기 때문에 각 서비스의 상태를 모니터링하고 로깅하는 것이 복잡해집니다. 모든 서비스의 상태와 성능을 실시간으로 모니터링하기 위해서 각 서비스에 대한 일관된 로깅, 모니터링 체계를 구축해야 합니다.

결론

---

MSA와 모놀리스 아키텍처는 각각의 장단점이 분명히 존재하며, 프로젝트의 성격과 요구 사항에 따라 적합한 아키텍처를 선택하는 것이 중요합니다. 모놀리스 아키텍처는 간단한 초기 설정과 배포의 용이성으로, 작은 규모의 애플리케이션이나 빠른 프로토타이핑이 필요한 경우에 유리합니다. 반면, MSA는 서비스 간 독립성을 보장하고 확장성을 극대화하여, 대규모 시스템이나 다양한 기능을 병렬적으로 개발하고 배포할 필요가 있는 환경에 적합합니다.

 

따라서 어떤 아키텍처를 선택할지는 프로젝트의 현재 규모와 향후 성장 가능성, 팀의 역량, 유지보수 요구사항 등을 종합적으로 고려해야 합니다. 궁극적으로 중요한 것은 아키텍처 선택이 시스템의 성능과 유지보수성, 확장성에 장기적으로 어떤 영향을 미칠지를 신중하게 판단하여, 프로젝트의 성공 가능성을 높이는 최적의 아키텍처를 선택하는 것입니다.

 

다음 글에서는 지금 서비스의 구조와 개선방안에 대해 작성하려고합니다.