OpenShift 에서 NGINX Proxy 모델 구현하기

NGINX는 OpenShift 컨테이너 플랫폼과 함께 발표된 기술 프로그램인 OpenShift Primed의 출시에 참여하게 되었습니다. 이 협업의 첫 번째 결과물은 Kubernetes Ingress Controller 및 OpenShift Origin에서 NGINX Plus의 엔터프라이즈 지원 기능을 사용할 수 있도록 하는 것입니다.

또한 올해 말 일반 릴리스를 위해 NGINX Microservices Reference Architecture(MRA)를 계속 개발 중입니다. 일반 릴리스에 앞서 NGINX 전문 서비스 고객과 함께 MRA를 사용하여 Proxy 모델, Router Mesh 모델, Fabric 모델 등 세 가지 모델을 다양한 플랫폼에 각각 배포하고 있습니다.

최근 가장 흥미로운 배포 사례 중 하나는 컨테이너 관리를 위해 Docker 컨테이너와 Kubernetes를 사용하는 Open Source 애플리케이션 개발 플랫폼인 Red Hat의 OpenShift 플랫폼에 배포한 것입니다. 저희는 OpenShift에서 사용할 수 있게 되는 새로운 Ingress Controller 기능을 활용하기 위해 Red Hat OpenShift에 Proxy 모델을 배포하는 데 중점을 두었습니다. NGINX Plus를 OpenShift의 Ingress Controller로 활용할 수 있다는 것은 매우 흥미로운 일이며, OpenShift 애플리케이션으로 유입되는 트래픽을 관리할 수 있는 강력한 기능을 많이 제공합니다.

이름에서 알 수 있듯이 Proxy 모델은 Microservice 기반 애플리케이션을 구성하는 서비스를 실행하는 서버 앞에 Reverse Proxy 서버로 NGINX Plus를 배치합니다. Proxy 모델에서 NGINX Plus는 서비스에 대한 중앙 액세스 지점을 제공합니다.

NGINX Plus Reverse Proxy 서버는 동적 서비스 검색을 제공하며 API Gateway 역할을 할 수 있습니다. 후속 활동으로 Router Mesh 모델과 Fabric 모델도 OpenShift에 구현할 예정입니다.

목차

1. OpenShift에서 Proxy 모델 사용
2. OpenShift를 사용한 Proxy 모델의 Service Discovery
3. OpenShift에서 Proxy 모델 실행
4. NGINX 및 NGINX Plus로 Kubernetes 서비스 Expose
5. 결론

1. OpenShift 에서 Proxy 모델 사용

Proxy 모델의 기능을 통해 애플리케이션 성능, 안정성, 보안 및 확장성을 개선할 수 있습니다.

  • 비교적 간단한 애플리케이션 Proxy 설정
  • 컨테이너 기반 Microservice 애플리케이션으로 전환하기 전에 기존 OpenShift 애플리케이션의 성능 개선하기
  • Router Mesh 모델 또는 Fabric 모델로 이동하기 전에 출발점으로, 세 모델 모두 Reverse Proxy 서버 패턴을 사용하므로 Proxy 모델이 좋은 출발점이 됩니다.

그림 1은 Proxy 모델에서 NGINX Plus가 Reverse Proxy 서버에서 실행되고 웹 Frontend에 대한 포스트에서 설명한 웹 Microservices인 Pages 서비스의 여러 인스턴스를 포함하여 여러 서비스와 상호 작용하는 방식을 보여줍니다.

In the Proxy Model of the Microservices Reference Architecture from NGINX, NGINX Plus acts as a reverse proxy server and ingress controller for the microservice instances of an application

그림 1. NGINX Microservices Reference Architecture의 Proxy 모델

2. OpenShift 를 사용한 Proxy 모델의 Service Discovery

기존 OpenShift 애플리케이션으로 시작하는 경우, 애플리케이션 서버 앞에 Reverse Proxy로 NGINX Plus를 배치하고 아래에 설명된 Proxy 모델 기능을 구현하기만 하면 됩니다. 그러면 애플리케이션을 컨테이너 기반 Microservices 애플리케이션으로 전환할 수 있는 좋은 위치에 있게 됩니다.

Proxy 모델은 Microservices 인스턴스 간의 통신을 위해 구현하는 메커니즘에 구애받지 않습니다. 사용 가능한 접근 방식 중 대부분은 한 서비스에서 다른 서비스로의 DNS Round Robin 요청을 사용하는 경향이 있습니다.

