NGINX Gateway Fabric + Istio 통합 East-West 트래픽 라우팅 검증

본 포스트에서는 NGINX Plus 기반의 NGINX Gateway Fabric 과 Istio를 통합하여 East-West 트래픽 라우팅을 구현하고, 실제 테스트를 통해 정상 동작을 검증하는 절차를 소개합니다.
이 가이드는 Service Mesh 경계 게이트웨이 구성, Istio VirtualService 연동, 라우팅 테스트에 중점을 둡니다.

Istio와 같은 서비스 메시 환경에서 애플리케이션 간의 East-West 트래픽을 효율적으로 관리하고자 할 때, NGINX Gateway Fabric(NGF)을 활용하면 고성능의 L7 트래픽 라우팅이 가능합니다.

목차

1. NGINX Gateway Fabric 과 Istio 개요
 1-1. NGINX Gateway Fabric 이란?
 1-2. Istio Service Mesh에서의 Gateway 역할
2. NGINX Gateway Fabric 과 Istio 통합 아키텍처
 2-1. Istio IngressGateway와의 차이점
 2-2. East-West 트래픽 라우팅 구조
3. 통합 구성 단계
 3-1. NGINX Gateway Fabric 설치 및 구성
 3-2. Istio와 VirtualService 연동
4. 라우팅 시나리오 검증
 4-1. 테스트 앱 배포 및 설정
 4-2. 실제 요청을 통한 라우팅 확인
5. 마무리 및 운영 팁
 5-1. 로그 및 모니터링 구성
 5-2. 운영 환경에서의 고려사항

1. NGINX Gateway Fabric 과 Istio 개요

현대적인 마이크로서비스 환경에서 트래픽 관리는 핵심적인 도전 과제입니다. 수십 개에서 수백 개의 서비스가 상호작용하는 복잡한 환경에서 안정적이고 효율적인 통신을 보장하려면 강력한 게이트웨이와 서비스 메시 솔루션이 필요합니다. NGINX Gateway Fabric과 Istio는 각각 고유한 강점을 가지고 있으며, 이들을 통합하면 더욱 완성도 높은 아키텍처를 구축할 수 있습니다.

1-1. NGINX Gateway Fabric 이란?

NGINX Gateway Fabric은 Kubernetes Gateway API를 기반으로 한 차세대 Ingress Controller 입니다. 기존 NGINX Ingress Controller의 후속작으로, 더 유연하고 표준화된 방식으로 트래픽 라우팅을 관리할 수 있습니다.

주요 특징:

• Kubernetes Gateway API 네이티브 지원
• 고성능 NGINX 데이터 플레인 활용
• 선언적 구성을 통한 트래픽 관리
• 멀티 테넌트 환경 지원
• 프로토콜별 맞춤형 라우팅 (HTTP, HTTPS, TCP, UDP)

# Gateway Fabric의 기본 Gateway 리소스 예시
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: nginx-gateway
  namespace: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

1-2. Istio Service Mesh에서의 Gateway 역할

Istio Service Mesh는 마이크로서비스 간의 통신을 관리하고 보안, 관찰성, 트래픽 관리 기능을 제공합니다. Gateway는 서비스 메시 외부에서 내부로 들어오는 트래픽의 진입점 역할을 담당합니다.

Istio Gateway의 핵심 기능:

• 외부 트래픽의 Service Mesh 진입점 제어
• TLS 종료 및 인증서 관리
• 프로토콜 변환 및 헤더 조작
• 트래픽 정책 적용 (레이트 리미팅, 보안 정책)

# Istio Gateway 구성 예시
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "myapp.example.com"

2. NGINX Gateway Fabric 과 Istio 통합 아키텍처

두 기술을 통합할 때 가장 중요한 것은 각각의 역할을 명확히 구분하고 상호 보완적으로 활용하는 것입니다. NGINX Gateway Fabric은 외부 트래픽의 진입점 역할을 담당하며, Istio는 서비스 메시 내부의 트래픽 관리를 책임집니다. 이러한 역할 분담을 통해 높은 성능과 풍부한 기능을 동시에 확보할 수 있습니다.

통합 아키텍처에서는 NGINX의 검증된 고성능 처리 능력과 Istio의 정교한 트래픽 정책 관리 기능이 결합됩니다. 이를 통해 대용량 트래픽 처리가 필요한 환경에서도 세밀한 라우팅 제어와 보안 정책을 적용할 수 있습니다.

2-1. Istio IngressGateway와의 차이점

NGINX Gateway Fabric과 Istio IngressGateway는 각각 고유한 장점을 가지고 있으며, 통합 시 상호 보완적인 역할을 수행합니다.

통합 아키텍처의 이점:

• NGINX의 고성능 처리 능력과 Istio의 풍부한 서비스 메시 기능 결합
• 트래픽 처리는 NGINX가, 서비스 간 통신 관리는 Istio가 담당
• 단일 장애점 제거 및 부하 분산

2-2. East-West 트래픽 라우팅 구조

통합 환경에서는 North-South 트래픽(외부↔내부)과 East-West 트래픽(서비스↔서비스) 모두를 효율적으로 처리할 수 있습니다.

3. 통합 구성 단계

