MSA
MSA에 대해 알아보자
변화하는 애플리케이션
모놀리틱 소프트웨어 구조는 로컬 환경에서 개발하기에도 편리하고 통합 시나리오 테스트를 수행 하기에도 가장 손쉬운 구성이며 모든 코드가 하나의 묶음으로 구성되어 있기 때문에 배포도 매우 간편하다.
하지만 이러한 소프트웨어 구조는 서비스가 지속적으로 성장하고 규모가 커질 때 한계에 부딪히게 된다. 3명의 개발자가 몇 가지 핵심 기능을 개발할 때에는 이와 같은 모놀리틱 아키텍처가 최적의 효율성을 보장하지만 개발자의 규모가 수십에서 백명 이상이 되고 서비스의 복잡도가 증가되면 아주 간단한 기능을 추가하기 위해서라도 매우 많은 줄의 코드를 수정 해야 함은 물론, 코드의 변화가 영향을 미치는 범위가 증가되기 떄문에 간단한 변화 하나에도 통합 테스트가 필요하게 된다.
모놀리틱 아키텍처가 가지는 문제점들은 배포 시간의 증가, 부분적 스케일 아웃의 어려움, 안정성의 감소 등 여러가지가 있다. 이러한 문제점들을 해결하기 위해 마이크로 서비스 구조가 등장 하게 되었다.
모놀리틱 이란?
소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이다. 웹 개발을 예로 들면 웹 프로그램을 개발하기 위해 모듈별로 개발을 하고, 개발이 완료된 웹 어플리케이션을 하나의 결과물로 패키징하여 배포되는 형태를 말한다.
MSA란?
Microsoft Architecture란 모놀리틱 아키텍처로 구성된 하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리하여 설계하는 패턴이라고 할 수 있다. 각각의 마이크로 서비스는 그 크기만 작을 뿐 자세히 살펴보면 각각이 하나의 모놀리틱 아키텍처와 유사한 구조를 갖게 된다.
MSA 특징
독립된 애플리케이션 개발로 인해 해당 도메인에 대한 책임만 가질 수 있게 된다.
각각의 애플리케이션은 외부에 제공해야 하는 기능에만 의존하므로 언어에 종속받지 않는다. 서비스에 특성에 따라 Node.js, C#, Python, PHP 등 다양한 언어를 구사할 수 있다.
각각의 독립된 기능은 확장에 유연하게 대응할 수 있다.
작은 규모의 애플리케이션 개발은 로컬 환경에서 신속하게 해당 기능에 대한 유지보수가 가능해진다.
MSA와 모놀리틱 비교
특성 | MSA | 모놀리틱 |
단위 설계 | 애플리케이션은 유연하게 결합된 서비스로 구성된다. 각 서비스는 단일 비즈니스 작업을 지원한다. | 하나의 애플리케이션만 존재하고 단일로 개발 및 배포한다. |
기능 재사용 | 마이크로 서비스는 클라이언트에 해당 기능을 표시하는 API를 정의하기 때문에 여러 서비스에서 재사용하기 용이하다 | 애플리케이션 내의 컴포넌트 간 기능 재사용은 코드 구현에 따라 재한적일 수 있다. |
애플리케이션 상호 통신 | 애플리케이션 마이크로 서비스는 서로 통신하기 위해 요청-응답 통신 모델을 사용한다. 일반적인 구현은 HTTP 프로토콜을 기반으로 REST API 호출을 사용한다. | 내부 프로시저(함수 호출)는 애플리케이션 구성요소간의 통신을 용이하게 한다. |
기술 유연성 | 마이크로 서비스는 서비스에 적절한 언어 및 프레임워크를 사용할 수 있다. | 하나의 애플리케이션으로 개발되어야 하니 단일 언어와 프레임워크를 선정해야 한다. |
데이터 관리 | 서비스 마다 자체 데이터베이스를 사용한다. | 하나의 데이터베이스로 관리한다. |
배치 | 각각의 서비스는 본인이 소유한 도메인에 대한 배치 기능을 구현한다. | 특정 기능에 대한 배치 변경에 따라 전체 애플리케이션이 재배포 되어야 한다. |
유지 관리 기능 | 독립된 서비스는 해당 도메인에 대한 이해만 요구하므로 유지보수가 용이하다. | 여러개의 도메인이 의존된 로직으로 작성되어 유지보수가 힘들어진다. |
복원성 | 특정 서비스에 대한 오류는 전체 시스템에 영향을 주지 않도록 유연하게 대응할 수 있다. | 특정 기능에 대한 오류는 애플리케이션 전체 에러로 전이될 수 있다. |
확장성 | 각 서비스는 독립적이기 때문에 상황에 맞게 유연하게 대처할 수 있다. | 특정 기능에 대한 스케일링에도 전체 애플리케이션의 스케일링을 조절해야 한다. |
MSA 도입시 간과하는 사항들
분산 컴퓨팅은 이론적으로는 효율적 일수 있으나 분산 컴퓨팅을 설계하면서 대부분의 개발자들이 간과하는 사실들이 있다.
소프트웨어 응용 프로그램은 네트워킹 오류에 거의 오류 처리를 하지 않고 작성됩니다. 그러므로 응답 패킷을 멈추거나 무한히 기다리므로 영구적으로 메모리 또는 기타 리소스를 소비합니다.
실패한 네트워크를 사용할 수 있게 되면 이러한 응용 프로그램은 지연된 작업을 다시 시도하지 못하거나 수동으로 다시 시작해야 할 수도 있습니다.
네트워크 대기 시간과 패킷 손실의 무지로 인해 애플리케이션 및 전송 계층 개발자는 무제한 트래픽을 허용 하여 패킷 손실이 크게 증가하고 대역폭을 낭비하게 됩니다.
트래픽 발신자 측의 대역폭 제한을 무시하면 병목 현상이 발생할 수 있습니다.
네트워크 보안에 대한 만족은 보안 조치에 지속적으로 관리해주어야 합니다.
네트워크 토폴로지 변경 사항은 대역폭 및 대기 시간 문제에 영향을 줄 수 있으므로 문제가 발생할 수 있습니다.
여러 관리자 는 경쟁 업체의 서브넷과 마찬가지로 원하는 경로를 완료하기 위해 네트워크 트래픽의 보낸 사람이 알고 있어야하는 충돌하는 정책을 수립 할 수 있습니다.
네트워크 또는 서브넷을 구축하고 유지하는 데 드는 "숨겨진"비용은 무시할 수 없으므로 막대한 불이익을 피하기 위해 예산에 기록해야 합니다.
시스템이 동질의 네트워크를 가정하면 처음 세 가지 오류로 인해 동일한 문제가 발생할 수 있습니다.
MSA 구현 시 고려사항
Msa는 각 서비스가 분리되어 비동기로 동작하기 때문에 런타임 환경에서의 상호작용을 테스트하기가 매우 까다롭다. 그래서 각 서비스의 초기 단계에서 최대한 테스트 커버리지를 높여서 end-to-end 테스팅을 최소화하는 전략이 필요한다.
서비스간에 비동기처리를 위해서 콜백 함수를 이용하게 되는데 이러한 방식의 애플리케이션 코드는 무한한 콜백을 만들어 낼 수 있으면 유지보수와 소스코드의 가독성을 현저하게 악화시키는 원인이 된다.
상호간에 서비스에서 실패가 발생할 경우 오류를 핸들링해주는 범위도 고려해야 한다.
서비스 간에 결합이 깨지지 않도록 고려해야 한다.
서비스간에 데이터 트랜잭션이 유지되도록 고려해야 한다.
서비스들 간에 오류를 추적할 수 있도록 고려해서 설계해야 한다.
서비스들 간에 자동화 과정을 고려해야 한다.
서비스별로 데이터베이스를 독립적으로 분리되도록 정의되어야 한다.
MSA 보완 사항
단점 | 보완방법 |
장애추적, 모니터링, 매지징이 어렵다. | Sleuth등과 ELK, EFK등의 서비스를 연동하여 사용하는 방안 고려 |
여러 서비스에 걸쳐져 있는 feature의 경우, 트랜잭션을 다루기 어렵다. | 보상 트랜잭션 또는 부분적으로 composite 서비스로의 병합 고려 |
여러 서비스에 걸쳐져 있는 feature의 경우, 테스팅이 복잡하다. | 테스팅 계획 및 방법에 노력 투자 |
서비스 간 dependency가 있는 경우 릴리즈가 까다롭다. | 관련 개발조직 간 roll-out 계획 마련 및 dependency의 명백한 관리 |
서비스 개수가 많고 유동적이기때문에 Continuous Integration/Delivery 및 서비스 관리 상의 문제가 발생할 수 있다. | 서비스 레지스트리, 모니터링, 개발~디플로이 자동화 기술 고려 (PaaS 고려) |
monolith로 시작한 시스템을 Microservices로 전환할 때 큰 고통이 수반될 수 있다. | B2C웹 또는 SaaS 어플리케이션은 처음부터 Microservices 및 서비스별 조직 구성 고려 |
참고
Last updated
