마이크로서비스 아키텍처

마이크로서비스란

마이크로서비스 아키텍처(MSA)는 하나의 큰 애플리케이션을 비즈니스 기능 단위의 작은 서비스 여러 개로 나누는 구조다. 각 서비스는 독립된 프로세스로 돌고, 자기 데이터를 갖고, 따로 빌드·배포·확장된다. 서비스끼리는 네트워크(REST, gRPC, 메시지 브로커)로 대화한다.

여러 아키텍처 패턴 중 MSA의 위치는 소프트웨어 아키텍처 패턴에 있다.

전형적인 구조

flowchart TB
  client["클라이언트"] --> cdn["CDN<br/>정적 콘텐츠는 여기서 끝난다"]
  client --> lb["로드 밸런서"] --> gw["API 게이트웨이"]
  gw --> idp["인증 서버(Identity Provider)"]
  gw --> reg["서비스 레지스트리(어디에 무엇이 떠 있나)"]
  subgraph svcs["도메인별로 나뉜 서비스 (서비스마다 자기 DB)"]
    order["주문 서비스<br/>+ DB"]
    pay["결제 서비스<br/>+ DB"]
    prod["상품 서비스<br/>+ DB"]
  end
  gw --> svcs
  order & pay & prod ---|"비동기 통신"| mb["메시지 브로커(Kafka, RabbitMQ)"]
  subgraph ops["관리 영역"]
    metrics["메트릭(Prometheus → Grafana)"]
    logs["로그(수집 → 저장 → 검색·시각화)"]
    cache["분산 캐시"]
  end

운영에 필요한 구성 요소

인증을 게이트웨이에서 할지 각 서비스에서 할지는 인증·인가 로직은 어디에 두나, 서비스 디스커버리와 서킷 브레이커는 대규모 트래픽에서 서비스를 지키는 설계에 있다.

설계·개발 원칙

서비스 협업: 오케스트레이션과 코레오그래피

여러 서비스가 하나의 업무(주문 → 결제 → 배송)를 함께 처리하는 방식은 두 가지다.

오케스트레이션 (중앙이 순서를 호출)

flowchart TB
  o["오케스트레이터"] --> a["주문"]
  o --> b["결제"]
  o --> c["배송"]

코레오그래피 (각자 규칙에 따라 반응)

flowchart LR
  order["주문"] -->|"이벤트"| pay["결제"]
  order -->|"이벤트"| ship["배송"]
  pay --> ship

워크플로 엔진(Netflix Conductor, Temporal 등)이 오케스트레이터 역할을 한다. 이벤트 기반 협업은 웹 확장성의 구성 요소의 이벤트 기반 아키텍처와 같은 생각이다.

패턴 언어로 본 설계 결정

마이크로서비스를 고르면 따라오는 결정들은 「문제 → 해법 → 대가」 모양의 패턴으로 정리되어 있다(microservices.io의 패턴 언어). 결정마다 선택지가 둘 이상이다.

어떻게 나누나

둘 다 기술 계층(UI·DB)이 아니라 업무로 나눈다. 경계를 찾는 출발점은 조직 구조와 핵심 도메인 객체다.

데이터를 어떻게 두나

「서비스별 DB」가 서버를 서비스마다 하나씩 띄우라는 뜻은 아니다. 관계형 DB라면 비용이 낮은 순서로 서비스 전용 테이블 → 서비스 전용 스키마 → 서비스 전용 DB 서버를 고른다. 어느 쪽이든 서비스마다 다른 DB 계정과 권한(grant)을 줘서 남의 테이블을 직접 읽지 못하게 막는다. 막지 않으면 결국 누군가 API를 우회한다.

서로를 어떻게 찾나

인스턴스는 자동 확장·재배포로 IP가 계속 바뀐다. 그래서 서비스 레지스트리(인스턴스 주소 목록)를 두고 호출 때 찾는다.