각 서비스는 동적으로 확장되고 서비스 인스턴스가 애플리케이션에 임시로 존재하기 때문에 NGINX Plus는 서비스 인스턴스가 생성될 때 트래픽을 추적하고 라우팅한 다음 서비스 중단 시 Load Balancing Pool에서 제거해야 합니다.

NGINX Plus에는 Service Discovery을 지원하기 위해 특별히 설계된 여러 가지 기능이 있으며, MRA는 이러한 기능을 활용합니다. MRA의 목적을 위해 NGINX Plus에서 가장 중요한 Service Discovery 기능은 컨테이너 관리자(이 경우 Kubernetes)를 Query하여 서비스 인스턴스 정보를 가져오고 서비스로 돌아가는 경로를 제공하는 DNS Resolver 기능입니다.

NGINX Plus는 SRV 레코드 지원을 도입하여 서비스 인스턴스가 모든 IP 주소/포트 번호 조합에 존재할 수 있으며 NGINX Plus는 이를 동적으로 다시 라우팅할 수 있습니다. NGINX Plus DNS Resolver는 비동기식이기 때문에 서비스 레지스트리를 스캔하여 새로운 서비스 Endpoint를 추가하거나 Pool에서 제거할 수 있으며, NGINX의 주요 작업인 요청 처리를 차단하지 않습니다.

DNS Resolver는 구성이 가능하므로 DNS 레코드의 TTL(Time-to-Live)에 의존하여 IP 주소를 새로 고칠 시기를 알 필요가 없습니다. 실제로 Microservices 애플리케이션에서 TTL에 의존하는 것은 치명적일 수 있습니다. 대신, resolver 지시문에 유효한 매개변수를 사용하면 Resolver가 서비스 레지스트리를 스캔하는 빈도를 설정할 수 있습니다.

그림 2는 Service Discovery에 대한 포스트에서 설명한 대로 공유 서비스 레지스트리를 사용한 Service Discovery을 보여줍니다.

With client-side service discovery, the client determines the network locations of available service instances and load balances requests across them

그림 2. 공유 서비스 레지스트리를 사용한 Service Discovery

3. OpenShift 에서 Proxy 모델 실행

RedHat의 OpenShift Container-as-a-Service(CaaS) 플랫폼은 강력한 Kubernetes 기반 컨테이너 관리 시스템입니다. 따라서 NGINX MRA를 OpenShift에서 실행하기 위한 핵심 작업의 대부분은 적절한 Kubernetes YAML 파일을 생성하고 컨테이너를 배포하는 것이었습니다. 이 작업이 완료되면 Proxy 모델 아키텍처에서 작동하도록 시스템을 구성했습니다.

첫 번째 단계는 Kubernetes의 Replication Controller와 서비스 정의 파일을 생성하는 것이었습니다. MRA는 각 서비스가 다른 서비스와 독립적으로 확장될 수 있고 많은 경우에 확장되어야 하는 느슨하게 결합된 아키텍처를 사용하기 때문에 각 서비스에 대해 단일 Replication Controller와 서비스 정의를 만들었습니다. 이러한 이유로 각 Replication Controller와 서비스 정의는 별도로 생성되었습니다. (관리의 용이성을 위해 두 파일을 하나의 파일로 결합했습니다.)

apiVersion: v1
kind: ReplicationController
metadata:
  name: auth-proxy
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: auth-proxy
    spec:
      containers:
      - name: auth-proxy
        image: ngrefarch/auth-proxy:openshift
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: auth-proxy
  labels:
    app: auth-proxy
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: auth-proxy

가장 간단한 형식의 사양에는 애플리케이션 이름, 인스턴스 수, Docker 이미지의 위치, auth-proxy 서비스에 필요하고 제공하는 포트, 프로토콜, 서비스 유형이 명시되어 있습니다.

OpenShift가 제공하는 편리함 중 하나는 Private Repo에 있는 Docker 이미지에 액세스할 수 있는 메커니즘입니다. oc secrets 명령을 사용하여 원격 Repository에서 이미지를 가져오는 데 필요한 자격 증명과 계정 정보를 OpenShift에 알려줄 수 있었습니다.

Docker 구성을 Secret으로 추가합니다.

$ oc secrets new pull_secret_name .dockerconfigjson=path/to/.docker/config.json

이미지를 가져오기 위해 서비스 계정에 Secret를 추가합니다.

$ oc secrets add serviceaccount/default secrets/pull_secret_name --for=pull

OpenShift에는 Docker 이미지를 관리하고 배포할 수 있는 다양한 기능이 있어 애플리케이션 배포를 유연하게 제어할 수 있습니다.

