[MSA] 마이크로서비스 아키텍처(MSA)란?

오늘은 내가 진행할 프로젝트에 적용하려는 마이크로서비스 아키텍처(MSA)에 대해 알아보고, 왜 이 아키텍처를 선택했는지에 대해 살펴보려고 한다. 기존의 모놀리식 아키텍처에서 벗어나 여러 개의 독립적인 서비스로 구성된 시스템을 만드는 것이 프로젝트에 어떤 이점을 줄 수 있는지 정리해 보자.

 

모놀리식 아키텍처(Monolithic Architecture)

애플리케이션의 모든 기능과 비즈니스 로직이 하나의 프로젝트로 통합된 형태

 

전통적인 방식으로, 하나의 코드베이스에서 모든 기능이 실행되며, 모든 프로세스가 긴밀하게 결합되어 있다.

이러한 구조에서는 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다. 

 

장점

• 소규모 프로젝트에서는 합리적이다.
• 개발, 빌드, 배포, 테스트가 단순하여 빠르게 진행할 수 있다.

 

단점

• 애플리케이션 구동 및 배포 속도가 느려진다.
• 작은 수정에도 전체 시스템을 빌드 및 배포해야 한다.
• 코드가 많아질수록 유지보수 및 확장성 관리가 어렵다.
• 일부 기능의 오류가 전체 서비스에 영향을 준다.
• 특정 기능에 맞는 다양한 기술 스택 적용이 어렵다.
• Scale-Out(수평 확장)이 불가능하여 트래픽 증가 대응이 어렵다.

 

마이크로서비스 아키텍처(MicroService Architecture)

애플리케이션을 여러 개의 작은 독립적인 서비스로 나누어 운영하는 방식

 

하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 독립적으로 개발, 배포, 확장이 가능하며, 서비스 간 통신을 통해 하나의 애플리케이션을 구성한다. 이 구조에서는 각 서비스가 개별적으로 실행되므로 특정 기능의 트래픽이 증가해도 해당 서비스만 확장할 수 있다.

 

장점

• 독립적인 서비스 배포로 빠른 배포가 가능하다.
• 특정 서비스만 배포가 가능하여 전체 서비스 중단이 필요 없다.
• 각 서비스별로 서버를 나눌 수 있어 메모리 및 CPU 관리에 효율적이다.
• 기능별 최적화된 기술 스택을 선택할 수 있다.
• 서비스 간 모듈화가 잘 되어 개발 속도가 증가한다.
• 서버 장애 발생 시 격리 및 복구가 쉽고, 장애가 전체 시스템으로 확산될 가능성이 낮다.

단점

• 서비스 간 통신 비용(Latency)이 증가한다. - REST API, 메시지 큐 등 사용
• 서비스가 많아질수록 트랜잭션 관리, 장애 추적, 테스트 복잡성이 증가한다.
• 서비스별 개별 DB를 사용하여 데이터 조회가 어렵고 중복 가능성이 존재한다.
• 전체 서비스가 커질수록 아키텍처가 복잡해지고 운영 부담이 증가한다.

 

📌Monolithic VS Microservices

아래 그림과 같이 애플리케이션을 하나로 관리하는 모놀리식에 비해, 마이크로서비스는 애플리케이션을 작은 독립적인 서비스로 분리하고, 각 서비스는 나눠서 개발 및 관리를 진행한다.

 

MSA 선택 이유

모놀리식 아키텍처는 개발 유연성 부족, 장애 발생 시 격리 어려움, 배포 및 롤백 리스크 증가, 리소스 낭비 등 다양한 단점을 가지고 있다. 소규모 프로젝트에서는 모놀리식이 더 효율적일 수 있지만, 대규모 시스템에서는 MSA의 장점이 훨씬 크다. 특히, 빠른 기능 추가 및 업데이트 / 서비스별 독립적 확장 / 장애 격리를 통한 안정성 확보 등 이러한 장점 때문에 MSA를 도입하는 것이 더 적합하다고 판단했다. 

 

앞으로 MSA를 적용하면서 겪은 경험이나 문제점도 정리해서 공유할 예정이다.

 

 

 

참고자료

https://velog.io/@dmchoi224/Microservice-Architecture-MSA-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Monolithic