Microservices Architecture, MSA)란?

Microservices Architecture, MSA)는 현대 소프트웨어 개발 방법론에서 가장 주목받는 아키텍처 패러다임 중 하나가 되었습니다. 이 아키텍처는 대규모 애플리케이션을 개발하고 운영하는 방식을 근본적으로 변화시켰으며, 클라우드 네이티브 환경에서 서비스의 확장성과 유연성을 향상시키는 데 크게 기여하고 있습니다.

 

 

마이크로서비스 아키텍처의 개념과 정의

마이크로서비스 아키텍처는 하나의 애플리케이션을 여러 개의 작고 독립적인 서비스로 분할하여 개발하는 소프트웨어 아키텍처 접근 방식입니다. 각 서비스는 특정 비즈니스 기능을 수행하며, API를 통해 다른 서비스와 통신합니다. 이는 기존의 모놀리식(Monolithic) 아키텍처와 대비되는 개념으로, 모놀리식이 모든 기능이 하나의 코드베이스에 통합된 형태라면, 마이크로서비스는 기능별로 분리된 여러 서비스의 집합체라고 볼 수 있습니다.

마이크로서비스의 핵심 개념

각 서비스는 단일 비즈니스 기능에 집중

서비스 간 느슨한 결합(loose coupling)을 통한 독립성 확보

각 서비스는 독립적으로 배포 가능

서비스 간 통신은 API를 통해 이루어짐

 

---

등장 배경

마이크로서비스 아키텍처가 등장하기 이전 애플리케이션 빌드의 전통적인 방식은 모놀리식 위주였습니다. 모놀리식 아키텍처는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스입니다. 소규모의 프로젝트에서는 형태가 간단하고, 유지보수가 편하기 때문에 선호되지만 일정 규모 이상을 넘어가면 한계점에 봉착합니다.

 

Monolithic Architecture의 한계

 

• 높은 복잡도 및 결합도:
  애플리케이션 내의 모든 기능이 하나의 프로세스나 코드 베이스에 통합되어 있기 때문에, 작은 기능 변경이라도 전체 시스템에 영향을 미칠 수 있습니다. 이로 인해 개발자는 수정 시 예상치 못한 사이드 이펙트(부작용)를 파악하고 해결하는 데 어려움을 겪습니다.
• 확장성 문제:
  특정 서비스나 기능이 부하를 증가시킬 경우, 전체 애플리케이션을 함께 확장해야 합니다. 이는 리소스 낭비를 초래할 뿐만 아니라, 특정 부분만 별도로 스케일 아웃(scale-out)하기 어렵게 만듭니다.
• 빌드 및 배포 시간 증가:
  모놀리식 구조는 전체 시스템을 한 번에 빌드하고 배포해야 하므로, 코드 변경이 있을 때마다 전체 애플리케이션의 빌드 시간이 길어지고, 배포 시점에서 전체 시스템의 안정성을 고려해야 합니다.
• 유지보수 및 테스트의 어려움:
  모든 기능이 하나의 코드 베이스 내에 존재하므로, 특정 기능이나 모듈에 대한 독립적인 테스트가 어려워집니다. 또한, 하나의 작은 문제가 전체 시스템에 영향을 줄 수 있어 유지보수에 어려움을 겪게 됩니다.

 

 

이러한 단점을 극복하기 위해 마이크로서비스 아키텍처(MSA)가 등장하였습니다.

---

주요 특성 및 구성 요소

주요 특성

 

• 독립적 배포:
  각 서비스가 개별적으로 배포될 수 있으므로 한 서비스의 업데이트나 수정이 전체 시스템에 영향을 미치지 않습니다. 이러한 특성은 개발 주기와 유지보수를 단축시키고, 서비스별로 빠른 반복 배포가 가능하게 합니다.
• 기술적 다양성:
  각 서비스마다 요구사항과 성격에 맞는 최적의 기술 스택(프로그래밍 언어, 데이터베이스, 프레임워크 등)을 선택하여 적용할 수 있습니다. 이를 통해 서비스마다 성능과 효율성을 극대화할 수 있습니다.
