개념
시스템을 독립적으로 배포할 수 있는 서비스들로 구성하고, 각 서비스는 잘 정의된 API로 통신하는 것 으로 적용하는 목표와, 기준이 명확하지는 않다.
다음과 같은 특징을 가지면 MSA 라고 볼 수 있다.
- 서비스 단위로 변경하고, 독립적으로 배포하여 시스템을 빠르게 변경할 수 있다.
- 각 서비스를 담당하는 팀이 독립적으로 기획, 개발, 배포하여 다른 팀과 협업하거나 일정을 조율할 필요가 없다.
- CI/CD 프로세스의 모든 과정이 독립되어야 한다.
-
서비스 단위로 장애를 차단하고 성능 확장(스케일 아웃) 을 할 수 있다.
-
서비스 간에 잘 정의된 API를 사용하여 서로 통신한다. 각 서비스의 내부 구현은 숨긴다.
- 서비스 간에 데이터를 조회하거나, 트랜잭션을 발생시켜야 하는 경우, REST API나 이벤트를 통해 통신한다.
- 서비스 간에 임의적인 접근이 불가능하도록 격리되어야 한다.
- 다른 서비스가 임의로 코드를 참조할 수 없도록 소스 코드를 분리하고, 정해진 인터페이스로만 접근하게 해야하며, 데이터베이스를 액세스하지 못하게 차단해야 한다.
정리하자면 마이크로서비스 아키텍처를 제대로 적용한 시스템은
서비스가 업무 단위로 분리되어 서로 정해진 인터페이스로만 통신하고,
독립적으로 실행하며 독립적으로 배포되어야 한다.
시스템이 마이크로 서비스 아키텍처에 적합한지 다음을 기준으로 판단 할 수 있다.
- 비즈니스 민첩성
- 변경사항 리드 타임(코드 변경이 branch에 커밋되는 시점부터 배포 가능 상태가 되기까지의 시간)을 단축하여 시장의 변화 요구에 빠르게 대응하는 것을 의미
- 배포 빈도, 변경 사항 리드타임, 평균 복구 시간, 변경 사항 실패율을 기준으로 측정이 가능하다.
- 장애 격리
- 서비스를 기준으로 시스템을 분리하므로, 서비스 단위로 장애 확산을 방지할 수 있다.
- 확장성
- 시스템 규모를 필요에 따라 확장하고 축소하는 비기능 요구사항
마이크로서비스 아키텍처와 직접적인 관련이 없는 것들
- REST API는 마이크로서비스 아키텍처와 직접적인 관련이 없다.
REST API는 기능을 재사용하기에 좋은 수단으로, 오픈 API로 새로운 비즈니스를 창줄하기도 하는데 이는 아키텍처 스타일을 결정할 만큼 구체적인 목표가 될 수 있다.
그래서 현재는 프론트(SPA), 백엔드(REST API)를 제공하는 것이 표준적인 구조가 되었는데 아직도 JSP와 같은 오래된 기술을 사용하는 경우가 많다.
이러한 오래된 기술을 사용하는 경우에 REST API를 MSA의 특징으로 보는 경우가 있다.
- 클라우드 네이티브 (예로 서버리스) 가 보급이 되니, MSA와 함께 거론되는 경우가 많다.
클라우드 인프라의 보급이 활발해지면서 이를 사용하지 않는 MSA가 드문데, MSA를 기반으로 하는 대부분의 시스템은 인프라를 잘 활용할 수 있는 구조를 갖춰야 하므로, 클라우드 네이티브 애플리케이션이라고 말해도 무방할 것 같지만, 작은 Monolithic 시스템도 클라우드 인프라를 사용한다면 이를 잘 활용할 수 있는 구조를 갖춰야 한다.
따라서, 클라우드 네이티브 어플리케이션은 모놀리식 아키텍처와 마이크로서비스 아키텍처를 포함하는 개념이라 할 수 있다.
참조한 책 및 사이트
마이크로서비스 아키텍처 구축 가이드
https://hahahoho5915.tistory.com/71
https://learn.microsoft.com/ko-kr/azure/architecture/guide/architecture-styles/microservices
https://medium.com/design-microservices-architecture-with-patterns/when-to-use-monolithic-architecture-57c0653e245e