CS

MSA

soohykim 2025. 6. 27. 14:39
728x90
반응형

✅ MSA (Microservice Architecture)

🔹 MSA 개념

  • 하나의 거대한 시스템을 → 작은 단위의 서비스들로 쪼개서 운영하는 아키텍처
  • 각 서비스는 독립적으로 배포, 운영, 확장 가능
  • 서비스 간은 API (주로 REST, gRPC, 메시지큐)로 통신

즉, '작게 나눠서 빠르게, 독립적으로 움직이는 시스템 구조'

🔹 Monolithic, 모놀리식

🔸 Monolithic 구조

  • 모든 기능이 하나의 덩어리(어플리케이션)로 통합
  • 한 번에 배포, 한 번에 실행

🔸 단점

  1. 확장성 부족
    → 결제만 트래픽이 많아도 전체 서버를 늘려야 함
  2. 배포 리스크 큼
    → 작은 수정도 전체 서비스 재배포 (중단 가능성)
  3. 개발 속도 저하
    → 팀 간 충돌 많음 (같은 코드베이스)
  4. 장애 전파
    → 하나가 죽으면 전체 영향

🔹 MSA 장점

  1. 서비스별 독립 배포 가능
  2. 장애가 서비스 단위로만 제한됨
  3. 필요한 서비스만 수평 확장
  4. 기술 스택 자유 (서비스마다 Java, Node, Python도 가능)
  5. 대규모 조직에서도 팀 단위 개발 가능

✅ MSA 개발

🔸 기술 구성 요소

API Gateway NGINX, Kong, Spring Cloud Gateway
서비스 디스커버리 Eureka, Consul
서비스 간 통신 REST, gRPC, Kafka, RabbitMQ
인증/인가 OAuth, JWT
관측/모니터링 Prometheus, Grafana, Whatap, ELK
배포/오케스트레이션 Docker + Kubernetes (K8s), ArgoCD
 

🔸 개발 방식

  • 도메인 중심으로 서비스 분리 (회원, 주문, 결제 등)
  • 각 서비스는 DB도 따로 → DB도 독립
  • API Gateway가 사용자 요청을 각 서비스로 라우팅
  • 서비스 간 통신은 API 호출 또는 메시지 큐

✅ MSA 전환 목적

  1. 레거시 시스템 한계
    • WAS + Monolithic 구조
    • 배포 시 다운타임
    • 서비스 확장 어려움
  2. 디지털 금융 환경 대응
    • 모바일 중심 서비스 급증
    • 고객 요구 빠른 대응 필요
  3. 배치 → 실시간 처리 요구 증가
    • 기존 금융은 배치가 중심 → 지금은 API 기반 실시간 요구
  4. 클라우드 전환
    • 온프레미스 → 클라우드 또는 하이브리드 환경 대응
  5. 리스크 분산
    • 서비스 장애 시 전체가 아니라, 부분만 영향

👉 실제로 신한투자증권은 디지털 전환 프로젝트로 MSA화, 클라우드 네이티브화를 진행했고, ArgoCD, Kubernetes 같은 도구가 도입됨.


 

✅ 금융권 MSA 도입 시 고려 항목

1. 트랜잭션 관리 - 기존 DB 트랜잭션은 서비스 간 동기 처리 어려움
- SAGA 패턴, 보상 트랜잭션 도입 필요
2. 데이터 일관성 - 서비스마다 DB가 독립됨
- 강한 일관성 → 최종 일관성으로 전환 필요
3. 보안 강화 필요 - 서비스 간 인증/인가 강화
- Zero Trust Network 적용
4. 장애 복구/모니터링 - 서비스 단위 장애 탐지 어려움
- 중앙화된 모니터링 시스템 필수 (ELK, Whatap)
5. 네트워크 지연 - API 호출이 많아지면 지연 발생 가능
- 비동기(MQ) 설계 병행
6. 배포 및 버전 관리 - 서비스 간 인터페이스 변경 시 호환성 문제
- 버전 관리, 블루/그린 배포 적용
7. 운영 복잡도 증가 - 서비스 수 증가 → 장애 원인 파악 어려움
- DevOps, SRE 조직 필요
 

