[Java] MSA
MSA란?
MicroService Architecture의 줄임말로 어플리케이션을 다양한 MicroService들로 구성하여 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 소프트웨어 개발 기법입니다.
독립적으로 실행이 가능하며 배포가 가능한 서비스를 의미합니다.
MSA 특징
- 각각의 마이크로 서비스는 Monolithic Architecture와 유사한 구조를 가집니다.
- 독립적으로 배포가 가능합니다.
- 다른 서비스들과의 의존성이 작습니다.
- 개별 프로세스로 구동되며, REST API와 같은 가벼운 방식으로 통신되어야 합니다.
- 서비스 지향 아키텍처(SOA : Service Oriented Architecture)
- 어플리케이션 구성요소가 통신프로토콜을 통해 다른 구성요소에 서비스를 제공하는 아키텍처 접근 방식
- 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상에 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 해당 서비스를 네트워크 상에서 연동하여 시스템 전체를 구축해 나가는 방법론
- ‘서비스’는 기능의 독립적 단위
- MSA와 SOA의 가장 큰 차이점은 DB를 같이 쓰는지 각각 쓰는지이다.
MSA 등장 배경
MSA가 등장하기 이전 대부분의 서비스는 Monolithic Architecture 방식으로 설계가 되어 있었습니다. 여기서 Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스를 말합니다. 간단하며 유지보수가 편리하기 때문에 소규모의 프로젝트에서는 선호되는 설계 방식입니다. 하지만 일정 규모 이상을 넘어가게 되면 Monolithic Architecture은 **다양한 한계점에 봉착하게 됩니다.
Monolithic Architecture의 한계점
- 장애 시 단일 장애점으로 동작하여 부분 장애가 전체서비스의 장애를 초래할 수 있습니다.
- 시스템 구조 및 서비스 수정으로 인한 영향도 파악이 어렵습니다.
- 서비스를 변경하거나 부분 scale-out하기 어렵습니다.
- 기능별 배포가 불가해 빌드 시간 및 테스트, 배포 시간과 비용이 많이 듭니다.
이러한 한계점들을 극복하기 위해 MSA가 등장하게 되었습니다.
MSA 패턴
MSA 구조
External Gateway
전체 서비스 외부로부터 들어오는 접근을, 내부 구조를 감추고 처리하기 위한 요소입니다. 사용자 인증과 권한 정책 관리 등을 수행하며, 적절한 서비스에 메시지를 전달하는 API Gateway가 가장 중요한 역할을 합니다.
Service Mesh
마이크로 서비스 구성 요소 간의 네트워크를 제어하는 역할을 합니다.
서비스 간에 통신을 하기 위해 service discovery, service routing, 트래픽 관리 및 보안 등을 담당하는 요소입니다.
service discovery
서비스를 등록하고 등록된 서비스의 목록을 반환하는 기능
service router
내부 로드밸런싱을 수행하는 기능
Container Management
각각의 서비스들에 대한 인프라 관리 기술로 개발자가 손쉽게 접근 및 운영할 수 있도록 만들어주는 역할을 합니다.
ex) Docker
Backing Service
어플리케이션이 실행되는 중, 네트워크를 통해 사용할 수 있는 모든 서비스를 의미합니다.
MSA 특성상 생성, 재생성, 인스턴스 삭제 등의 작업이 빈번하게 이루어지기에 보통 Message Queue를 활용한 비동기 통신을 많이 활용합니다.
Telemetry
MSA는 분산 환경에서 운영되기 때문에 서비스의 상태를 일일이 모니터링하고 이슈에 대응하는 것이 어렵습니다. 그렇기에 Telemetry는 서비스들을 모니터링하고 서비스 별로 발생하는 이슈에 대응할 수 있도록 환경을 구성하는 역할을 합니다.
CI/CD Automation
지속적인 통합과 지속적인 배포를 자동화하는 것은 배포가 잦은 MSA 시스템에서 반드시 필요한 요소입니다.
MSA 특징
API를 통한 상호작용(의존성 약화)
MSA는 API를 통해서만 각 서비스(기능)들끼리 상호작용할 수 있습니다. 즉, Micro Service는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부사항은 추상화합니다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, DB, 품질 유지 체계와 같은 기술적인 사항들은 모두 API에 의해 가려지게 됩니다.
각각의 서비스가 하나의 기능만 수행한다(재사용성, 배포 성능 향상)
MSA에서는 각각의 서비스들이 본인이 서비스하고자 하는 기능만 수행하게 됩니다. 그리고 해당 기능을 다른 어플리케이션에서도 재사용할 수 있어야 합니다.
다양한 언어와 기술로 구축할 수 있다
MSA에서는 각각의 기능의 특성에 맞춰 해당 기능에 적합한 언어와 기술을 사용하여 기능을 구현할 수 있기에 효율적인 개발이 가능합니다.
MSA 장점
배포
- 서비스별 개별 배포가 가능해 무중단 배포가 가능합니다.
- 특정 서비스의 요구사항을 반영하여 개별 수정이 가능합니다.
확장
- 특정 서비스에 대한 scale-out이 가능해 확장성이 뛰어납니다.
- 클라우드 기반 서비스 사용에 적합합니다.
장애
- 단일 장애점이 해결돼 일부 장애가 전체 서비스 장애로 이어질 가능성이 적습니다.
- 특정 기능에 대해서 발생하는 장애를 격리하고 해결이 수월합니다.
유지/보수
- 각각의 서비스 별로 분리되어 있기에 코드 이해도가 증가하고, 그에 따라 유지/보수 하기 용이합니다.
개발 효율
- 배포 시간을 단축 시킬 수 있어 생산성이 증가합니다.
- 특정 기능에 맞춰 적합한 언어와 기술 사용이 가능해 성능이 향상됩니다.
MSA 단점
설계 난이도
- MSA는 서비스가 모두 분산되어 있기에 내부 시스템의 통신 방식에 대해 고려해야합니다. 또한 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 고민하여 구현해야합니다.
성능
- 서비스 간 호출 시 API를 사용하기에 이로 인한 통신 비용이나 Latency(지연 시간)에 대한 이슈가 존재합니다.
트랜잭션 및 테스트
- MSA는 각각의 다른 서비스들을 연결하기 위한 통신이라는 고려요소가 있기에 단일 트랜잭션을 유지하는게 어렵습니다.
- 따라서 통합 테스트가 어렵습니다.
데이터 관리
- 데이터가 각각의 서비스에 분산되어 있어 관리 및 조회하기 어렵습니다.
Monolithic Architecture와 MSA 선택 시 고려사항
비용
MSA 아키텍처를 도입할 경우, Monolithic Architecture에 비해 비용을 얼마나 절감하고 Benefit을 끌어낼 수 있는가?
생산성
마이크로 서비스를 요구할 만큼 시스템 복잡도가 높은가? 또는 마이크로 서비스가 생산성을 저해할 가능성에 대해 고려했는가?
운영
개발과 운영을 동시에 할 인프라가 준비되어 있는가? 또한 DevOps 역량을 갖춘 인력이 있는가?
배포
무중단 배포하거나 배포를 자주해야 할 정도로 MSA가 필요한가?