[이론] MSA, 마이크로서비스 아키텍처

조민수·2024년 9월 6일

개발 이론

목록 보기

7/8

오늘은 기업 인프라의 핵심이자 이제는 기본적 기술이 되어버린 MSA에 대해 알아보고자 한다.
개발자 직무 면접에서도 빈번히 등장하며, MSA를 심도깊게 다뤄보진 못했더라도
모든 개발자들이 얕게나마 거쳐갔기 때문이다. (나 포함)

MSA란?

독립적인 작은 서비스들의 집합으로 구성된 애플리케이션 구조이다.
가트너 하이프 사이클에 따르면, 거품기, 침체기를 넘어 성장기에 도달한 구조로,
기존의 모놀리식 아키텍처(Monolithic Architecture)를 대안하는 구조이다.
개발, 배포가 독립적으로 가능하며 각 기능(서비스)에 따라 다른 Framework, Language를 사용해 최적화한 개발 방법을 사용할 수 있다.

모놀리식 아키텍처? Monolithic Architecture?

MSA이전 기존의 애플리케이션 구조 방식
하나의 프로젝트에 모든 기능을 함께 포함해, 사이즈가 커질 수록 복잡성이 증가하는 단점이 있다.
초기 개발이 빠르고, Prototype이 빠르게 나온다는 장점이 있지만, 일부 기능의 수정에
전체 프로그램의 재설정, 재설치가 필요한 번거로움이 있다.
또한 전체 프로그램을 하나의 Framework, Language에 의존해 종속된다는 특성도 가진다.

MSA의 특징

MSA는 API를 통해 상호작용한다. 각 독립적인 서비스의 접근접을 API 형태로 구성하고,
내부 기능들을 추상화해 외부로부터 hidden한다.
서비스 간 독립성으로 인해 높은 확장성, 유연성을 가지며
이로 인해, 특정 서비스의 에러에도 전체 시스템이 크게 영향을 받지 않는다.
또한 각 서비스를 독립적으로 배포할 수 있어, 지속적 배포 CD도 가볍게 진행할 수 있다.
하지만, 소규모 서비스가 많아져 각 서비스 간 연결 구축 및 관리가 복잡해지고,
초기 개발 및 통신 등에 시간 소요가 높아진다.
또한 테스팅 단계에서 필수적인 Integration Test, 통합 테스트가 어렵고
하나의 서비스에 대한 재배포에서 각 서비스들과 정상적 연계를 늘 확인해야한다.

어떻게 MSA를 접근해야하는가

LG CNS에 따르면 2가지를 MSA 성공의 핵심 요소로 고려해야한다고 한다.

1. 서비스 쪼개기

기업이 목표로하는 시스템을 위해 서비스의 크기를 결정하고 검증하는 과정.

목표 설정 → 서비스 분리 → 평가 검증 → 서비스 설계 의 4단계로 구성된다.
목표 설정 단계에선, MSA 도입의 본질을 고민한다.
비즈니스의 빠른 변화 vs 서비스 독립성 우선 확보 가 그 본질이다.
이를 거친 후, 어떤 기준, 어떤 수준으로 서비스를 쪼갤지에 대한 의논이 진행된다.

이후 워크숍 형태의 이벤트 스토밍을 거쳐 적합한 크기로 서비스를 추출한 후
스토리텔링을 통해 후보 서비스를 골라낸다.
이때, 신규로 추가되거나, 변경이 잦은 업무를 별도 서비스로 분리하고,
부하, 장애 등의 이유로 최우선으로 독립성을 확보해야 하는 서비스를 식별한다.

해당 단게를 거치면 서비스 간 관계를 도식화한다.
서비스 간 통합, 분리의 재정의 및 특정 서비스 중심의 API, Pub/Sub 등 통신 방식 적용 등이 수행된다.

2. 서비스 아키텍처 설계

이젠, 마이크로서비스가 독립성을 가질 수 있게 아키텍처를 정의, 구상하는 작업이 요구된다.

이때, 매우 중요한 개념이 API 우선 설계(API First Design) 이다.
이는 모든 개발 프로세스에서 API를 첫 번째 우선순위로 두어 개별 서비스의 내부 설계 이전
API를 우선 정의함을 통해 마이크로서비스 간 원활한 호출, 독립적 작동을 보장하는 것이다.

서비스 간 API, Pub/Sub, 데이터 인터페이스를 먼저 정의하는 것이 중요하다는 것이다.

하지만, MSA에 API 우선 설계를 적용하려면 몇 가지 문제에 직면하는데,
그 중 대표적인 것이 여러 서비스를 포괄하는 조회성 업무이다.
한 화면에서 다양한 서비스의 데이터를 보여준다면, Client의 호출이 잦아지고
데이터 조합 작업을 인한 성능 하락을 야기하기 때문이다.

이를 해결하기 위해 API Composition, CQRS 패턴을 활용할 수 있다.
Server Side에선 API Composition으로 다수의 서비스를 호출하고,
해당 데이터를 Client로 제공해 처리 시간 단축과 성능 개선의 이점을 갖는 것이다.

For Me,

이젠, 내가 MSA를 어떻게 접해왔는 지 확인해보자
대표적으로 COCO 서비스는 MSA를 기반으로 설계되었다.

완벽한 MSA는 아니지만, 핵심 기능들을 따로 분리해 설계, 개발되었다.
특히 게시판 기능, 유저 개인정보 등 단순한 Client의 요청은
React → FastAPI ↔ MySQL 간 통신으로 구현했지만,
핵심이되는 문제 풀이 및 채점 기능은
React → FastAPI의 API Composition ↔ isolate & redis의 과정으로 구현되었다.
외에도 AI 관련 기능을 서비스로 따로 개발해 FastAPI위에서 API Composition 방식으로 구현했다.