레지스트리에 등록하는 방법도 둘이다. 인스턴스가 시작·종료 때 스스로 등록·해제하고 하트비트를 보내는 자기 등록, 배포 플랫폼이 대신 등록하는 서드파티 등록이다. 쿠버네티스는 플랫폼이 등록하고 DNS로 찾게 해서, 대부분 별도 레지스트리 없이 서버 측 발견을 쓴다.

컨테이너가 동적 포트로 뜨고 지는 환경에서 이 구조는 역할 셋으로 나뉜다. 등록(무엇이 어디에 떴나 알린다), 레지스트리(주소를 저장하고 변경을 알린다), 소비(주소를 읽어 설정이나 호출에 반영한다).

컨테이너 시작 ─▶ registrator ─▶ etcd/Consul ─▶ confd ─▶ nginx.conf 다시 쓰고 reload
               (Docker 이벤트    /services/web/web_1     (키 감시 →
                감시, 공개 포트)  = 172.17.8.101:49155     템플릿 렌더링)
 
# confd 템플릿: 서비스마다 upstream 블록을 만든다
{{ range $dir := lsdir "/services" }}
upstream backend_{{ base $dir }} {
  {{ range getvs (printf "/services/%s/*" $dir) }} server {{ . }}; {{ end }}
}
{{ end }}

컨테이너를 띄우기만 하면 프록시의 upstream이 무중단으로 갱신된다. 키에 TTL을 걸면 죽은 컨테이너의 항목이 저절로 사라진다. confd는 마지막 릴리스가 v0.16.0(2018)으로 사실상 멈췄고, 같은 일은 쿠버네티스 Service·EndpointSlice와 Ingress 컨트롤러, Consul의 consul-template, Traefik·Caddy의 동적 설정 공급자가 한다.

Consul은 서비스 디스커버리, 헬스 체크(장애 감지), KV 저장소, 멀티 데이터센터를 한 도구로 준다. 서버 에이전트 몇 대가 Raft로 상태를 지키고(첫 구성은 -bootstrap-expect=3처럼 기대 서버 수를 주면 그만큼 모였을 때 리더를 뽑는다. 단독 -bootstrap은 옛 방식이다), 각 노드의 클라이언트 에이전트가 붙는다. 조회는 두 길이다.

HTTP  GET /v1/health/service/database?passing      건강한 인스턴스만
DNS   dig @127.0.0.1 -p 8600 database.service.consul
      mysql.database.service.dc1.consul               태그.서비스.service.데이터센터

서비스 정의는 {"service": {"name": "database", "tags": ["mysql"], "port": 5000, "check": {"args": ["/bin/check_mysql"], "interval": "10s"}}} 모양이다. 스크립트 체크는 원격 실행 위험이 있어 에이전트에 enable_local_script_checks(설정 파일에 정의한 체크만 허용, 권장)나 enable_script_checks를 켜야 동작한다.

클라이언트 라이브러리 대신 호스트마다 로컬 프록시를 두고 디스커버리 결과로 그 설정을 갱신하는 방식(AirBnB SmartStack: 로컬 HAProxy 설정을 바꾸는 synapse와 등록을 맡는 nerve, 고정 주소로 상대를 가리키는 앰배서더 컨테이너)은 오늘날 서비스 메시 사이드카의 조상이다.

공통 관심사를 어떻게 처리하나

어디에 배포하나

마이크로서비스의 공통 특성

마이크로서비스라는 이름이 정착할 때 정리된 공통 특성 가운데, 위 원칙 표에 없는 것들이다.

SOA·ESB와 무엇이 다른가

서비스 지향 아키텍처(SOA) 와 마이크로서비스는 둘 다 시스템을 서비스로 나누지만 범위와 목적이 다르다. SOA는 전사 시스템의 기능을 공통 통신 표준(SOAP·WSDL 등)의 서비스 인터페이스로 열어 재사용을 극대화하려 한다. 마이크로서비스는 팀이 혼자 배포할 수 있는 가장 작은 단위로 나눠 팀의 자율성과 분리를 노린다.