• 모듈화 및 유지보수 용이성:
  비즈니스 로직을 기능별 서비스로 분리함으로써, 각 서비스의 역할과 책임이 명확해집니다. 이로 인해 코드의 이해도와 유지보수의 효율이 향상되며, 특정 기능에 대한 변경이나 확장이 보다 용이하게 진행됩니다.
• 확장성 및 자원 최적화:
  전체 시스템이 아닌 특정 서비스만 독립적으로 확장할 수 있기 때문에, 과도한 자원 낭비 없이 필요한 부분에 집중하여 확장이 가능해집니다. 이러한 특성은 시스템 자원을 최적화하고, 서비스 수요에 따른 유연한 대응을 가능하게 합니다.
• 결함 격리:
  하나의 서비스에서 발생한 문제가 다른 서비스로 전파되지 않도록 설계되어, 장애 발생 시 전체 시스템에 미치는 영향을 최소화할 수 있습니다. 이는 시스템의 신뢰성과 안정성을 높이는 중요한 요소입니다.
  
  이와 같이, 각 서비스가 독립적이고 모듈화되어 있음으로써 다양한 기술의 자유로운 적용, 유지보수의 효율성, 확장성과 장애 격리 같은 장점을 확보할 수 있습니다.

 

 

구성 요소 및 관련 도구

구성 요소	설명	대표 도구
API Gateway	API 인증, 라우팅 및 보안 관리	Amazon API Gateway, Kong
Service Mesh	서비스 간 통신 및 트래픽 관리	Istio, Linkerd
컨테이너 오케스트레이션	컨테이너 기반 애플리케이션의 배포 및 관리	Kubernetes, Docker Swarm
독립 데이터 관리	서비스별 전용 데이터 관리	PostgreSQL, DynamoDB
메시지 브로커	비동기 통신 및 이벤트 전달 기능 지원	RabbitMQ, Kafka

 

문제점

• 복잡성 증가:
  여러 개의 분산된 서비스들이 서로 통신하고 협력해야 하는 구조이기 때문에, 시스템 전체의 관리가 복잡해지고, 서비스 간의 통신 및 상호작용 관리가 어려워질 수 있습니다.
• 데이터 일관성:
  분산 환경에서는 각 서비스가 독립적으로 데이터를 관리하기 때문에, 트랜잭션 관리와 데이터 일관성 유지가 어렵고 복잡한 문제가 발생할 수 있습니다.
• 운영 비용 증가:
  많은 수의 독립적인 서비스를 동시에 운영하고 모니터링해야 하기 때문에, 인프라 비용 뿐만 아니라 관리 및 모니터링에 소요되는 노력과 자원이 증가할 수 있습니다.

7. 결론

마이크로서비스 아키텍처는 대규모 애플리케이션에서 유연성과 확장성을 제공하는 혁신적인 설계 방법으로, 각 서비스가 독립적으로 배포되고 관리될 수 있다는 점에서 조직이 빠르게 변화하는 시장에 효과적으로 대응할 수 있도록 돕습니다. 이러한 아키텍처는 독립적 배포, 기술 다양성, 그리고 결함 격리의 강점을 지니고 있으나, 동시에 분산 시스템의 복잡한 관리, 데이터 일관성 확보의 어려움, 그리고 증가하는 운영 비용과 같은 문제점도 내포하고 있습니다. 따라서 조직은 자신의 규모와 요구사항, 그리고 기술 역량을 충분히 고려하여 신중하게 도입 여부를 결정해야 할 것 입니다.

 

참조 

 

RedHat – 마이크로서비스란?
https://www.redhat.com/ko/topics/microservices/what-are-microservices

[간단정리] MSA란?

https://hahahoho5915.tistory.com/71

microsoft - 마이크로 서비스 아키텍처 스타일

https://learn.microsoft.com/ko-kr/azure/architecture/guide/architecture-styles/microservices

wikipedia - Microservices

https://en.wikipedia.org/wiki/Microservices