163. 마이크로서비스 아키텍처 (MSA, Microservices Architecture)
핵심 인사이트: 덩치가 산만해진 공룡 시스템(모놀리식)은 코드 한 줄 고치는 데 한 달이 걸리고 빌드하다 서버가 멈춘다. MSA는 이 거대한 공룡을 결제 공룡, 배송 공룡, 리뷰 공룡 등 수십 마리의 작고 날렵한 랩터(마이크로서비스)로 쪼개어, 각자 독립적으로 살아가게 만드는 혁명적인 구조다.
Ⅰ. MSA (Microservices Architecture)의 개념
소프트웨어 애플리케이션을 개발할 때, 전체 시스템을 단일 코드베이스와 단일 데이터베이스(Monolithic)로 만들지 않고, 독립적으로 배포(Deploy) 및 확장(Scale)이 가능한 여러 개의 작고 응집력 있는 서비스(Microservices)들의 조합으로 분할하여 구축하는 아키텍처 스타일입니다. Netflix, Amazon, 배달의민족 등 빅테크 기업들이 트래픽 폭주를 감당하기 위해 표준으로 채택하고 있습니다.
Ⅱ. 기존 모놀리식(Monolithic) 아키텍처와의 비교
[ 모놀리식 아키텍처 (과거) ] [ 마이크로서비스 아키텍처 (MSA) ]
┌──────── 커다란 서버 ────────┐ ┌─(API Gateway)───▼───▼────┐
│ [주문 로직] [결제 로직] │ │ [주문서버] [결제서버] [배송서버] │
│ [회원 로직] [배송 로직] │ │ ▼ ▼ ▼ │
│ ───────── API ───────── │ │ [주문DB] [결제DB] [배송DB] │
└──────────────┬──────────────┘ └───────────────────────────────┘
▼ * 각 서비스는 REST API나 메시지 큐로
[(거대한) 단일 통합 DB] 통신하며, 자기만의 DB를 가짐!
- 모놀리식은 배송 로직 하나만 수정해도 10GB짜리 거대한 통합 패키지를 재빌드하고 서버 전체를 껐다 켜야 합니다.
- MSA는 배송서버만
Docker컨테이너로 살짝 내렸다가 새 코드로 갈아 끼우면 끝입니다. 결제나 주문 서비스는 아무 영향 없이 계속 돌아갑니다.
Ⅲ. MSA의 핵심 특징 (원칙)
| 특징 | 설명 |
|---|---|
| 독립적인 배포 (Independent Deployment) | 다른 서비스와 무관하게 특정 서비스만 개별적으로 코드를 수정하고, 빌드하고, 배포할 수 있습니다. |
| 폴리글랏 (Polyglot) 아키텍처 | 서비스마다 가장 적합한 언어와 DB를 맘대로 쓸 수 있습니다. (주문은 Java+Oracle, 머신러닝 추천은 Python+MongoDB) |
| DB 분리 (Decentralized Data) | 이게 가장 중요합니다! 테이블이 외래키(FK)로 거미줄처럼 엮인 단일 DB를 쓰면 안 되고, 서비스마다 자신만의 독립된 DB를 가져야 합니다. |
| 자율적인 팀 구조 | 10명 내외의 작은 피자 2판 팀(Two-Pizza Team)이 하나의 마이크로서비스를 기획부터 개발, 운영까지 풀스택으로 책임집니다. |
Ⅳ. MSA의 치명적인 단점 (도입 시 주의점)
- 트랜잭션(분산 트랜잭션)의 악몽: 모놀리식에서는 DB에서
ROLLBACK명령어 한 줄이면 주문과 결제가 동시 취소되지만, MSA에서는 DB가 분리되어 있어 결제 취소를 위해 '보상 트랜잭션(Saga 패턴)'을 개발자가 일일이 구현해야 합니다. - 운영 복잡도 폭발: 서비스가 수십 개로 쪼개지면 네트워크 지연, 서비스 간 연쇄 장애, 에러 추적(Tracing)이 극도로 어려워지므로 쿠버네티스(Kubernetes) 같은 강력한 컨테이너 오케스트레이션 도구가 필수적입니다.
📢 섹션 요약 비유: 모놀리식은 모든 주방장이 하나의 커다란 냄비에 스프, 고기, 디저트를 다 같이 끓이는 끔찍한 주방입니다. 한 명이 소금을 잘못 치면 요리 전체를 버려야 합니다. MSA는 주방장들이 각자의 개인 냄비를 들고 요리하다가 마지막에 예쁜 접시(화면)에 모아서 내놓는 시스템입니다. 한 명의 냄비가 타버려도(장애 발생), 디저트는 정상적으로 손님에게 나갈 수 있습니다.