🔍 MSA 동작 방식

  • 사용자가 앱이나 웹에서 요청하면 → API Gateway가 먼저 받음
  • 이 Gateway는 요청을 적절한 서비스로 라우팅
  • 각 서비스는 DB도 따로 갖고 있고, 독립적으로 동작
  • 서비스 간 데이터 주고받을 땐 API 호출하거나 Kafka 같은 MQ 사용
  • 서비스가 많아지니 장애 모니터링은 Prometheus, Whatap 등으로 통합 관제
  • 코드 배포는 Kubernetes와 ArgoCD로 컨테이너 단위로 자동화됨

 


"금융권에서 MSA는 단순한 트렌드가 아니라, 디지털 금융 시대에 맞춘 필수 아키텍처 전환입니다. 장애 대응력, 확장성, 그리고 민첩한 서비스 개발을 위해 기존 레거시를 클라우드 네이티브 환경으로 전환하고 있는 것입니다."

 

 

✅ MSA 아키텍처 구성 

 

1. 프론트엔드 계층

  • 웹/모바일 앱
  • API Gateway를 통해 서비스 접근

2. API Gateway

  • 인증/인가 처리
  • 라우팅
  • 로깅, 트래픽 제어, 장애 격리
  • 예: Kong, NGINX, AWS API Gateway

3. 서비스 계층 (MSA)

  • 기능별 독립 서비스
    • 고객 서비스
    • 계좌 서비스
    • 상품 서비스
    • 거래 서비스
    • 인증 서비스
  • 각 서비스는 독립된 DB 및 배포 단위
  • REST API 혹은 gRPC, GraphQL

4. 메시지 브로커 (비동기 통신)

  • Kafka, RabbitMQ
  • 이벤트 기반 아키텍처
  • 서비스 간 이벤트 전달

5. 데이터 저장소

  • 서비스별 독립 DB (Polyglot Persistence)
    • PostgreSQL, MySQL, Redis, MongoDB 등
  • Object Storage (AWS S3, MinIO)

6. 배치 / 스케줄링

  • Spring Batch, Airflow 등
  • 금융 거래 집계, 정산 처리

7. 모니터링 및 로깅

  • Prometheus, Grafana (모니터링)
  • ELK/EFK Stack (로그 수집)
  • Whatap, Datadog (애플리케이션 성능 모니터링)

8. 보안

  • OAuth2, JWT
  • API 인증/인가
  • WAF, 보안 Gateway

 

✅  MDD와 MSA 차이

  • MDD (Model-Driven Development)
    • 모델 중심 개발 방식으로, 개발 초기에 도메인 모델, UML 등 명확한 모델을 작성하고 이를 바탕으로 자동 코드 생성 또는 수동 구현을 진행하는 개발 방법론입니다.
    • 설계 모델이 개발의 기준이 되어 소프트웨어 개발의 생산성과 품질을 높이는 데 목적이 있습니다.
    • 금융 시스템은 복잡한 비즈니스 로직과 규제를 갖고 있어, 모델을 명확히 해 요구사항 변경에 유연하게 대응하고 코드 품질을 관리하는 데 유리합니다.
    • 모델 중심으로 개발해 설계 오류를 줄이고, 문서화 및 이해도를 높이는 데 강점이 있습니다.
  • MSA (Microservices Architecture)
    • 시스템을 작은 단위의 독립적인 서비스(마이크로서비스)들로 나누어 개발, 배포, 운영하는 아키텍처 스타일입니다.
    • 각 서비스는 독립적으로 배포 가능하고, 자신의 데이터베이스를 소유하며, REST API나 메시징으로 통신합니다.
    • 금융 서비스가 커지고 다양해지면서, 빠른 기능 추가와 독립적인 배포, 확장성을 위해 마이크로서비스 아키텍처가 필요합니다.
    • 장애가 한 서비스에만 국한되어 전체 시스템 영향 최소화, 서비스별 기술 스택 다양화도 가능합니다.
초점 소프트웨어 설계 모델과 자동화 도구 중심 시스템 아키텍처 분할과 서비스 독립성에 집중
주요 활동 UML, 도메인 모델링, 모델 검증, 코드 생성 등 서비스 분리, API 설계, 독립 배포, 서비스 간 통신
결과물 상세한 설계 문서, 자동 생성된 코드 독립적이고 분산된 여러 서비스 컴포넌트
확장성 모델 변경 시 코드 재생성으로 관리 서비스 단위 확장 및 개별 배포 가능
 

 

 