실제 통합 환경을 구축하는 과정은 체계적인 접근이 필요합니다. 먼저 NGINX Gateway Fabric을 설치하고 기본 Gateway를 구성한 후, Istio Service Mesh와의 연동 설정을 진행합니다. 이 과정에서 Kubernetes Gateway API의 표준화된 방식과 Istio의 VirtualService 기능을 조합하여 유연하고 강력한 라우팅 시스템을 구축할 수 있습니다.

구성 과정에서는 네임스페이스 격리, 보안 정책, 그리고 트래픽 정책을 함께 고려해야 합니다. 특히 Sidecar Proxy 주입과 mTLS 설정은 보안성을 확보하는 데 핵심적인 역할을 합니다.

Istio Service Mesh 설치가 안되어 있으면 아래 포스트를 참고하여 설치하세요.

Istio Service Mesh 를 클러스터에 배포하기

3-1. NGINX Gateway Fabric 설치 및 구성

NGINX Gateway Fabric 설치는 다음 블로그 포스트를 참고하세요.

NGINX Gateway Fabric: Helm 및 Manifest 설치

NGINX Gateway Fabric 이 NGINX Plus 기반으로 설치된 것을 확인합니다.

kubectl describe pods <nginx-gateway-pods> | grep nginx

NGINX Gateway Fabric에 Istio Service Mesh의 Sidecar Proxy가 Injection 된 것을 확인합니다.

NGINX Gateway Fabric 서비스의 Type을 확인합니다.

4. 라우팅 시나리오 검증

Kubernetes 환경에서는 트래픽 흐름을 크게 두 가지로 나눌 수 있습니다. 외부에서 클러스터로 들어오는 North-South 트래픽과 클러스터 내부 서비스 간의 East-West 트래픽입니다. 이번 포스트에서는 NGINX Gateway Fabric + Istio Service Mesh 환경에서 East-West 트래픽을 테스트하는 방법을 알아보겠습니다.

4-1. 테스트 앱 배포 및 설정

East-West 트래픽을 테스트하기 위해 먼저 클라이언트 파드를 생성합니다.

#east-west-test.yaml

apiVersion: v1
kind: Pod
metadata:
  name: east-west-client
  namespace: nginx-gateway
spec:
  containers:
  - name: client
    image: curlimages/curl
    command:
      - sleep
      - "3600"

이 YAML을 east-west-test.yaml 파일로 저장한 후 적용합니다.

kubectl apply -f east-west-test.yaml

4-2. 실제 요청을 통한 라우팅 확인

Kubernetes에서는 서비스 이름을 통해 다른 서비스에 접근할 수 있습니다. 클라이언트 파드에서 coffee 서비스로 직접 요청을 보내봅니다.

kubectl exec -it east-west-client -n nginx-gateway -- curl coffee.nginx-gateway.svc.cluster.local -v

* Host coffee.nginx-gateway.svc.cluster.local:80 was resolved.
* IPv6: (none)
* IPv4: 10.104.30.52
*   Trying 10.104.30.52:80...
* Connected to coffee.nginx-gateway.svc.cluster.local (10.104.30.52) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: coffee.nginx-gateway.svc.cluster.local
> User-Agent: curl/8.13.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< server: envoy
< date: Fri, 30 May 2025 07:57:45 GMT
< content-type: text/plain
< content-length: 155
< expires: Fri, 30 May 2025 07:57:44 GMT
< cache-control: no-cache
< x-envoy-upstream-service-time: 50
< 
Server address: 10.0.14.176:8080
Server name: coffee-676c9f8944-trwwz
Date: 30/May/2025:07:57:45 +0000
URI: /
Request ID: 01192da81c00434b4c4eda2a815bf1e8

위 결과에서 몇 가지 중요한 점을 확인할 수 있습니다:

1. Service Discovery: Kubernetes DNS를 통해 coffee.nginx-gateway.svc.cluster.local이 IP 10.104.30.52로 해석되었습니다.

1. Service Mesh 통합: 응답 헤더에 server: envoy가 포함되어 있습니다. 이는 요청이 Istio의 Envoy 프록시를 통해 라우팅되었음을 의미합니다.

1. 성공적인 라우팅: 200 OK 응답과 함께 coffee 서비스의 파드 정보(coffee-676c9f8944-trwwz)가 반환되었습니다.

5. 결론

NGINX Gateway Fabric과 Istio Service Mesh의 통합은 고성능 트래픽 처리와 풍부한 서비스 메시 기능을 동시에 제공하는 강력한 아키텍처입니다. NGINX의 검증된 성능과 Istio의 고급 트래픽 관리 기능을 결합하여 복잡한 마이크로서비스 환경에서도 안정적이고 확장 가능한 솔루션을 구축할 수 있습니다.

이 통합 아키텍처를 통해 개발팀은 더 나은 관찰성, 보안, 그리고 트래픽 제어 능력을 확보하면서도 높은 성능을 유지할 수 있습니다. 특히 대규모 트래픽을 처리해야 하는 환경에서 이러한 통합 접근법의 가치가 더욱 두드러집니다.

프로덕션 환경에 적용하기 전에는 충분한 테스트와 성능 검증을 거쳐 각 조직의 요구사항에 맞게 설정을 최적화하는 것이 중요합니다.

NGINX Gateway Fabric 혹은 Istio Service Mesh에 대해 자세히 알아보려면 NGINX STORE의 기술 블로그를 참고하세요.

NGINX STORE는 Istio 기술지원도 진행하고 있습니다. 해당 링크에 방문하여 자세한 정보를 알아보세요.