NGINX Gateway Fabric 1.2.0 릴리스 발표

Akash Ananthanarayanan기술 마케팅 매니저 | F5 NGINX

Mike Stefaniak수석 제품 관리자 | F5 NGINX

Kubernetes Gateway API를 준수하는 구현체인 NGINX Gateway Fabric의 최신 소식을 전해 드리게 되어 매우 기쁩니다. 최근 몇 가지 흥미로운 신규 기능과 개선 사항을 포함한 버전 1.2.0으로 업데이트했습니다. 이번 릴리스는 플랫폼의 기능을 강화하고 사용자 요구 사항을 충족하는 데 중점을 두었습니다. F5 NGINX Plus 지원을 추가하고, 수요가 가장 많은 사용 사례를 지원하도록 API 범위를 확장했습니다. 이러한 개선 사항을 통해 모든 사용자에게 더 나은 경험을 제공하고, 사용자가 목표를 더욱 효율적으로 달성할 수 있도록 지원할 수 있으리라 믿습니다.

그림 1: NGINX Gateway Fabric의 설계 및 아키텍처 개요

NGINX Gateway Fabric 1.2.0 한눈에 보기:

• NGINX Plus 지원 – 이제 NGINX Gateway Fabric는 데이터 플레인에서 NGINX Plus를 지원하여 향상된 가용성, 상세한 메트릭 및 실시간 관측성 대시보드를 제공합니다.
• BackendTLSPolicy – TLS 검증을 통해 NGINX Gateway Fabric은 백엔드 애플리케이션의 ID를 확인하여 악성 애플리케이션이 연결을 가로챌 가능성을 방지할 수 있습니다. 또한 TLS는 클러스터 내 트래픽을 암호화하여 클라이언트와 백엔드 애플리케이션 간의 안전한 통신을 보장합니다.
• URLRewrite – NGINX Gateway Fabric는 이제 Route 객체에서 URL 재작성을 지원합니다. 이 기능을 사용하면 원래 요청 URL을 손쉽게 수정하여 더 적절한 대상으로 리디렉션할 수 있습니다. 따라서 백엔드 애플리케이션의 API가 변경되더라도 클라이언트에 제공하는 API를 일관되게 유지할 수 있습니다.
• 제품 텔레메트리 – 이제 NGINX Gateway Fabric에 제품 텔레메트리가 도입되어, 사용자의 환경에서 제품이 어떻게 사용되는지 파악함으로써 인프라의 운영 효율성을 더욱 향상하는 데 도움을 드릴 수 있습니다. 또한 회의에서 이러한 인사이트를 커뮤니티와 정기적으로 공유할 계획입니다.

아래에서 새로운 기능을 자세히 살펴보겠습니다.

NGINX Gateway Fabric 1.2.0의 새로운 기능은 무엇인가요?

NGINX Plus 지원

NGINX Plus를 지원하는 NGINX Gateway Fabric 버전 1.2.0이 출시되어 사용자에게 다양한 새로운 이점을 제공합니다. 이번 업그레이드를 통해 사용자는 추가 Prometheus 메트릭, 동적 업스트림 다시 로드, NGINX Plus 대시보드 등 NGINX Plus의 고급 기능을 배포 환경에서 활용할 수 있습니다. 또한 이번 업그레이드로 사용 중인 환경에 대해 NGINX로부터 직접 지원을 받을 수도 있습니다.

추가 Prometheus 메트릭

NGINX Plus를 데이터 플레인으로 사용하면 NGINX Open Source에서 일반적으로 제공되는 메트릭과 함께 추가 고급 메트릭도 내보내집니다. 주요 메트릭으로는 HTTP 요청, 스트림, 연결 관련 메트릭 등이 있습니다. 전체 목록은 NGINX의 Prometheus 익스포터에서 제공하는 편리한 목록을 확인하세요. 단, NGINX Gateway Fabric에 익스포터가 반드시 필요한 것은 아닙니다. Prometheus 또는 Prometheus 호환 스크레이퍼를 설치하면 이러한 메트릭을 관측성 스택으로 수집하고, 아키텍처 내의 일관된 단일 계층을 사용하여 대시보드와 알림을 구축할 수 있습니다. Prometheus 메트릭은 NGINX Gateway Fabric의 HTTP 포트 9113을 통해 자동으로 제공됩니다. Pod 템플릿을 업데이트하여 기본 포트를 변경할 수도 있습니다. 간단한 설정 방법을 찾고 있다면 GitHub 페이지에서 Prometheus를 배포하고 구성하여 수집을 시작하는 방법에 대한 자세한 내용을 확인하세요. 설정을 생략하고 메트릭만 확인하려면 다음 섹션에서 설명하는 NGINX Plus 대시보드를 사용할 수도 있습니다. 클러스터에 Prometheus를 설치한 후 백그라운드에서 포트 포워딩을 실행하면 대시보드에 액세스할 수 있습니다. kubectl -n monitoring port-forward svc/prometheus-server 9090:80

