NGINX Gateway Fabric 요청 미러링 구성 가이드

NGINX Gateway Fabric 요청 미러링 은 Kubernetes 환경에서 실제 사용자 트래픽을 복제하여 신규 서비스 검증이나 테스트를 안전하게 수행할 수 있는 기능입니다. 운영 환경에서 발생하는 트래픽을 그대로 활용할 수 있기 때문에, 별도의 테스트 시나리오 없이도 현실적인 검증이 가능하다는 장점이 있습니다.

NGINX Gateway Fabric은 Gateway API를 기반으로 다양한 트래픽 제어 기능을 제공하며, RequestMirror 기능을 통해 애플리케이션 수정 없이 요청을 다른 백엔드로 복제하여 전달할 수 있습니다. 이를 활용하면 운영 트래픽에 영향을 주지 않으면서도 신규 기능 테스트, 로그 분석, 보안 검증 등을 효과적으로 수행할 수 있습니다.

이번 포스트에서는 NGINX Gateway Fabric의 요청 미러링 설정 방법과 함께 Kubernetes 환경에서 트래픽을 복제하고 검증하는 과정을 단계별로 살펴봅니다.

목차

1. 요청 미러링이란?
2. 환경/버전 정보
3. NGINX Gateway Fabric 요청 미러링 테스트 환경 구성
4. NGINX Gateway Fabric 요청 미러링 확인
5. 결론

1. 요청 미러링 이란?

요청 미러링(Request Mirroring)은 클라이언트 요청을 원본 서비스(백엔드)로 전달하면서, 동시에 동일한 요청을 다른 백엔드로 복제하여 전달하는 기능입니다.

이를 통해 다음과 같은 활용이 가능합니다.

– 신규 버전 안전성 테스트: 실제 운영 트래픽을 바탕으로 Canary 배포 전 사전 검증 (에러율, 성능 측정)
– 데이터 분석 및 보안: 원본에 영향을 주지 않고 로그 분석 및 보안 위협 탐지 시스템으로 트래픽 복제
– 실제 환경과 동일한 부하 테스트: 가상의 더미 데이터가 아닌 실제 사용자 패턴으로 테스트 수행

특히 Kubernetes 환경에서 Gateway API의 RequestMirror 필터를 통해 별도의 애플리케이션 수정 없이 요청 미러링을 구현할 수 있습니다.

2. 환경/버전 정보

구성 요소버전
Kubernetesv1.35.3
NGINX Gateway Fabric2.4.2
Gateway APIv1.4.1 (experimental)

RequestMirror 필터 기능은 experimental 전용 기능이 아니며, standard Gateway API 구성에서도 사용 가능합니다.

3. NGINX Gateway Fabric 요청 미러링 테스트 환경 구성

트래픽이 전달될 백엔드 애플리케이션의 Deployment, Service를 구성합니다.

nginx-hello 이미지를 사용하는 coffee, tea Deployment를 구성했으며, tea의 경우 command와 args를 사용하여 디버그 모드로 동작하도록 구성했습니다.

apps.yaml
YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: coffee
spec:
  replicas: 1
  selector:
    matchLabels:
      app: coffee
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: nginxdemos/nginx-hello:plain-text
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: coffee
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: coffee
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tea
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: nginxdemos/nginx-hello:plain-text
        ports:
          - containerPort: 8080
        command: ["nginx-debug"]
        args: ["-g", "daemon off; error_log /dev/stdout debug;"]
---
apiVersion: v1
kind: Service
metadata:
  name: tea
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: tea

yaml 파일을 사용하여 클러스터에 배포하고 확인합니다.

$ kubectl apply -f apps.yaml 
deployment.apps/coffee created
service/coffee created
deployment.apps/tea created
service/tea created
$ kubectl get po,svc 
NAME                                                        READY   STATUS    RESTARTS   AGE
pod/coffee-654ddf664b-8v6sw                                 1/1     Running   0          9s
pod/tea-644548b49c-hqw47                                    1/1     Running   0          9s
NAME                                           TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE  
service/coffee                                 ClusterIP      10.97.202.43     <none>          80/TCP                        253d 
service/tea                                    ClusterIP      10.108.245.77    <none>          80/TCP                       8s

클러스터 외부의 요청을 수신하기 위한 진입점인 Gateway 리소스를 배포합니다.
80번 포트를 통해 HTTP 프로토콜 요청을 수신합니다.

gateway.yaml
YAML
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mirror-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

Gateway가 배포되면 해당 리소스의 이름으로 시작하는 Pod와 Service가 생성됩니다.
포스트의 환경에서는 MetalLB를 사용하여 LoadBalancer 타입의 Service에 IP를 할당하여 연결했습니다.

