MSA에 대하여
•
하나의 애플리케이션을 여러 개의 작은 서비스로 나누어 개발하고 배포하는 방식이다.
•
MicroService Architecture의 줄임말이다. 마이크로서비스는 애플리케이션을 느슨하게 결합된 서비스 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 기법이다.
•
대규모 서비스/어플리케이션 을 여러 개의 작은 규모의 서비스/어플리케이션 으로 나누는 접근 방식을 의미한다.
*서비스 지향 아키텍처(Service Oriented Architecture(SOA))
•
애플리케이션 구성요소가 통신 프로토콜을 통해 다른 구성요소에 서비스를 제공하는 아키텍처 접근 방식이다.
•
대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상에 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크 상에 연동하여 시스템 전체를 구축해 나가는 방법론이다.
•
‘서비스’는 기능의 독립적인 단위를 의미한다.
MSA 등장 배경
Monolithic Architecture(모노리스 구조)는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스이다. 현재 많은 회사들의 소프트웨어가 레거시 또는 필요로 인해 Monolithic 형태로 구현되어 있다. 소규모의 프로젝트에서는 Monolithic 형태는 간단하며, 유지보수가 편하기 때문에 선호된다. 그러나 일정 규모 이상을 넘어가면 Monolithic은 많은 한계점에 봉착한다.
기존 Monolithic Architecture의 한계
•
부분 장애가 전체 서비스의 장애로 확대될 수 있음
•
전체 시스템 구조 파악이 어려움
•
서비스 변경이 어렵고, 수정 시 영향도(side effect 등) 파악하기가 쉽지 않음
•
빌드 시간 및 테스트, 배포 시간의 급증
•
서비스의 특정 부분만 scale-out 하기 어려움
이러한 기존 모놀리식 구조 서비스의 한계점으로 인해 MSA가 등장하게 되었다.
MSA 특징
MSA는 API를 통해서만 상호작용할 수 있다. 즉, 마이크로서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
제대로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다. 즉, 어플리케이션 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임진다. 그리고 여러 어플리케이션에서 재사용할 수 있어야 한다.
어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 어플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.
마이크로서비스는 SOA에서 사용되는 집중화된 관리 체계를 사용하지 않는다. 마이크로서비스 구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점이다. REST 등 가벼운 통신 아키텍처, 또는 Kafka 등을 이용한 message stream을 주로 사용한다.
MSA 장점
1.
배포
a.
서비스별 개별 배포가 가능하다(배포시 전체 서비스의 중단이 없다).
b.
특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능하다.
2.
확장
a.
특정 서비스에 대한 확장성(scale-out)이 유리하다.
b.
클라우드 기반 서비스 사용에 적합하다.
3.
장애
a.
일부 장애가 전체 서비스로 확장될 가능성이 적다.
b.
부분적으로 발생하는 장애에 대한 격리가 수월하다.
4.
그 외
a.
새로운 기술을 적용하기에 유연하다(전체 서비스가 아닌 특정 서비스만 별도의 기술 또는 언어로 구현 가능)
b.
각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽다.
MSA 단점
1.
설계의 어려움
a.
MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야 한다. 또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야 한다.
2.
성능
a.
서비스 간 호출 시 API를 사용하기 때문에 통신 비용이나 레이턴시(대기 시간)에 대한 이슈가 존재한다.
3.
테스트/데이터 트랜잭션
a.
모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는 게 어렵다.
b.
통합 테스트가 어렵다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다.
4.
데이터 관리
a.
데이터가 여러 서비스에 분산되어 있어 조회하기 어렵다.
b.
데이터가 여러 서비스를 거치는 경우 데이터 무결성 / 정합성 유지가 상당히 어려워지며 이를 유지하기 위해 도입하는 기술의 러닝 커브가 높다.
c.
데이터를 관리하기 어렵다.
MSA 구성 요소와 패턴
외부 아키텍처와 내부 아키텍처
외부 아키텍처는 마이크로서비스가 운영되는 환경을 의미하며 크게 어플리케이션 영역과 플랫폼 영역, 인프라 영역으로 나눠진다.
•
어플리케이션 영역 : 플랫폼 영역 위에서 구동되는 어플리케이션 서비스 영역
◦
채널 (모바일 / 브라우저), 핵심 서비스 (프론트엔드 / 벡엔드), 데이터 (DB) 등
•
플랫폼 영역 : 인프라 영역 위에 올라가는 어플리케이션을 운영 및 구동하기 위한 영역
◦
플랫폼 서비스 : DevOps 파이프라인, 팀 업 환경, 메시지 버스, 로깅, 라이브러리 등
◦
MSA 기반 서비스 : API 게이트웨이, 모니터링, 구성 관리, 서비스 탐색 등
•
인프라 영역
◦
하드웨어 인프라
내부 아키텍처는 실제 비즈니스가 실행되는 내부 구조를 의미하며 마이크로서비스에서 제공하는 API나 비즈니스 로직, 이벤트 발행, 데이터 저장 처리 등에 대해 구조화한 것이다.
인프라 구성 요소
인프라 구성 요소는 마이크로서비스가 실행되는 하부 구조 인프라를 구축하는데 필요한 구성 요소를 의미하며 환경으로 나누면 크게 퍼블릭 클라우드 Iaas, PaaS나 베어메탈 + 프라이빗 클라우드 PaaS 환경으로 나뉜다.
플랫폼 패턴
플랫폼 패턴은 인프라 위에서 마이크로서비스의 운영과 관리를 지원하는 플랫폼 차원의 패턴으로 크게 개발 지원 환경을 위한 플랫폼 패턴과 마이크로서비스 관리 / 운영을 위한 플랫폼 패턴으로 구분할 수 있다.
개발 지원 환경을 위한 DevOps 인프라
마이크로서비스를 빌드, 테스트, 배포할 수 있게 도와주는 개발 지원 환경이며 이러한 인프라에서 수행하는 자동화 배포 작업을 CI / CD 라고도 부른다.
•
CI(Continueous Integration) : 지속적 통합, 개발자들이 작성한 소스 코드, 테스트 코드를 통합해서 자동으로 빌드 및 테스트
•
CD(Continueous Delievery / Deployment) : 지속적 제공 / 배포, CI 이후 빌드된 소스 코드를 실행 환경에 자동으로 배포
이러한 CI / CD를 위해 마이크로서비스별로 빌드/배포 파이프라인을 설계해야 하는데, 보통의 파이프라인 절차는 다음과 같다.
•
리포지토리 -> 빌드/유닛 테스트 -> 정적 분석 -> 통합 테스트 -> 배포 -> 마이크로서비스
마이크로서비스 관리 / 운영을 위한 패턴들
자동화 배포 말고도 마이크로서비스를 관리하고 운영하는데에 필요한 플랫폼 패턴들도 존재한다. 대표적인 패턴들은 다음과 같다.
•
서비스 레지스트리 패턴 : 마이크로서비스의 관리, 운영을 위해 마이크로서비스의 주소와 유동적인 IP를 매핑하여 저장하는 패턴
•
서비스 디스커버리 패턴 : 클라이언트가 여러 개의 마이크로서비스를 호출하기 위해 최적 경로를 찾아주는 라우팅 기능과 적절한 부하 분산에 필요한 로드 밸런싱을 위한 패턴
•
API 게이트웨이 패턴 : 서비스 단일 진입을 위한 패턴이며 서비스 레지스트리와 연계한 동적 라우팅, 로드 밸런싱 등 다양한 기능을 제공
•
BFF 패턴 (Backend for Frontend) : API 게이트웨이와 같은 진입점을 하나로 두지 않고 프론트엔드의 유형에 따라 각각 두는 패턴, API 게이트웨이 앞에 위치하며 클라이언트 종류에 맞게 최적화된 처리를 수행할 수 있도록 구성
•
외부 구성 저장소 패턴 : 각 마이크로서비스의 외부 환경 설정 정보를 분리하여 외부 구성 저장소에 저장하고 일관되게 변경 가능하도록 관리하는 패턴
•
인증 / 인가 패턴 : 중앙 집중식 세션 관리 패턴과 API 게이트웨이와 클라이언트 토큰을 활용한 패턴으로 나뉨
•
서킷 브레이커 패턴 : 장애가 발생한 서비스를 격리하여 유연하게 처리하기 위한 패턴
•
모니터링과 추적 패턴 : 서비스 상태를 모니터링하고 서비스 간 트랜잭션의 호출을 추적하기 위한 패턴
•
중앙화된 로그 집계 패턴 : 로그를 스트림 형태로 처리하며 서비스는 스트림의 전달 / 저장에 관여하지 않게끔 하는 패턴, ELK(Elasticsearch-Logstash-Kibana) / EFK(Elasticsearch-Fluentd-Kibana) / PLG(Promtail-Loki-Grafana) 등이 있음
어플리케이션 패턴
어플리케이션 패턴은 마이크로서비스 어플리케이션을 구성하는데 필요한 패턴으로 마찬가지로 다양한 패턴들이 존재한다.
•
UI 컴포지트 패턴 또는 마이크로 프론트엔드(MFA) : 백엔드 마이크로서비스처럼 프론트엔드 역시 기능별로 분리, 이를 조합하기 위한 프레임 형태의 부모 창을 통해 프론트엔드를 조합해서 동작하게 하는 패턴
•
마이크로서비스 동기 통신 및 비동기 통신 : 마이크로서비스 간 호출 시 동기식 호출을 먼저 검토하며 비동기식 처리가 필요할 경우 메시지 브로커를 이용하여 처리
•
비동기 방식의 이벤트 기반 아키텍처 : 분산 시스템 간에 발신자 - 수신자가 이벤트 (상태의 변화 등) 를 주고 받으며 처리하는 시스템 아키텍처
•
저장소 분리 패턴 : 각 마이크로서비스가 각자의 비즈니스를 처리하기 위한 데이터를 직접 소유하는 패턴
•
분산 트랜잭션 처리 패턴 - Saga 패턴 : 각 서비스의 로컬 트랜잭션을 순차적으로 처리하며 여러 개의 분산된 서비스를 하나의 트랜잭션으로 묶지 않고 각 로컬 트랜잭션과 보상 트랜잭션을 이용, 비즈니스 및 데이터의 정합성을 맞춤
•
읽기와 쓰기를 분리하는 CQRS(Command Query Responsibility Segregation, 명령 조회 책임 분리) 패턴 : 저장소에 쓰기 모델과 읽기 모델을 분리시키거나 물리적으로 저장소를 분리시킴
•
이벤트 소싱 패턴 : 쓰기에 최적화되어 있으며 트랜잭션 자체를 저장, 즉 상태 변경 이벤트를 계산해서 데이터 모델로 변경하지 않고 바로 이벤트 저장소에 그대로 저장하는 것
정리
•
MSA는 대규모 서비스 / 어플리케이션을 여러 개의 작은 규모의 서비스 / 어플리케이션으로 나누는 접근 방식이다.
•
각 서비스는 비즈니스 기능 단위로 구성되고 다양한 언어 / 기술을 사용해 개발되고 자동화된 배포 방식을 이용해 독립적으로 배포되며, 개별 프로세스에서 실행되고 API나 메시지 브로커 등의 가벼운 수단을 사용해 통신한다.
•
MSA의 구성 요소는 크게 외부 아키텍처와 내부 아키텍처로 나뉘며 외부 아키텍처에는 어플리케이션 영역 / 플랫폼 영역 / 인프라 영역으로 나뉘고 내부 아키텍처는 API나 비즈니스 로직, 이벤트 발행 및 데이터 저장 처리 등에 대해 구조화한 것이다.
•
MSA를 구성하거나 운영 / 관리하는데 필요한 외부 아키텍처와 내부 아키텍처와 관련된 다양한 패턴들이 존재한다.
•
마이크로서비스는 클라우드 인프라 환경에서 클라우드 네이티브한 특성(독립적으로 분리되어 배포될 수 있는 조각으로 구성)을 가지고 있으며 좀 더 유연한 확장 / 스케일 아웃 / 독립적인 개발 / 배포가 가능하다는 장점이 있다.
•
단점은 아키텍처 자체가 복잡할 수 밖에 없고 러닝 커브가 있으며 테스트 및 배포 복잡성이 존재하고 데이터 관리가 어려워지며 서비스 간 의존성이 높아지는 단점이 있다.
•
따라서 많은 전문가들이 MSA는 모놀리식 아키텍처로 효율적으로 서비스를 운영할 수 있다면 무리하게 도입하는 것보다는 새로운 기능을 추가할 때 작은 마이크로서비스를 만들어 시범적으로 운영해보고 전환하는 것을 권장하고 있다.
참고링크