자격 증명이 준비되면 oc create 명령을 사용하여 서비스를 배포할 Replication Controller를 만들 수 있습니다. auth-proxy 서비스를 생성하기 위해 다음 명령을 실행했습니다.

$ oc create -f auth-proxy.yml

각 서비스에 대해 이 명령을 실행한 후 OpenShift Overview 인터페이스를 사용하여 모든 서비스가 사양에 따라 실행되고 구성되었는지 확인했습니다.

Overview page in OpenShift GUI, with servers configured per the Proxy Model of the NGINX Microservices Reference Architecture

그림 3. OpenShift Overview 페이지에서 서비스 확인

Auth Proxy는 Backend 서비스에 대한 기본 인터페이스이므로 경로가 필요합니다. 경로는 OpenShift에서 GUI의 Create Route 화면을 사용하여 만들 수 있습니다. 서비스를 선택하고 Create Route 화면을 열어 경로를 지정합니다.

경로 이름을 지정할 때, 특히 단일 경로의 경우 경로가 연결되는 서비스와 동일한 이름을 지정하는 것이 좋습니다. 이렇게 하면 경로와 서비스를 명확하게 연결할 수 있으며, 이는 기본적으로 Create Route 도구에서 수행됩니다.

OpenShift 라우트는 공개적으로 액세스할 수 있는 Endpoint이므로 호스트명이 있어야 합니다. 호스트명을 직접 입력하거나 시스템에서 생성하도록 할 수 있습니다. 시스템은 xip.io DNS 서비스를 사용하여 공용 호스트명을 생성합니다.

마지막으로 경로의 대상 포트를 추가해야 합니다. SSL/TLS를 사용하는 경우, Create Route 도구는 SSL/TLS 인증서를 업로드할 수 있는 기능을 제공합니다. TLS Passthrough 설정을 사용하면 TCP 수준 트래픽을 Auth-Proxy 컨테이너로 직접 라우팅할 수 있습니다.

OpenShift는 MRA를 실행하는 데 매우 유능한 CaaS 플랫폼임이 입증되었습니다.

Create Route tool in OpenShift for uploading SSL/TLS certificates

그림 4. SSL/TLS 인증서 업로드를 위한 Create Route 도구

4. NGINX 및 NGINX Plus로 Kubernetes 서비스 Expose

OpenShift에서 작업할 때 가장 흥미로운 측면 중 하나는 Kubernetes Ingress Controller API가 OpenShift와 통합되어 제공될 때 이를 활용할 수 있는 가능성이 있다는 점입니다.

NGINX는 최신 버전의 Kubernetes와 함께 작동하는 NGINX 및 NGINX Plus 기반 Ingress Controller의 Open Source 버전을 개발했습니다. 이 Ingress Controller 구현은 일부 사용자 정의 Go 코드와 함께 NGINX 및 NGINX Plus 기능의 조합을 사용하여 전체 Service Discovery, 라우팅 및 트래픽 관리를 Kubernetes 클러스터로 수행합니다.

NGINX Ingress Controller는 두 가지 버전으로 제공됩니다. NGINX Open Source 버전을 사용하는 Open Source 버전과 Ingress 트래픽을 관리하기 위해 NGINX Plus를 사용하는 상용 버전이 있습니다.

이 둘의 차이점은 NGINX Plus 버전에는 Load Balancing Pool에서 서버를 관리하기 위한 동적 메모리 Zone이 있다는 것입니다. NGINX Plus를 사용하면 많은 일반적인 Load Balancing 이벤트에 대해 NGINX를 Reload할 필요 없이 즉시 변경할 수 있습니다. 또한 이 버전에는 클러스터 내의 트래픽 지표에 대한 훨씬 더 자세한 정보를 APM에 제공할 수 있는 상태 API가 있습니다.

많은 측면에서 Ingress Controller는 MRA에서 Auth-Proxy 서비스의 많은 부분을 담당하지만, OpenShift 클러스터로 Ingress 트래픽을 관리하기 위해 보다 일반화된 서비스를 제공하므로 배포 중인 대부분의 OpenShift 애플리케이션에 활용할 수 있습니다.

5. 결론

OpenShift의 고급 Load Balancer로 NGINX Plus를 활용할 수 있다는 것은 매우 흥미로운 일이며, OpenShift 애플리케이션으로 유입되는 트래픽을 관리하기 위한 강력한 기능을 많이 제공합니다. OpenShift는 Proxy 모델을 구현하기 위한 견고한 플랫폼임이 입증되었으며, 이제 Router Mesh 모델과 Fabric 모델에서 보다 복잡한 네트워크 아키텍처를 구현할 수 있게 되었습니다.

NGINX Plus를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.