$ kubectl get gateway,po,svc
NAME                                               CLASS   ADDRESS         PROGRAMMED   AGE
gateway.gateway.networking.k8s.io/mirror-gateway   nginx   192.168.40.75   True         15s
NAME                                                        READY   STATUS    RESTARTS   AGE
pod/mirror-gateway-nginx-7455c47df4-f688d                   1/1     Running   0          15s
NAME                                           TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE  
service/mirror-gateway-nginx                   LoadBalancer   10.97.99.81      192.168.40.75   80:31680/TCP                 15s

Gateway를 통해 라우팅 할 트래픽 규칙을 정의하는 HTTPRoute 리소스를 구성합니다.

기본적으로 /coffe 경로의 요청을 coffee Service의 80번 포트로 전달하고, RequestMirror filter 설정을 통해 동일한 요청을 tea Service의 80번 포트로 전달합니다.

httproute.yaml
YAML
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mirror
spec:
  parentRefs:
  - name: mirror-gateway  # 앞서 배포한 Gateway 리소스의 이름을 입력하여 연결
    sectionName: http     # Gateway 리소스의 listeners.name 값을 입력
  hostnames:
  - "cafe.mirror.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee
      port: 80
    filters:
    - type: RequestMirror
      requestMirror:
        backendRef:
          name: tea
          port: 80

리소스를 배포하면 다음과 같이 확인할 수 있습니다.

$ kubectl apply -f httproute.yaml 
httproute.gateway.networking.k8s.io/mirror created
$ kubectl get httproutes.gateway.networking.k8s.io 
NAME     HOSTNAMES             AGE
mirror   ["cafe.mirror.com"]   93s

4. NGINX Gateway Fabric 요청 미러링 확인

구성한 HTTPRoute의 hostname과 path로 요청을 전송하여 응답을 확인합니다.

$ curl http://cafe.mirror.com/coffee
Server address: 10.0.134.33:8080
Server name: coffee-654ddf664b-8v6sw
Date: 27/Mar/2026:06:20:43 +0000
URI: /coffee
Request ID: 1b8ff054b7f056ca137b54dbd3c95182

coffee-654ddf664b-8v6sw Pod로부터 응답을 받은 것을 확인할 수 있습니다. 로그에도 요청이 기록됩니다.

$ kubectl logs coffee-654ddf664b-8v6sw | tail -n 1
10.0.134.32 - - [27/Mar/2026:06:20:43 +0000] "GET /coffee HTTP/1.1" 200 161 "-" "curl/8.5.0" "192.168.201.3"

tea Pod의 로그도 확인합니다. 미러링 설정으로 인해 동일한 요청이 전달된 것을 확인할 수 있으며, 디버그 모드로 동작하여 동일 요청의 디버그 로그를 확인할 수 있습니다.

$ kubectl logs tea-644548b49c-hqw47
......
2026/03/27 06:20:43 [debug] 7#7: *1 HTTP/1.1 200 OK
Server: nginx/1.29.1
Date: Fri, 27 Mar 2026 06:20:43 GMT
Content-Type: text/plain
Content-Length: 158
Connection: keep-alive
Expires: Fri, 27 Mar 2026 06:20:42 GMT
Cache-Control: no-cache
......
2026/03/27 06:20:43 [debug] 7#7: *1 http log handler
10.0.134.32 - - [27/Mar/2026:06:20:43 +0000] "GET /coffee HTTP/1.1" 200 158 "-" "curl/8.5.0" "192.168.201.3"
2026/03/27 06:20:43 [debug] 7#7: *1 free: 00007F96B20D6200, unused: 8
2026/03/27 06:20:43 [debug] 7#7: *1 free: 00007F96B20CBB40, unused: 2137
......

5. 결론

NGINX Gateway Fabric 요청 미러링 기능을 활용하면 애플리케이션 수정 없이 Kubernetes 환경에서 손쉽게 트래픽 복제를 구현할 수 있습니다. 이를 통해 운영 환경과 동일한 조건에서 신규 서비스 검증, 보안 분석 등 다양한 시나리오를 안전하게 수행할 수 있습니다.

특히 Gateway API 기반의 선언형 구성을 통해 유연하고 확장성 있는 트래픽 제어가 가능하며, MSA 및 Cloud-Native 환경에서 매우 유용한 기능으로 활용될 수 있습니다.
향후 Canary 배포, A/B 테스트, Observability 플랫폼 연계 등과 함께 활용하면 더욱 강력한 트래픽 전략을 구성할 수 있습니다.

NGINX Gateway Fabric의 상용 버전을 체험해 보고 싶으시다면, NGINX STORE를 통해 문의하여 무료로 NGINX One trial을 통해 NGINX Plus Gateway Fabric를 체험해 보세요.

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

* indicates required