기업 안의 서로 다른 플랫폼·애플리케이션을 연계하는 일을 EAI(Enterprise Application Integration) 라 부르고, 연결 토폴로지로 네 유형을 구분한다. ESB는 이 가운데 메시지 버스형의 대표다.

SOA를 받치던 것이 엔터프라이즈 서비스 버스(ESB) 다. 애플리케이션 사이의 통합을 중앙 소프트웨어 하나가 맡는 패턴으로, 데이터 모델 변환, 연결 관리, 메시지 라우팅, 프로토콜 변환, 여러 요청의 조합까지 한다. 이 통합을 서비스 인터페이스로 열어 새 애플리케이션이 다시 쓰게 한다.

그래서 마이크로서비스는 「똑똑한 끝점, 단순한 파이프」를 택한다(위 표). 변환·라우팅 로직은 서비스 안에 두고, 통신 인프라는 가벼운 메시지 브로커(RabbitMQ, Kafka)로 메시지를 나르기만 한다. 브로커가 ESB의 서비스 간 통신 기능을 더 싸게 대신한다(메시지 큐와 Kafka). API 게이트웨이에 오케스트레이션을 넣지 말라는 이유도 같다(API 게이트웨이).

도메인 단위로 묶기: DOMA

서비스가 수천 개로 늘면 의존 관계가 깊어지고, 하위 서비스의 지연이 위로 연쇄 전파되고, 기능 하나를 바꾸려 여러 서비스를 함께 고쳐 배포해야 한다. 서로 독립적으로 보이지만 함께 배포해야 하는 상태를 분산 모놀리스(distributed monolith) 라 한다. 마이크로서비스의 이점을 잃은 상태다.

다음 중 하나라도 맞으면 분산 모놀리스를 의심한다.

• 서비스끼리 저지연의 잦은 동기 호출이 필요하다(요청 하나에 내부 호출이 줄줄이 붙는다).
• 서비스 하나만 따로 늘릴 수 없다.
• 서비스 사이 의존이 많아 하나를 고치면 여러 서비스를 같이 배포한다.
• 같은 DB 같은 자원을 공유한다.

마이크로서비스를 처음 도입할 때 흔한 함정은 이렇다. 서비스 경계를 비즈니스 도메인이 아니라 기술 계층으로 나누기, 분산 시스템의 어려움을 얕보기, 공유 DB와 공통 의존성, 서비스마다 소유자가 불분명한 것, 재시도를 하면서 멱등성을 빠뜨리기(복원력 패턴), 모든 것을 ACID 트랜잭션으로 묶으려 하기(서비스 사이에는 최종 일관성과 사가, 분산 트랜잭션), 장애 격리 설계가 없어 연쇄 장애를 맞기다. API를 바꿀 때는 하위 호환을 지켜야 서비스가 따로 배포된다.

도메인 지향 마이크로서비스 아키텍처(DOMA) 는 개별 서비스 대신 관련 서비스 묶음(도메인) 을 설계 단위로 삼아 이를 다룬다.

도메인은 다른 도메인의 로직이나 데이터 모델을 안에 하드코딩하지 않는다. 이런 구조는 한 번의 전면 재설계보다 작은 방향 조정을 꾸준히 반복해서 옮겨 간다.

모듈러 모놀리스: 나누기 전 단계

조직과 트래픽이 독립 배포를 요구하기 전에는 배포 단위는 하나로 두되 모듈 경계를 엄격히 나눈 모놀리스가 대개 더 싸다. 단순한 배포·운영과 로컬 트랜잭션을 유지하면서, 나중에 서비스로 떼어 낼 경계를 미리 만든다.

