관리 메뉴

피터의 개발이야기

[Search] 검색 미들서버 앞에 Gateway가 필요한 이유 - 검색은 검색만 잘하면 된다 본문

DevOps

[Search] 검색 미들서버 앞에 Gateway가 필요한 이유 - 검색은 검색만 잘하면 된다

기록하는 백엔드개발자 2026. 7. 23. 06:51
반응형

TL;DR

검색 미들서버(SMS)의 역할은 좋은 검색 결과를 만드는 것이다.

하지만 실제 서비스에서는 검색과 관계없는 운영 기능이 훨씬 많다.

그래서 대규모 검색 시스템은 SMS 앞단에 Gateway(Reverse Proxy) 를 두고,

요청 분산, 장애 대응, 캐시, 인증 등을 Gateway가 담당하도록 설계한다.

결국 Gateway의 존재 이유는 검색 미들서버가 검색 로직에만 집중하도록 만드는 것이다.


ㅁ 들어가며

어제 회의에서 들었던 검색미들을 위한 Gateway의 역할에 대해서 알게 되었다. 

검색 시스템을 처음 접하면서 자연스럽게 이런 생각을 하게 된다.

검색 미들서버가 요청을 받아 검색하고 결과를 돌려주면 되는 것 아닌가?

 

나 역시 처음에는 그렇게 생각했다.

하지만 실제 서비스에서는 검색보다 운영을 위한 기능이 훨씬 많이 필요하다.

예를 들어 이런 상황을 생각해 보자.

  • 검색 서버가 50대라면 어느 서버로 요청을 보낼까?
  • 특정 서버가 장애가 나면 어떻게 할까?
  • 동일한 검색어는 다시 검색해야 할까?
  • 비정상적인 요청은 어떻게 막을까?
  • 모든 요청 로그는 어디에서 관리할까?

이런 기능을 모두 검색 미들서버가 담당한다면 검색 로직과 운영 로직이 하나의 시스템 안에 뒤섞이게 된다.

 

ㅁ 검색 미들서버는 검색만 잘하면 된다

검색 미들서버(SMS)의 가장 중요한 역할은 검색이다.

즉,

  • 검색어 분석
  • 검색 정책 적용
  • 랭킹 계산
  • 검색 결과 생성

처럼 검색 품질과 직접 관련된 기능에 집중해야 한다.

 

반면 운영을 위한 기능은 성격이 전혀 다르다.

  • Load Balancing
  • Cache
  • Authentication
  • Rate Limiting
  • Retry
  • Failover
  • Logging

이 기능들은 검색 알고리즘과는 아무런 관련이 없다.

그래서 대규모 서비스는 자연스럽게 역할을 분리하게 된다.

 

 

ㅁ Gateway가 맡는 역할

검색 시스템은 보통 다음과 같이 구성된다.

Gateway는 검색과 관계없는 공통 기능을 담당한다.

Gateway의 역할 설명
요청 분산 여러 SMS에 트래픽을 균등하게 분배
장애 우회 장애가 발생한 SMS를 자동 제외
캐시 동일 요청을 재사용하여 응답 속도 향상
인증 사용자 인증 및 권한 확인
요청 제한 과도한 요청 차단
로그 수집 모든 요청과 응답 기록
Retry / Timeout 네트워크 오류 자동 처리

 

반면 SMS는 검색에만 집중한다.

SMS의 역할
검색어 분석
검색 정책 적용
랭킹 계산
검색 결과 생성

 

 

ㅁ 대표적인 Gateway 오픈소스

Gateway는 특정 제품이 아니라 역할이다.

대표적으로 다음과 같은 오픈소스가 많이 사용된다.

프로젝트 특징 적합한 환경
Envoy 고성능 L7 Proxy, 동적 라우팅, Observability Kubernetes, MSA
Apache Traffic Server HTTP Cache와 Reverse Proxy에 특화 포털, CDN, 검색 서비스
NGINX 범용 Reverse Proxy 대부분의 웹 서비스
HAProxy 초고성능 Load Balancer 금융, 대규모 트래픽

Envoy

https://gateway.envoyproxy.io/

Envoy는 CNCF 프로젝트이며 현재 클라우드 네이티브 환경에서 가장 많이 사용하는 Gateway 중 하나이다.

 

특히

  • Service Discovery
  • Retry
  • Circuit Breaker
  • Observability

기능이 뛰어나 Kubernetes 환경에서 사실상의 표준으로 자리 잡았다.

Apache Traffic Server

https://trafficserver.apache.org/

Apache Traffic Server(ATS)는 Yahoo!가 개발한 HTTP Reverse Proxy이다.

 

특히

  • HTTP Cache
  • 대규모 트래픽 처리
  • Reverse Proxy

성능이 뛰어나 CDN과 검색 서비스에서 오랫동안 활용되어 왔다.

검색 시스템에서는 인기 검색어를 캐시하여 검색 미들서버의 부하를 줄이는 데 큰 장점을 가진다.

 

 

ㅁ 왜 이렇게 분리할까?

결국 이유는 하나다.

관심사의 분리(Separation of Concerns)

 

Gateway는

  "요청을 안정적으로 전달하는 책임" 을 가진다.

Search Middleware는

  "가장 좋은 검색 결과를 만드는 책임" 을 가진다.

 

각자의 책임이 명확해질수록 시스템은 단순해지고 유지보수는 쉬워진다.

 

 

ㅁ 마무리 — 검색 시스템이 커질수록 Gateway의 가치가 커진다

검색 서비스는 규모가 커질수록 검색 알고리즘보다 운영 복잡도가 더 빠르게 증가한다.

이때 Gateway는 검색과 무관한 공통 기능을 모두 흡수하여 검색 미들서버를 단순하게 만든다.

결국 검색 미들서버는 "어떻게 요청을 받을 것인가" 를 고민하는 것이 아니라,

"어떻게 더 좋은 검색 결과를 만들 것인가" 에만 집중할 수 있게 된다.

아마 이것이 대규모 검색 시스템에서 Gateway를 두는 가장 큰 이유일 것이다.

반응형
Comments