그림 2: NGINX Gateway Fabric에서 허용된 연결을 보여주는 Prometheus 그래프

기본 NGINX Open Source를 데이터 플레인으로 사용하더라도 위 설정은 정상적으로 작동합니다! 하지만 NGINX Plus에서 제공하는 추가 메트릭은 확인할 수 없습니다. 클러스터의 규모와 범위가 커짐에 따라 NGINX Plus 메트릭을 활용하여 용량 계획 문제, 인시던트, 심지어 백엔드 애플리케이션 장애까지 신속하게 해결하는 방법을 살펴보는 것이 좋습니다.

동적 업스트림 다시 로드

NGINX Plus와 함께 설치할 때 NGINX Gateway Fabric에서 자동으로 활성화되는 동적 업스트림 다시 로드를 사용하면 NGINX를 다시 로드하지 않고도 NGINX Gateway Fabric에서 NGINX 구성을 업데이트할 수 있습니다. 일반적으로 NGINX를 다시 로드하면 기존 연결은 이전 워커 프로세스에서 처리하고, 새로 구성된 워커는 새 연결을 처리합니다. 기존 연결이 모두 완료되면 이전 워커가 중지되고 NGINX는 새로 구성된 워커만으로 계속 실행됩니다. 이러한 방식으로 NGINX Open Source에서도 구성 변경 사항을 원활하게 처리할 수 있습니다. 하지만 NGINX의 부하가 높을 때 이전 워커와 새 워커를 모두 유지하면 리소스 오버헤드가 발생하여 문제가 생길 수 있으며, 특히 NGINX Gateway Fabric을 최대한 적은 리소스로 실행하려는 경우 더욱 그렇습니다. NGINX Plus에서 제공하는 동적 업스트림 다시 로드는 구성 변경을 위한 API 엔드포인트를 제공합니다. 이 엔드포인트가 있으면 NGINX Gateway Fabric에서 자동으로 사용하므로, 다시 로드하는 동안 이전 워커와 새 워커를 처리하는 데 필요한 추가 리소스 오버헤드를 줄여 이 문제를 방지할 수 있습니다. NGINX Gateway Fabric을 더 자주 변경하기 시작하면 다시 로드도 더 자주 발생합니다. 현재 설치된 NGF에서 다시 로드가 얼마나 자주 또는 언제 발생하는지 확인하려면 Prometheus 메트릭 nginx_gateway_fabric_nginx_reloads_total을 확인하면 됩니다. 이 문제를 자세히 알아보려면 Nick Shadrin의 글을 여기에서 확인하세요! 다음은 Prometheus 대시보드에서 NGINX Gateway Fabric 배포 두 개가 있는 환경의 메트릭 예시입니다.

그림 3: NGINX Gateway Fabric의 총 리로드 횟수를 보여주는 Prometheus 그래프

NGINX Plus 대시보드

앞서 언급했듯이 Prometheus를 설치하거나 관측성 스택을 구축하지 않고 NGINX Plus 메트릭을 빠르게 확인하려는 경우, NGINX Plus 대시보드를 사용하면 성능 메트릭을 실시간으로 모니터링하여 장애를 해결하고 리소스 용량을 점검할 수 있습니다. 이 대시보드는 NGINX Plus에서 기본으로 제공하는 모든 메트릭을 다양한 보기로 표시하며 내부 포트를 통해 쉽게 액세스할 수 있습니다. 대시보드의 기능을 간단히 직접 살펴보려면 다음 대시보드 데모 사이트를 확인하세요: demo.nginx.com. NGINX Gateway Fabric 설치 환경에서 NGINX Plus 대시보드에 액세스하려면 포트 포워딩을 통해 로컬 머신의 포트 8765로 연결을 전달할 수 있습니다: kubectl port-forward -n nginx-gateway 8765:8765 그런 다음 원하는 브라우저를 열고 주소 표시줄에 http://localhost:8765/dashboard.html을 입력합니다.

그림 4: NGINX Plus 대시보드 개요

BackendTLSPolicy

이번 릴리스에서는 오랫동안 기다려 온 BackendTLSPolicy 지원이 추가되었습니다. BackendTLSPolicy는 NGINX Gateway Fabric과 애플리케이션 간에 암호화된 TLS 통신을 도입하여 통신 채널의 보안을 크게 강화합니다. 다음 예제에서는 신뢰할 수 있는 인증 기관(CA)을 기준으로 서버 인증서를 검증할 때 TLS 암호화 스위트 및 프로토콜과 같은 설정을 지정하여 정책을 적용하는 방법을 보여 줍니다. BackendTLSPolicy를 사용하면 NGF와 백엔드 간의 트래픽을 보호할 수 있습니다. 최소 TLS 버전과 암호화 스위트도 설정할 수 있습니다. 이를 통해 악성 애플리케이션이 연결을 가로채는 것을 방지하고 클러스터 내부의 트래픽을 암호화할 수 있습니다. 백엔드 TLS 종료를 구성하려면 먼저 사용할 CA 인증서가 포함된 ConfigMap을 생성합니다. Kubernetes 내부 인증서 관리에 대한 도움말은 이 가이드를 참조하세요.