모듈 안은 포트와 어댑터 스타일로 짠다. 유스케이스와 리포지토리 인터페이스는 코어에, 구현은 바깥에 둔다(소프트웨어 아키텍처 패턴). 모듈 경계는 말로만 지키면 무너지므로 아키텍처 테스트나 모듈 검증 도구(Spring Modulith, ArchUnit 등)로 강제한다. 모듈 사이 후속 처리를 이벤트로 넘겨 두면 서비스로 떼어 낼 때 그대로 메시지로 바꿀 수 있다(이벤트 기반 아키텍처 설계).

나눌 때가 됐다는 신호

다음 증상이 여럿 겹치면 서비스 분리를 검토할 때다. 하나둘이면 모듈 경계를 다듬는 것으로 충분한 경우가 많다.

• 배포 한 번이 오래 걸리고, 작은 수정에도 전체 회귀 테스트가 필요하다.
• 한 곳의 버그 수정이 엉뚱한 곳의 더 큰 버그를 만든다.
• 팀이 늘어 같은 코드베이스에서 배포 일정과 변경이 서로 막힌다.
• 기능별로 부하 특성이 달라(한 기능만 트래픽이 몰림) 따로 확장하고 싶다.

마이크로서비스가 맞지 않는 곳

MSA는 특정 문제를 풀려고 나온 구조이지 기본값이 아니다. 다음 성질을 가진 시스템은 모놀리스가 낫다.

사례: 분산 구조를 한 프로세스로 합치기

실시간 영상 스트림의 품질을 감시하는 파이프라인(미디어 변환 → 결함 탐지 → 알림)이 서버리스 함수와 워크플로 서비스로 짜여 있던 사례(Amazon Prime Video)가 있다. 비용이 컸던 곳은 두 군데였다.

• 상태 전이마다 과금되는 오케스트레이션: 초당 여러 번 상태가 바뀌었다.
• 단계 사이의 데이터 전달: 중간 프레임을 객체 스토리지에 올렸다 내려받았다.

변환기와 탐지기를 한 프로세스에 넣자 데이터가 메모리 안에서 넘어가고 오케스트레이션 비용이 사라져 인프라 비용이 크게 줄었다. 교훈은 분해에도 비용이 있다는 것과 아키텍처는 상황에 따라 다시 검토하는 전략이지 신념이 아니다라는 것이다. 서버리스를 먼저 시도하는 것(serverless first)과 서버리스만 고집하는 것(serverless only)은 다르다.

정리

• MSA는 기능 단위의 작은 서비스가 자기 데이터와 배포를 갖는 구조다. 독립 확장·배포를 얻는 대신 네트워크 비용과 운영 복잡도를 치른다.
• 게이트웨이, 레지스트리, 인증 서버, 메시징, 메트릭·로그 수집이 사실상 필수 구성 요소다.
• 실패를 전제로 설계하고, 데이터는 서비스가 소유하고, 서비스는 상태 없이 만든다.
• 협업은 중앙이 흐름을 쥐는 오케스트레이션과 이벤트로 반응하는 코레오그래피 중에서 신뢰성과 결합도를 보고 고른다.
• 지연·메모리 상태·대용량 단계 간 전달이 핵심인 시스템은 모놀리스가 낫다. 왜 나누는지 먼저 묻는다.
• 서비스가 많아지면 도메인·계층·게이트웨이로 묶어 분산 모놀리스를 피하고, 나누기 전에는 모듈러 모놀리스로 경계를 먼저 만든다.

더 읽을거리: 「Mastering Chaos - A Netflix Guide to Microservices」(QCon 영상), 「우아한 모노리스」(우아한테크 영상)

관련 노트: 이벤트 기반 아키텍처 설계, 소프트웨어 아키텍처 패턴, 도메인 주도 설계, 웹 확장성의 구성 요소, 대규모 트래픽에서 서비스를 지키는 설계, 인증·인가 로직은 어디에 두나, BFF (Backend For Frontend)