MSA(Microservices Architecture)란 무엇인가?

최근 많은 IT 기업들이 “MSA(Microservices Architecture)”를 도입하고 있다.
Netflix, Amazon, 카카오, 네이버 등 대규모 서비스를 운영하는 기업들은 이미 오래전부터 MSA를 통해 유연하고 확장 가능한 시스템을 구축해 왔다.

그렇다면 MSA란 정확히 무엇이고,
그리고 왜 많은 개발자와 기업이 MSA를 선택하는가?

MSA(Microservices Architecture)란, 하나의 거대한 애플리케이션을,

여러 개의 작은 독립적인 서비스 단위(Microservice)로 나누어 개발하고 운영하는 아키텍처이다.

“한 덩어리로 되어 있던 시스템을 작게 쪼개서, 각각 독립적으로 실행되게 하는 구조”
라고 이해할 수 있다.

기존의 Monolithic Architecture(모놀리식 구조)에서는 모든 기능(로그인, 결제, 게시판, 알림 등)이 하나의 서버 코드 안에 들어있다.
이 경우 일부 기능을 수정해도 전체 애플리케이션을 다시 빌드하고 배포해야 한다.

Notification(알림 서비스)
등이 각각 독립된 서버로 분리되어 있다.
따라서 하나의 서비스만 수정해도 다른 서비스에는 영향을 주지 않는다.

1. 독립 배포 (Independent Deployment)

각 서비스는 개별적으로 빌드, 테스트, 배포할 수 있습니다.
예를 들어 로그인 서비스에 문제가 생겨도, 결제 서비스는 정상적으로 작동한다.

2. 기술 스택의 다양성 (Polyglot Architecture)

각 마이크로서비스는 서로 다른 언어나 프레임워크를 사용할 수 있다.
예: Auth는 Node.js, Payment는 Spring Boot로 구현 가능.

3. 자율적인 팀 운영 (Decentralized Team)

MSA는 서비스별로 담당 팀이 나뉘어 있어, 각 팀이 빠르게 의사결정하고 독립적으로 배포할 수 있다.

트래픽이 몰리는 서비스만 따로 수평 확장(Scale-out) 할 수 있다.
예를 들어, Payment 서비스에만 서버를 늘리는 것이 가능하다.

서비스 간 의존성 감소로 유지보수가 쉬움

부분 장애 격리 가능 (한 서비스가 죽어도 전체가 멈추지 않음)

빠른 배포 및 지속적 통합(CI/CD) 에 유리

서비스 간 통신이 HTTP 기반이라 네트워크 오버헤드 발생

데이터 일관성 관리가 어려움 (서비스별 DB 분리)

트랜잭션 관리 복잡 (분산 트랜잭션 or 보상 트랜잭션 필요)

서비스가 많아질수록 운영 및 모니터링 부담 증가

다음은 직접 작성한 MSA 구조도의 예시이다

보다시피, MSA구조를 이해하려면 Kubernetes와 Docker에 대해서 필수적으로 알아야 한다.

각 노드는 다수의 POD를 포함하고 있으며, POD끼리는 HTTP/gRPC 프로토콜을 통해 통신한다.

각 노드에 포함된 POD들은 각각 다른 독자적인 Database로 연결되며, 중앙화된 데이터베이스 사용은 하지 않는다. 

(단, In-memory DB의 경우, 특정 경우에 있어서 중앙화된 단일 시스템을 사용하는 경우도 존재. 예)각 POD별로 산재된 Session 관리)

일례로, 이 글을 작성한 본인은 혼자서, 초기 서비스의 백엔드를 MSA로 구축한 적이 있는데,

설계 및 개발 소요 기간은 일반 Monolithic 구조로 구축하는 것에 비해서 수배 이상 들었으며, 불필요한 통신 비용으로 인해 프로그램의 복잡도는 더욱 증가 되었다.

트랜잭션 관리의 경우에도, Monolithic 구조에서는 트랜잭션을 걸고, 로직 실패시 roll back 해주면 해결 되었으나,

MSA에서는 단일 DB를 사용하지 않으므로, 각 비즈니스 로직의 실패 단계에서 보상 로직을 작성 해 주어야한다.

(이 부분은 Orchestrator와 같은 패턴을 사용하여 작성 가능하다.)

개인적인 경험으로는 MSA 구조는, 소규모 팀 혹은 개인이 채택하는것을 추천하지 않는다.

그렇다면 MSA가 필요한 시점은 언제인가?

모든 프로젝트가 MSA를 도입해야 하는 것은 아니다.
다음과 같은 상황이라면 MSA가 효과적일 수 있다.

트래픽이 많은 대규모 서비스 운영 중

기능이 많고 팀이 여러 개로 분리된 경우

서비스별로 배포 주기가 달라야 할 때

클라우드 환경에서 자동 확장(Autoscaling) 을 적극 활용하고 싶을 때

반대로,
소규모 프로젝트나 MVP 단계의 서비스, 필자 본인이 경험했듯이 오히려 관리 복잡도가 증가할 수있다.
이 경우에는 모놀리식 구조로 시작하고, 규모가 커질 때 MSA로 전환하는 것이 일반적이다.

MSA(Microservice Architecture)란?

Body Parser란?

Express JS란?

Request, Response

Resposne - send(), json(), end()

컨트롤러, 라우터

HTML ELEMENT

데이터 타입

멀티 컬럼 인덱스(Multi-Column Index)

링크

링크

MSA(Microservice Architecture)란?