추가로 알아두면 좋은 점

  • 실제로는 MDD와 MSA가 대립 관계가 아니라 보완 관계인 경우가 많아요.
    • MDD로 도메인 모델과 설계를 명확히 하고, MSA로 서비스 구조를 유연하게 운영하는 식이죠.
  • ‘모델 중심’은 설계가 부실하면 의미가 없고, ‘서비스 중심’도 잘 나누지 못하면 복잡해집니다. 균형이 중요해요.

 

✅ Spring MVC의 Model이란?

✔️ 개념

  • MVC 패턴(MODEL - VIEW - CONTROLLER)에서의 'Model'
  • 프론트(화면)와 백엔드(서버) 사이의 데이터 전달자 역할
  • 컨트롤러에서 뷰(HTML, JSP 등)로 데이터를 전달할 때 사용되는 단순 데이터 컨테이너
  • 여기서 model.addAttribute()는 화면(View)에 보여줄 데이터를 담는 역할만 합니다.

✔️ 특징

  • 화면 렌더링을 위한 임시 데이터 저장소
  • 도메인 모델이나 데이터베이스와 직접적인 관련은 없음

✅ 소프트웨어 개발 방법론(MDD)에서의 Model이란?

✔️ 개념

  • 도메인 모델: 현실 세계의 비즈니스 규칙과 개념을 소프트웨어 객체로 추상화한 것
  • 데이터 구조(Entity), 비즈니스 규칙, 상태 및 행동을 포함한 ‘업무 그 자체’를 표현하는 구조
  • DB 테이블 매핑도 포함하고, 비즈니스 로직도 품습니다.

✔️ 특징

  • 업무 로직, 상태 변경, 데이터 구조가 모두 포함
  • DB와 연동되고, 트랜잭션의 주체가 됨
목적 화면(View)에 데이터 전달 비즈니스 로직 표현, 업무 상태 관리
동작 범위 HTTP 요청/응답의 생명주기 내에서만 존재 애플리케이션 전체 수명주기 내에서 상태와 로직을 담당
포함하는 기능 단순한 key-value 형태 데이터 전달 데이터 구조(Entity) + 비즈니스 로직 + 상태 관리
DB와의 관계 없음 있음 (DB 매핑, 트랜잭션 관리)
 
 

 

  • 기존의 토스 코어뱅킹 시스템은 여타 은행과 다름없이 채널계와의 통신을 위한 모놀리식 시스템으로 구성
    • Redis, Kafka 등의 모던한 기술을 사용
    • 채널계와의 통신을 위한 MCI, 대외연계를 위한 FEP, 대내 단위 시스템과의 연계를 위한 EAI 가 코어뱅킹 서버에 강하게 결합되어 있는 구조
  • AWS(Amazon Wer Services)가 등장하며 주요 환경이 온프레미스 환경에서 클라우드 환경
    • 아마존은 IaaS(Infrastructure as a Service), PaaS(Platform as a Service), SaaS(Software as a Service)를 제공
    • EC2(클라우드에서 가상 서버를 구축하고 실행할 수 있는 서비스)
  • 필요에 따라 원하는 성능과 운영체제를 사용하고 유연한 스케일링을 가능
  • 서버 인프라 관리를 위한 시간과 비용이 감축
  • 컨테이너 가상화 기술인 'Docker'와 오케스트레이션 도구(ex. 쿠버네티스)들의 발전으로 MSA가 사용되기 적절한 환경

 

 

💡 용어 정리

- MCI(Message Channel Interface) : 시스템 간의 데이터 교환을 위해 사용하는 메시지 기반 통신 인터페이스
- FEP(Front-end Processor) : 메인 시스템 앞단에서 데이터 통신을 처리하는 전처리 장치 또는 프로세서
- EAI(Enterprise Application Integration) : 조직 내 여러 이기종 애플리케이션간의 통합 및 데이터 교환을 가능하게 하는 소프트웨어 아키텍처

 

 

 

 

728x90
반응형