kind: ConfigMap
apiVersion: v1
metadata:
  name: backend-cert
data:
  ca.crt: 
         < -----BEGIN CERTIFICATE-----
	   -----END CERTIFICATE-----
          >

다음으로 secure-app 서비스를 대상으로 하고 이전 단계에서 생성한 ConfigMap을 참조하는 BackendTLSPolicy를 생성합니다:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: backend-tls
spec:
  targetRef:
    group: ''
    kind: Service
    name: secure-app
    namespace: default
  tls:
    caCertRefs:
    - name: backend-cert
      group: ''
      kind: ConfigMap
    hostname: secure-app.example.com

URL 재작성

URLRewrite 필터를 사용하면 성능 저하 없이 수신 요청의 원래 URL을 수정하여 다른 URL로 리디렉션할 수 있습니다. 이 기능은 백엔드 애플리케이션에서 외부에 공개하는 API가 변경되었지만 기존 클라이언트와의 하위 호환성을 유지하려는 경우에 특히 유용합니다. 또한 이 기능을 사용하면 클라이언트에 일관된 API URL을 제공하면서 요청을 서로 다른 API URL을 사용하는 여러 애플리케이션으로 리디렉션할 수 있습니다. 이를 통해 여러 API의 기능을 결합한 ‘경험’ API를 제공하여 클라이언트의 편의성과 성능을 높일 수 있습니다. 시작하려면 NGINX Gateway Fabric용 게이트웨이를 생성해 보겠습니다. 그러면 HTTP 리스너를 정의하고 최적의 성능을 위해 포트 80을 구성할 수 있습니다.

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

HTTPRoute 리소스를 생성하고 요청 필터를 구성하여 /coffee에 대한 모든 요청을 /beans로 다시 작성해 보겠습니다. 또한 백엔드에서 처리할 수 있도록 /latte 접두사를 제거하는 /latte 엔드포인트도 제공할 수 있습니다(“/latte/126”은 “/126”이 됩니다).

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: coffee
spec:
  parentRefs:
  - name: cafe
    sectionName: http
  hostnames:
  - "cafe.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplaceFullPath
          replaceFullPath: /beans
    backendRefs:
    - name: coffee
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /latte
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: coffee
      port: 80

HTTP 재작성 기능은 클라이언트 측 엔드포인트와 해당 엔드포인트가 백엔드에 매핑되는 방식 사이의 유연성을 보장하는 데 도움이 됩니다. 또한 한 URL에서 다른 URL로 트래픽을 리디렉션할 수 있어 콘텐츠를 새 웹사이트로 이전하거나 API 트래픽을 마이그레이션할 때 특히 유용합니다. NGINX Gateway Fabric은 경로 기반 재작성을 지원하지만, 현재 경로 기반 리디렉션은 지원하지 않습니다. 알려주세요 이 기능이 사용 중인 환경에 필요하다면.

제품 원격 측정

1.2 릴리스의 일부로 피드백을 수동적으로 수집하기 위한 메커니즘인 제품 원격 분석 기능을 포함하기로 했습니다. 이 기능은 사용자의 환경에서 다양한 지표를 수집하여 24시간마다 당사의 데이터 수집 플랫폼으로 전송합니다. 개인 식별 정보(PII)는 수집하지 않으며, 수집되는 정보의 전체 목록은 여기에서 확인할 수 있습니다. 당사는 원격 분석 기능을 완전히 투명하게 공개하기 위해 최선을 다하고 있습니다. 수집하는 모든 필드를 문서화하고 코드를 통해 수집 내용을 직접 확인할 수 있도록 하며, 언제든지 이 기능을 완전히 비활성화할 수도 있습니다. 또한 수집한 통계를 바탕으로 발견한 흥미로운 내용을 커뮤니티와 함께 커뮤니티 회의에서 정기적으로 살펴볼 예정이니 꼭 참석해 주세요!

리소스

NGINX Gateway Fabric 1.2.0의 전체 변경 로그는 릴리스 노트에서 확인하세요. NGINX Plus가 포함된 Kubernetes용 NGINX Gateway Fabric을 사용해 보려면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요. 프로젝트에 참여하거나, 향후 계획을 확인하거나, NGINX Gateway Fabric의 소스 코드를 살펴보려면 GitHub의 리포지토리를 확인하세요! 커뮤니티 회의는 격주 월요일 오전 9시(태평양 표준시)/오후 5시(GMT)에 열립니다. 회의 링크, 업데이트, 안건 및 회의록은 NGINX Gateway Fabric 회의 캘린더에서 확인할 수 있습니다. 링크는 GitHub README에서도 언제든지 확인할 수 있습니다.

작성자 소개

Akash Ananthanarayanan기술 마케팅 매니저 | F5 NGINX

Akash Ananthanarayanan의 다른 블로그 게시물

Mike Stefaniak수석 제품 관리자 | F5 NGINX

Mike Stefaniak의 다른 블로그 게시물