TIL - 20251225

juni·2025년 12월 24일

목록 보기

218/314

1225 마이크로서비스 아키텍처(MSA) 핵심 패턴 복습

MSA는 하나의 거대한 애플리케이션(모놀리식)을 기능별로 잘게 쪼개어, 독립적으로 배포하고 확장할 수 있는 작은 서비스들의 집합으로 만드는 아키텍처 스타일입니다.
핵심 목표:
- Agility (민첩성): 변경된 서비스만 독립적으로 빠르게 배포하여, 시장 변화에 신속하게 대응.
- Scalability (확장성): 트래픽이 몰리는 특정 서비스만 독립적으로 확장하여 비용 효율성 증대.
- Resilience (탄력성/회복성): 하나의 서비스 장애가 전체 시스템의 중단으로 이어지지 않도록 장애를 격리.

문제점: 클라이언트(웹/앱)가 수십 개의 마이크로서비스 주소를 모두 알고, 각 서비스의 인증 방식이나 프로토콜에 맞춰 직접 통신하는 것은 매우 복잡하고 비효율적입니다.
API 게이트웨이:
- 개념: 모든 클라이언트 요청의 단일 진입점(Single Point of Entry) 역할을 하는 서버입니다.
- 역할:
  1. 라우팅 (Routing): 클라이언트의 요청을 분석하여, 적절한 내부 마이크로서비스로 전달하는 "교통정리" 역할을 합니다.
  2. 프로토콜 변환: 외부의 HTTP 요청을 내부의 gRPC나 메시지 큐 프로토콜로 변환할 수 있습니다.
  3. 공통 기능 처리 (Cross-cutting Concerns): 인증/인가, 로깅, API 호출 횟수 제한(Rate Limiting), 캐싱 등 여러 서비스에 공통적으로 필요한 부가 기능을 한 곳에서 처리합니다.
- 대표적인 솔루션: Spring Cloud Gateway, AWS API Gateway, Nginx

문제점: MSA 환경에서는 컨테이너 기반으로 서비스가 배포되므로, 각 서비스 인스턴스의 IP 주소와 포트가 동적으로 계속 변경됩니다. A 서비스가 B 서비스를 호출해야 할 때, B 서비스의 현재 네트워크 위치를 어떻게 알 수 있을까요?
서비스 디스커버리:
- 개념: 마이크로서비스들이 서로를 동적으로 찾을 수 있도록 해주는 메커니즘입니다.
- 구성 요소:
  1. 서비스 레지스트리 (Service Registry): 모든 서비스 인스턴스들의 현재 위치 정보(IP, 포트)를 실시간으로 기록하고 있는 "주소록" 역할을 하는 서버입니다. (e.g., Netflix Eureka, Consul)
  2. 서비스 등록 (Service Registration): 각 마이크로서비스는 시작될 때, 자신의 위치 정보를 서비스 레지스트리에 "등록"합니다.
  3. 서비스 탐색 (Service Discovery): A 서비스는 B 서비스를 호출하기 전에, 먼저 서비스 레지스트리에 "B 서비스의 현재 주소가 뭐야?"라고 질의하여 최신 주소를 받아옵니다.

문제점: 수십 개의 마이크로서비스가 각각의 설정 파일(application.yml)을 가지고 있다면, 공통된 설정(DB 주소, 외부 API 키 등)을 변경해야 할 때 모든 서비스의 설정 파일을 수정하고 재배포해야 하는 "설정 지옥"에 빠지게 됩니다.
중앙 설정 서버 (Configuration Server):
- 개념: 모든 마이크로서비스의 설정 정보를 하나의 중앙 서버에서 관리하는 방식입니다.
- 동작 방식:
  1. 모든 설정 파일들을 Git 리포지토리와 같은 외부 저장소에 모아둡니다.
  2. 설정 서버는 이 Git 리포지토리와 연동되어 설정 정보들을 가지고 있습니다.
  3. 각 마이크로서비스는 시작될 때, 설정 서버에 자신의 설정 정보를 요청하여 받아옵니다.
- 장점: 설정이 변경되면, Git 리포지토리만 수정하고 설정 서버를 통해 각 서비스에 변경 사항을 전파할 수 있습니다. 애플리케이션의 재배포 없이 설정을 동적으로 변경하는 것도 가능합니다.
- 대표적인 솔루션: Spring Cloud Config

문제점 (연쇄 장애): MSA 환경에서 A 서비스가 B 서비스를 호출하고, B 서비스가 C 서비스를 호출하는 연쇄적인 의존 관계가 있을 때, 만약 C 서비스 하나에 장애가 발생하면 어떻게 될까요? B 서비스는 C를 기다리다 타임아웃되고, A 서비스도 B를 기다리다 타임아웃되어, 결국 작은 장애 하나가 전체 시스템의 장애로 번지는 "연쇄 장애(Cascading Failures)"가 발생할 수 있습니다.
서킷 브레이커:
- 개념: 전기 회로의 "차단기"처럼, 특정 서비스에 대한 호출이 반복적으로 실패하면, 더 이상의 호출을 일시적으로 차단(Open)하고 즉시 실패 응답을 반환하는 패턴입니다.
- 동작 상태:
  1. Closed (닫힘): 평소 상태. 요청을 정상적으로 전달.
  2. Open (열림): 실패 횟수가 임계치를 초과하면, 차단기가 열려 모든 요청을 즉시 실패 처리. (장애가 발생한 서비스에 부하를 주지 않음)
  3. Half-Open (반열림): 일정 시간이 지난 후, 시험적으로 하나의 요청을 보내 장애가 복구되었는지 확인. 성공하면 Closed로, 실패하면 다시 Open 상태로 전환.
- 대표적인 솔루션: Resilience4j, Netflix Hystrix(유지보수 모드)

API 게이트웨이는 마이크로서비스의 단일 진입점 역할을 하며, 라우팅과 공통 기능을 처리합니다.
서비스 디스커버리 (서비스 레지스트리)는 동적으로 변하는 서비스들의 네트워크 주소를 관리하는 "주소록"입니다.
중앙 설정 서버는 여러 서비스의 설정 정보를 Git과 같은 중앙 저장소에서 관리하여, 설정 변경을 용이하게 합니다.
서킷 브레이커는 특정 서비스의 장애가 다른 서비스로 전파되는 연쇄 장애를 방지하여 시스템의 안정성과 회복탄력성을 높이는 중요한 패턴입니다.
이러한 패턴들은 MSA의 복잡성을 관리하고, 그 장점을 극대화하기 위한 필수적인 도구들입니다.