소프트웨어 아키텍처 101

소프트웨어 아키텍처 101, 한빛미디어

API 게이트웨이(Gateway)와 서비스 디스커버리(Service Discovery)는 어떤 관계일까요?

실무에서 많이 사용하고 있는 개념이지만, 막상 구조적으로 연결해서 설명하려고 하면 헷갈릴 수 있습니다.

1. API 게이트웨이

API 게이트웨이는 외부의 요청이 유입되는 관문 역할을 수행하며 대표적인 구현체로는 다음과 같은 것들이 있습니다.

  • Spring Cloud Gateway
  • Netflix Zuul
  • Kong

“요청을 어디로 보낼지 결정”하는 것이 핵심 기능으로 다음의 기능들도 포함하고 있습니다.

  • 인증/인가
  • 라우팅
  • 로깅
  • Rate Limit
  • 공통 필터 처리

2. 서비스 디스커버리

반면, 서비스 디스커버리의 핵심 기능은 “요청을 처리할 서비스가 어디에 있는지 알려주는 것”입니다.

대표적인 구현체로는 다음이 있습니다.

  • Netflix Eureka
  • Consul
  • Kubernetes (내장 Service 기반)

마이크로서비스 아키텍처(MSA)에서는 각 서비스가 동적으로 생성·종료·스케일링 됩니다.

예를 들어 아래와 같은 서비스들이 각각 여러 인스턴스로 실행되고 있고, IP와 포트가 계속 바뀐다면 어떻게 서로를 찾을까요?

  • 주문 서비스(Order Service)
  • 결제 서비스(Payment Service)
  • 사용자 서비스(User Service)

바로 이 문제를 해결하는 것이 서비스 디스커버리입니다.

3. API 게이트웨이와 서비스 디스커버리의 연결

API 게이트웨이도 결국 내부 서비스를 호출해야 합니다. 그렇다면 내부 서비스의 위치를 어떻게 알까요?

바로 이 지점에서 서비스 디스커버리가 개입하게 됩니다.

[클라이언트]
    │
    ▼
[API 게이트웨이]
    │
    │ 1. user-service 어디 있지?
    ▼
[서비스 디스커버리]
    │
    │ 2. 인스턴스 목록 반환
    ▼
[게이트웨이 내부 Load Balancer]
    │
    ▼
[user-service 인스턴스]

즉,

  • 서비스 디스커버리 → 위치 정보 제공
  • API 게이트웨이 → 그 정보를 이용해 라우팅

API 게이트웨이는 서비스 디스커버리의 “클라이언트”가 됩니다.

4. 내부 서비스 간 호출

여기서 한 가지 중요한 질문이 생깁니다. 내부 서비스들끼리는 서로를 어떻게 호출할까요?

대표적으로 두 가지 패턴이 있습니다.

패턴 1. 게이트웨이 중심 구조

Service A → 게이트웨이 → Service B
  • 모든 트래픽을 중앙에서 통제
  • 추적 및 정책 적용이 쉬움
  • Gateway 부하 증가 가능성

패턴 2. 내부 직접 호출 + 디스커버리 사용

Service A → 디스커버리 → Service B
  • 진정한 의미의 분산 구조
  • 서비스 간 의존성 증가
  • 네트워크 흐름 복잡

5. 정리

사실 IP가 자주 변하지 않거나 오토스케일링이 활발하지는 않다면, 서비스 디스커버리가 반드시 필요한 것은 아닐 수 있습니다.

하지만 반대의 경우라면 서비스 디스커버리를 사용해서 운영 안정성을 크게 높일 수 있습니다.

컴포넌트 질문 역할
Service Discovery “서비스 어디 있지?” 위치 관리
API Gateway “요청 어디로 보내지?” 라우팅
관계 Gateway가 Discovery를 사용 의존 관계

6. 포스팅 시리즈

#소프트웨어아키텍처101 #한빛미디어 #소프트웨어 #아키텍처 #마이크로서비스 #MSA #API #게이트웨이 #서비스디스커버리