MSA
MicroService Architecture의 줄임말
마이크로서비스는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.
서비스 지향 아키텍처(Service Oriented Architecture)
- '서비스'는 기능의 독립적 단위를 의미
- 애플리케이션 구성요소가 통신 프로토콜을 통해 다른 구성요소에 서비스를 제공하는 아키텍처 접근 방식
- 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상에 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해 나가는 방법론
MSA 등장 배경
모놀리식 아키텍처(Monolithic Architecture)
모놀리식 아키텍처는 전통적인 개발 방법으로 하나의 프로젝트에 소프트웨어의 모든 구성요소가 통합되어 있는 서비스이다. 소규모의 프로젝트에서는 모놀리식 형태는 간단하며, 유지보수가 편하기 때문에 선호됩니다. 하지만, 일정 규모 이상의 프로젝트에서는 많은 한계점에 봉착합니다.
모놀리식 아키텍처의 한계
- 코드 베이스가 커질수록 복잡해지고 유지관리 및 확장이 어려워진다.
- 일부 기능을 수정하거나 업데이트 하려면 전체 애플리케이션을 재배포 해야한다.
- 서비스 변경이 어렵고, 수정 시 영향을 파악하기 힘들다.
- 전체 시스템의 구조 파악이 어렵다.
- 서비스의 특정 부분만 스케일아웃(scale-out) 하기 어렵다.
이러한 기존 모놀리식 구조 서비스의 한계점에서 MSA가 등장하게 되었습니다.
MSA 특징
MSA는 API를 통해서만 상호작용할 수 있다. 즉, 마이크로서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저히 가려진다.
제대로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다. 애플리케이션을 작은 독립적인 서비스로 분리하고, 각 서비스는 모듈 또는 프로젝트로 나눠서 개발 및 관리를 진행한다. 이렇게 개발을 진행할 경우 독립적으로 개발 및 배포가 가능하여 개별적인 추가 배포 주기를 가질 수 있다.
애플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 애플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.
마이크로서비스는 SOA에서 사용하는 집중화된 관리 체계를 사용하지 않는다. 마이크로서비스 구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점이다. REST 등 가벼운 통신 아키텍처, 또는 Kafka 등을 이용한 message stream을 주로 사용한다.
MSA 장단점
장점
- 서비스 간 독립성으로 인해 확장성과 유연성이 높아진다.
- 시스템 내 일부 장애가 발생하여도 전체 서비스로 확장될 가능성이 적다.
- 특정 서비스에 대한 확장성(scale-out)이 유리하다.
- 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽다.
단점
- 서비스 간 통신이 필요하며, 서로 간 연결 구축 및 관리의 복잡성이 증가한다.
- 초기 아키텍처 설계에 많은 시간과 비용이 필요하다.
- 데이터가 여러 서비스에 분산되어 있어 조회 및 관리하기 어렵다.
