Spring Cloud Gateway Reactive 라이프사이클

🚀 Spring Cloud Gateway Reactive 라이프사이클

— Predicate → Filter → Netty, 논블로킹 파이프라인의 정수

스프링 클라우드 게이트웨이(Spring Cloud Gateway, SCG)에서 요청이 들어와 처리되고 다시 나가는 전 과정은
Reactive(비동기 · 논블로킹) 아키텍처의 교과서라고 할 수 있습니다.

이 쳅터에서는 SCG가
👉 Predicate로 길을 찾고,
👉 Filter로 요청·응답을 가공하며,
👉 Netty로 실제 네트워크 통신을 수행하는
전체 라이프사이클을 정리해 보겠습니다. ✍️

🧭 1. 전체 흐름 한눈에 보기 (High-Level Flow)

SCG로 들어온 하나의 HTTP 요청은 아래와 같은 비동기 파이프라인을 따라 이동합니다.

Client
  ↓
Netty Server (Inbound)
  ↓
Predicate (Route 결정)
  ↓
Filter Chain (Pre)
  ↓
Netty Client (Outbound)
  ↓
Filter Chain (Post)
  ↓
Netty Server (Response)
  ↓
Client

💡 중요 포인트
SCG에는 요청을 처리하는 전용 스레드가 존재하지 않습니다.
모든 흐름은 이벤트 기반(Event-driven) 으로 이어집니다.

🚪 2. Netty – 요청의 시작점 (The Entrance)

SCG는 Tomcat 같은 서블릿 컨테이너 위에서 동작하지 않습니다.
대신 Netty 기반의 리액티브 서버로 동작합니다. ⚡

🔹 Event Loop 모델

• Netty의 Event Loop Thread가 TCP 연결을 수락
• 하나의 스레드가 수천 개의 커넥션을 관리
• 요청마다 스레드를 점유 ❌

🔹 ServerWebExchange

• HTTP 요청은 ServerWebExchange로 래핑
• 이 객체는 요청 + 응답 + 메타데이터를 모두 담는 핵심 컨텍스트 🎒
• 이후 모든 단계에서 같은 exchange 객체가 전달됨

✅ SCG의 모든 필터와 핸들러는
ServerWebExchange를 중심으로 동작합니다.

🧠 3. Predicate – 어디로 보낼 것인가? (The Decision)

요청이 수용되면, 이제 Route 선택 단계로 넘어갑니다.

🔹 RoutePredicateHandlerMapping

• 등록된 모든 Route를 순회
• 각 Route의 Predicate를 평가

🔹 Matching & Short-circuit

• Predicate 결과가 true인 첫 번째 Route 즉시 선택 🏁
• 매칭 실패 시 → 404 또는 기본 라우팅 규칙 적용

- id: order-service
  uri: lb://ORDER-SERVICE
  predicates:
    - Path=/orders/**

📌 이 시점에 결정되는 것:

• 목적지 URI (lb://ORDER-SERVICE)
• 적용될 Gateway Filter 목록

🧪 4. Filter Chain – 요청을 가공하다 (The Transformation)

선택된 Route는 이제 필터 체인(Filter Chain) 으로 들어갑니다.

🔹 Global Filter + Gateway Filter

• 모든 Global Filter
• Route에 정의된 Gateway Filter
  ➡️ 하나의 체인으로 결합

🔹 FilteringWebHandler

• 필터 체인의 실제 실행 담당자
• Reactor 체인 형태로 연결됨

🔹 Pre-Filter (Downstream)

return chain.filter(exchange);

이전 로직에서 수행되는 작업들:

• 🔐 인증 / 인가
• 🧾 요청 헤더 추가
• 🧪 요청 검증
• 📊 로깅

🔹 Filter Ordering

• @Order 값이 낮을수록 먼저 실행

• 일반적인 정석 배치 👇

  1. 보안(Security)
  2. 로깅(Logging)
  3. 트래픽 제어(RateLimit)
  4. 비즈니스 관련 필터

🌐 5. NettyRoutingFilter – 실제 호출 (The Execution)

필터 체인의 마지막 종착역에는 항상 이것이 있습니다.

🔥 NettyRoutingFilter

• SCG 내부에서 Netty Client 역할 수행
• 마이크로서비스로 HTTP 요청 전송

🔹 Non-blocking I/O

• 요청 전송 후 응답을 기다리며 블로킹 ❌
• 이벤트 루프는 즉시 반환되어 다른 요청 처리

요청 보냄 → 등록 → 응답 오면 콜백 실행

⚡ 이것이 SCG가 고성능을 내는 핵심 이유입니다.

🔄 6. Response & Post-Filter – 돌아오는 길 (The Return)

마이크로서비스에서 응답이 도착하면
필터 체인은 역순(reverse order) 으로 실행됩니다.

🔹 Post-Filter (Upstream)

chain.filter(exchange)
     .then(Mono.fromRunnable(() -> {
         // 응답 후 처리
     }));

여기서 주로 하는 작업들:

• 🧩 응답 헤더 가공
• 🔐 응답 암호화
• ⏱ 실행 시간 측정
• 📈 메트릭 수집

🔹 Final Output

• 최종 응답은 Netty Server를 통해 클라이언트로 전달 📦

🧠 7. 인사이트

❓ Netty는 왜 입구와 출구에 모두 등장할까?

SCG는 동시에 두 역할을 수행합니다.

역할	설명
Netty Server	클라이언트 요청 수신
Netty Client	백엔드 마이크로서비스 호출

➡️ 단일 이벤트 루프 모델에서 처리되므로
컨텍스트 스위칭 비용이 거의 없습니다. 🚀

⚖️ Backpressure – 폭주를 막는 안전벨트

Reactive Streams 기반 SCG는
Backpressure(배압) 를 통해 다음을 보장합니다.

• 소비자가 처리 가능한 만큼만 데이터 요청
• 대용량 Body 수정 시 메모리 폭발 방지 💣❌
• 느린 하위 서비스가 전체 게이트웨이를 망치지 않음

📌 특히 DataBuffer를 다루는 필터에서는
배압을 무시하면 OOM(Out Of Memory) 로 직행합니다.

📊 8. 전체 라이프사이클 요약표

단계	역할	핵심 컴포넌트
🚪 Netty (In)	요청 수락	HttpServer, ServerWebExchange
🧠 Predicate	Route 결정	RoutePredicateHandlerMapping
🧪 Filter (Pre)	요청 가공	GlobalFilter, GatewayFilter
🌐 Netty (Out)	서비스 호출	NettyRoutingFilter, HttpClient
🔄 Filter (Post)	응답 가공	Reactive Filter Chain

🎯 마무리

Spring Cloud Gateway는 단순한 “라우팅 도구”가 아닙니다.
그 자체로 Reactive 파이프라인 엔진이며,

Predicate → Filter → Netty
이 흐름을 정확히 이해하는 순간
SCG는 설정 파일이 아니라 아키텍처로 보이기 시작합니다. 🧩