NGINX 튜토리얼: 오토스케일링으로 Kubernetes 지연 시간 단축

Daniele Polencic

이 튜토리얼은 다음 자료의 개념을 실제로 적용해 보는 네 가지 튜토리얼 중 하나입니다. 2022년 3월 마이크로서비스: Kubernetes 네트워킹:

• 오토스케일링으로 Kubernetes 지연 시간 단축하기(이 게시물)
• 속도 제한으로 Kubernetes API 보호
• SQL 인젝션으로부터 Kubernetes 앱 보호
• 카나리 배포로 가동 시간과 복원력 향상

더욱 다양한 Kubernetes 네트워킹 사용 사례에서 NGINX를 활용하는 방법에 대한 자세한 안내가 필요하신가요? 무료 전자책 NGINX를 활용한 Kubernetes 트래픽 관리: 실용 가이드를 다운로드하세요.

귀사에서 Kubernetes 기반 앱을 구축했는데, 이제 인기를 끌고 있습니다! 하루 방문자 수가 불과 몇 명에서 수백 명(때로는 수천 명)으로 늘었습니다. 하지만 문제가 있습니다. 증가한 트래픽이 병목 현상을 일으켜 고객에게 지연과 시간 초과가 발생하고 있습니다. 사용자 경험을 개선하지 못하면 사람들은 이 앱을 더 이상 사용하지 않을 것입니다.

당신, 바로 용감한 Kubernetes 엔지니어에게 해결책이 있습니다. 트래픽을 라우팅하도록 Ingress 컨트롤러를 배포하고, 트래픽 변동에 맞춰 Ingress 컨트롤러 파드 수가 즉시 늘어나거나 줄어들도록 자동 확장 정책을 설정합니다. 이제 Ingress 컨트롤러 파드는 트래픽 급증도 원활하게 처리합니다. “지연 시간이여, 안녕!” 트래픽이 감소하면 리소스를 절약하도록 축소됩니다. “비용 절감이여, 어서 와!” 정말 잘하셨습니다.

실습 및 튜토리얼 개요

이 블로그는 Microservices March 2022의 유닛 1 실습인 트래픽이 많은 웹사이트를 위한 Kubernetes 클러스터 설계와 함께 제공되며, NGINX Ingress Controller를 사용해 앱을 외부에 노출한 다음 높은 트래픽에 대응하여 Ingress 컨트롤러 Pod를 자동 확장하는 방법을 보여줍니다.

이 튜토리얼을 진행하려면 다음 조건을 갖춘 머신이 필요합니다:

• CPU 2개 이상
• 2GB의 여유 메모리
• 20GB의 여유 디스크 공간
• 인터넷 연결
• Docker, Hyperkit, Hyper‑V, KVM, Parallels, Podman, VirtualBox 또는 VMware Fusion/Workstation과 같은 컨테이너 또는 가상 머신 관리자
• minikube 설치됨
• Helm 설치됨
• 브라우저 창을 실행할 수 있는 구성. 실행할 수 없는 경우 브라우저를 통해 관련 서비스에 액세스하는 방법을 파악해야 합니다.

실습과 튜토리얼을 최대한 활용하려면 시작하기 전에 다음 사항을 준비하는 것이 좋습니다:

• Watch the 라이브 스트리밍으로 진행된 개념 개요 녹화 영상 보기
• 검토하세요: 배경 설명 블로그
• 20분 분량의 실습 요약 동영상을 시청하세요:  

이 튜토리얼에서는 다음 기술을 사용합니다:

• NGINX Ingress Controller (NGINX Open Source 기반)
• Helm
• KEDA
• Locust
• minikube
• Podinfo
• Prometheus

각 챌린지의 안내에는 앱을 구성하는 데 사용되는 YAML 파일의 전체 내용이 포함되어 있습니다. 또한 GitHub 리포지토리에서 해당 내용을 복사할 수도 있습니다. 각 YAML 파일의 내용과 함께 GitHub 링크가 제공됩니다.

이 튜토리얼에는 네 가지 과제가 포함되어 있습니다:

1. Kubernetes 클러스터에서 간단한 앱 구성하기
2. NGINX Ingress Controller를 사용하여 앱으로 트래픽 라우팅
3. 트래픽 생성 및 모니터링
4. NGINX Ingress Controller 자동 확장

과제 1: Kubernetes 클러스터에 간단한 앱 구성하기

이 챌린지에서는 minikube 클러스터를 생성하고 샘플 앱으로 Podinfo를 설치합니다.

Minikube 클러스터 만들기

Create a minikube 클러스터를 생성합니다. 몇 초 후 배포가 성공했다는 메시지가 표시됩니다.

$ minikube start 🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default 

Podinfo 앱 설치

Podinfo는 “Kubernetes에서 마이크로서비스를 실행하는 모범 사례를 보여 주는 Go로 만든 웹 애플리케이션”입니다. 설치 용량이 작기 때문에 샘플 앱으로 사용합니다.

1. 원하는 텍스트 편집기를 사용하여 다음 내용으로 1-deployment.yaml이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사). 이 파일은 단일 복제본이 있는 Deployment와 Service를 정의합니다.

apiVersion: apps/v1 kind: Deployment 
metadata: 
  name: podinfo 
spec: 
  selector: 
    matchLabels: 
      app: podinfo 
  template: 
    metadata: 
      labels: 
        app: podinfo 
    spec: 
      containers: 
      - name: podinfo 
        image: stefanprodan/podinfo 
        ports: 
        - containerPort: 9898 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: podinfo 
spec: 
  ports: 
    - port: 80 
      targetPort: 9898 
      nodePort: 30001 
  selector: 
    app: podinfo 
  type: LoadBalancer 

1. 앱을 배포합니다:

$ kubectl apply -f 1-deployment.yaml deployment.apps/podinfo created 
service/podinfo created

1. Podinfo pod가 배포되었는지 확인합니다. 이는 Running 열의 STATUS 값으로 확인할 수 있습니다.

$ kubectl get podsNAME                       READY   STATUS   RESTARTS   AGE 
podinfo-5d76864686-rd2s5   1/1     Running  0          3m38s

1. 브라우저에서 Podinfo를 엽니다. greetings from podinfo 페이지가 표시되면 Podinfo가 실행 중인 것입니다.

$ minikube service podinfo

과제 2: NGINX Ingress Controller를 사용하여 앱으로 트래픽 라우팅하기

이 챌린지에서는 NGINX Ingress Controller를 배포하고 이를 구성하여 트래픽을 Podinfo 앱으로 라우팅합니다.

NGINX Ingress Controller 배포

NGINX Ingress Controller를 가장 빠르게 설치하는 방법은 Helm을 사용하는 것입니다.

1. Helm에 NGINX 리포지토리를 추가합니다:

$ helm repo add nginx-stable https://helm.nginx.com/stable 

1. NGINX Open Source 기반의 NGINX Ingress Controller를 다운로드하여 설치합니다. 이 컨트롤러는 F5 NGINX에서 유지 관리합니다. 출력의 마지막 줄에서 설치가 완료되었음을 확인할 수 있습니다.

$ helm install main nginx-stable/nginx-ingress \ --set controller.watchIngressWithoutClass=true \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30005 
NAME: main 
LAST DEPLOYED: Tue Mar 15 09:49:17 2022 
NAMESPACE: default 
STATUS: deployed 
REVISION: 1 
TEST SUITE: None 
NOTES: The NGINX Ingress Controller has been installed.

1. NGINX Ingress Controller Pod가 배포되었는지 확인합니다. 배포된 경우 Running 값이 STATUS 열에 표시됩니다(가독성을 위해 출력은 두 줄로 나누어 표시함).

$ kubectl get podsNAME                                   READY   STATUS    ...
main-nginx-ingress-779b74bb8b-mtdkr    1/1     Running   ...
podinfo-5d76864686-fjncl               1/1     Running   ...

       ... RESTARTS   AGE
       ... 0          18s 
       ... 0        2m36s

앱으로 트래픽 라우팅하기

1. 원하는 텍스트 편집기를 사용하여 다음 내용으로 2-ingress.yaml이라는 YAML 파일을 생성합니다(또는 GitHub에서 복사). 이 파일은 트래픽을 Podinfo로 라우팅하는 데 필요한 Ingress 매니페스트를 정의합니다.

apiVersion: networking.k8s.io/v1 kind: Ingress 
metadata: 
  name: podinfo 
spec: 
  ingressClassName: nginx 
  rules: 
    - host: "example.com" 
      http: 
        paths: 
          - backend: 
              service: 
                name: podinfo 
                port: 
                  number: 80 
            path: / 
            pathType: Prefix 

1. Ingress 리소스를 배포합니다:

$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/podinfo created 

과제 3: 트래픽 생성 및 모니터링

이 과제에서는 다양한 트래픽 부하에서 NGINX Ingress Controller의 성능을 관찰합니다. 준비 단계로 NGINX Ingress Controller에서 제공하는 메트릭을 나열하고 Prometheus를 배포하고, Locust를 설치합니다. 그런 다음 Locust를 사용하여 트래픽 급증을 시뮬레이션하고 성능에 미치는 영향을 추적합니다(Prometheus에서 확인).

앞서 살펴본 것처럼 Ingress 컨트롤러는 역방향 프록시(여기서는 NGINX)와 Kubernetes 통합을 위한 일부 코드를 하나로 묶은 일반 Kubernetes 파드입니다. 앱에 많은 트래픽이 유입되는 경우 NGINX Ingress Controller의 과부하로 인한 지연을 방지하려면 NGINX Ingress Controller 파드의 복제본 수를 늘려야 할 수 있습니다.

사용 가능한 메트릭 목록 확인

언제 얼마나 확장해야 하는지 파악하려면 NGINX Ingress Controller의 성능에 대한 정확한 정보가 필요합니다. 이 튜토리얼에서는 확장 시점을 결정하는 NGINX 메트릭으로 활성 연결 수(nginx_connections_active)를 사용합니다. 여기에서는 NGINX Ingress Controller가 이 메트릭을 추적하는지 확인합니다.

NGINX Ingress Controller는 여러 메트릭을 제공합니다: 이 튜토리얼에서 사용하는 NGINX Open Source 기반 모델은 8개의 메트릭을, NGINX Plus 기반 모델은 80개 이상의 메트릭을 제공합니다.

1. 메트릭 목록을 쿼리할 수 있도록 NGINX Ingress Controller 파드의 IP 주소를 확인합니다. 주소는 IP 필드에 표시되며, 여기서는 172.17.0.4입니다. (가독성을 위해 RESTARTS 및 AGE 열은 생략하고 출력은 두 줄로 나누어 표시했습니다.)

$ kubectl get pods -o wide NAME                                  READY   STATUS    ...
main-nginx-ingress-779b74bb8b-6hdwx   1/1     Running   ...
podinfo-5d76864686-nl8ws              1/1     Running   ...

    ... IP           NODE       NOMINATED NODE  READINESS GATES 
    ... 172.17.0.4   minikube   <none>          <none> 
    ... 172.17.0.3   minikube   <none>          <none>

1. Kubernetes 클러스터 내부의 호스트에 셸을 사용할 수 있는 임시 BusyBox 파드를 생성합니다:

$ kubectl run -ti --rm=true busybox --image=busyboxIf you don't see a command prompt, try pressing enter. 
/ # 

1. NGINX Ingress Controller에서 생성된 메트릭을 나열하고, 여기에 nginx_connections_active가 포함되어 있는지 확인합니다. <IP_address>에는 1단계에서 확인한 값을 입력합니다.

/# wget -qO- <IP_address>:9113/metrics

1. 셸을 종료하여 Kubernetes 서버로 돌아갑니다.

/# exit 

Prometheus 배포

이제 NGINX Ingress Controller가 nginx_connections_active 메트릭을 추적한다는 것을 알았으므로, 메트릭을 수집(“스크레이핑”)할 도구가 필요합니다. 이 튜토리얼에서는 Prometheus를 사용합니다.

NGINX Ingress Controller와 마찬가지로 Helm을 사용하는 것이 Prometheus를 설치하는 가장 빠른 방법입니다.

1. Helm에 Prometheus 리포지토리를 추가합니다:

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

1. Prometheus를 다운로드하여 설치합니다:

$ helm install prometheus prometheus-community/prometheus \ --set server.service.type=NodePort --set server.service.nodePort=30010

1. 설치를 확인합니다. 설치가 완료되는 데는 일반적으로 최대 60초가 걸립니다. 다음 샘플 출력에서는 helm install 명령을 실행한 지 불과 몇 초 후에 확인 명령을 실행했으므로 설치가 진행 중이며, 일부 Prometheus Pod의 STATUS 필드에 ContainerCreating이 표시됩니다. 모든 Pod의 상태가 Running이면 설치가 완료된 것입니다. (가독성을 위해 출력은 두 줄로 나누어 표시했습니다.)

$ kubectl get podsNAME                                           READY  ...
main-nginx-ingress-779b74bb8b-mtdkr            1/1    ...
podinfo-5d76864686-fjncl                       1/1    ...
prometheus-alertmanager-d6d94cf4b-85ww5        0/2    ...
prometheus-kube-state-metrics-7cd8f95cb-86hhs  0/1    ...
prometheus-node-exporter-gqxfz                 1/1    ...
prometheus-pushgateway-56745d8d8b-qnwcb        0/1    ...
prometheus-server-b78c9449f-kwhzp              0/2    ...

      ... STATUS             RESTARTS  AGE 
      ... Running            0         3m23s 
      ... Running            0         5m41s 
      ... ContainerCreating  0         7s
      ... Running            0         7s
      ... Running            0         7s
      ... ContainerCreating  0         7s
      ... ContainerCreating  0         7s

1. Prometheus를 엽니다. minikube 환경에서는 다음 명령을 실행합니다. 그러면 기본 브라우저에서 Prometheus 대시보드가 열립니다.

$ minikube service prometheus-server

1. 다음과 같은 페이지가 표시되면 서버가 정상적으로 작동하고 있는 것입니다.
   
2. 검색창에 nginx_ingress_nginx_connections_active을 입력하여 현재 활성 연결 메트릭 값을 확인합니다. 활성 연결이 하나 표시되는데, 이는 NGINX Ingress Controller Pod를 하나 배포했기 때문입니다.

Locust 설치

다음 섹션에서는 오픈 소스 부하 테스트 도구인 Locust를 사용하여 트래픽 급증을 시뮬레이션하고 Prometheus에서 NGINX Ingress Controller의 성능을 확인합니다. 여기서는 Locust를 배포합니다.

1. 원하는 텍스트 편집기를 사용하여 다음 내용으로 3-locust.yaml이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사). Deployment 및 Service 객체는 Locust Pod를 정의합니다. ConfigMap 객체는 올바른 헤더를 포함하여 Pod로 보낼 요청을 생성하는 locustfile.py 스크립트를 정의합니다.

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: locust-script 
data: 
  locustfile.py: |- 
    from locust import HttpUser, task, between 

    class QuickstartUser(HttpUser): 
        wait_time = between(0.7, 1.3) 

        @task 
        def hello_world(self): 
            self.client.get("/", headers={"Host": "example.com"}) 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: locust 
spec: 
  selector: 
    matchLabels: 
      app: locust 
  template: 
    metadata: 
      labels: 
        app: locust 
    spec: 
      containers: 
        - name: locust 
          image: locustio/locust 
          ports: 
            - containerPort: 8089 
          volumeMounts: 
            - mountPath: /home/locust 
              name: locust-script 
      volumes: 
        - name: locust-script 
          configMap: 
            name: locust-script 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: locust 
spec: 
  ports: 
    - port: 8089 
      targetPort: 8089 
      nodePort: 30015 
  selector: 
    app: locust 
  type: LoadBalancer 

1. Locust 배포:

$ kubectl apply -f 3-locust.yaml configmap/locust-script created 
deployment.apps/locust created 
service/locust created 

트래픽 급증을 시뮬레이션하고 성능에 미치는 영향 관찰하기

1. 브라우저에서 Locust를 엽니다.

$ minikube service locust

1. 
2. 필드에 다음 값을 입력합니다:
   • 사용자 수 – 1000
   • 생성 속도 – 10
   • 호스트 – http://main-nginx-ingress
3. Click the Start swarming 버튼을 클릭하여 Podinfo 앱으로 트래픽을 전송합니다.
4. Prometheus 대시보드로 돌아가 NGINX Ingress Controller가 어떻게 응답하는지 확인합니다. 변경 사항을 확인하려면 nginx_ingress_nginx_connections_active에 대해 새 쿼리를 실행해야 할 수도 있습니다. 다음 화면 출력에서 볼 수 있듯이, 많은 연결이 설정되면서 단일 NGINX Ingress Controller Pod는 지연 시간 증가 없이 늘어난 트래픽을 처리하는 데 어려움을 겪습니다. Prometheus 그래프를 보면 NGINX Ingress Controller Pod당 활성 연결이 약 100개에 이르면 지연 시간이 급증하기 시작합니다. 이 정보를 활용하면 지연 시간 증가를 방지하기 위해 NGINX Ingress Controller Pod 수를 언제 확장해야 하는지 판단할 수 있습니다.
   

과제 4: NGINX Ingress Controller 자동 확장

마지막 과제에서는 트래픽 양이 증가함에 따라 리소스를 자동으로 확장하는 구성을 구축합니다. 이 튜토리얼에서는 자동 확장에 KEDA를 사용하므로 먼저 KEDA를 설치하고 확장이 수행되는 시점과 방식을 정의하는 정책을 만듭니다. 그런 다음 과제 3에서와 마찬가지로 Locust를 사용하여 트래픽 급증을 시뮬레이션하고, Prometheus를 사용하여 자동 확장이 활성화되었을 때 NGINX Ingress Controller의 성능을 관찰합니다.

KEDA 설치

KEDA는 Kubernetes 이벤트 기반 오토스케일러로, 메트릭 서버(Kubernetes용 메트릭을 저장하고 변환하는 구성 요소)를 통합하며 Prometheus를 비롯한 여러 도구에서 메트릭을 직접 가져올 수 있습니다. 이러한 메트릭을 사용하여 Horizontal Pod Autoscaler(HPA)를 생성하고, Prometheus에서 수집한 메트릭을 연계하여 Kubernetes에 전달합니다.

NGINX Ingress Controller 및 Prometheus와 마찬가지로, 이 튜토리얼에서는 Helm을 사용하여 KEDA를 설치합니다.

1. Helm 리포지토리에 KEDA를 추가합니다:

$ helm repo add kedacore https://kedacore.github.io/charts 
"kedacore" has been added to your repositories 

1. KEDA를 설치합니다:

$ helm install keda kedacore/keda NAME: keda 
NAMESPACE: default 
STATUS: deployed 
REVISION: 1 
TEST SUITE: None

1. KEDA가 두 개의 Pod로 실행 중인지 확인합니다. (가독성을 위해 NAME 열의 일부 값은 축약했습니다. 또한 RESTARTS 열은 생략했으며, 모든 Pod의 값은 0입니다.)

$ kubectl get pods NAME                                    READY  STATUS     AGE 
keda-operator-8644dcdb79-492x5 1/1 Running 59s keda-operator-metrics-apiserver-66d... 1/1 Running 59s 
locust-77c699c94d-dvb5n                 1/1    Running  8m59s 
main-nginx-ingress-779b74bb8b-v7ggw     1/1    Running    48m 
podinfo-5d76864686-c98rb                1/1    Running    50m 
prometheus-alertmanager-d6d94cf4b-8...  2/2    Running    37m 
prometheus-kube-state-metrics-7cd8f...  1/1    Running    37m 
prometheus-node-exporter-j4qf4          1/1    Running    37m 
prometheus-pushgateway-56745d8d8b-9n4nl 1/1    Running    37m 
prometheus-server-b78c9449f-6ktn9       2/2    Running    37m

자동 확장 정책 만들기

이제 KEDA의 ScaledObject 사용자 정의 리소스 정의(CRD)를 사용하여 NGINX Ingress Controller의 확장 방식을 결정하는 매개변수를 정의합니다. 다음 구성은 다음과 같습니다:

• Prometheus에서 수집한 nginx_connections_active 메트릭 값을 기준으로 자동 확장을 트리거합니다
• 기존 각 Pod의 활성 연결 수가 100개에 도달하면 새 Pod를 배포합니다
• NGINX Ingress Controller Pod를 1개에서 최대 20개까지 자동으로 확장합니다

다음 단계를 수행합니다:

1. 원하는 텍스트 편집기를 사용하여 다음 내용으로 4-scaled-object.yaml이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사). 이 파일은 KEDA ScaledObject를 정의합니다.

apiVersion: keda.sh/v1alpha1 kind: ScaledObject 
metadata: 
 name: nginx-scale 
spec: 
 scaleTargetRef: 
   kind: Deployment 
   name: main-nginx-ingress 
minReplicaCount: 1 
maxReplicaCount: 20 
cooldownPeriod: 30 
pollingInterval: 1 
triggers: 
- type: prometheus 
  metadata: 
    serverAddress: http://prometheus-server 
    metricName: nginx_connections_active_keda 
    query: | 
      sum(avg_over_time(nginx_ingress_nginx_connections_active{app="main-nginx-ingress"}[1m])) 
    threshold: "100" 

1. Deploy the ScaledObject를 배포합니다:

$ kubectl apply -f 4-scaled-object.yaml scaledobject.keda.sh/nginx-scale created 

트래픽 급증을 시뮬레이션하고 오토스케일링이 성능에 미치는 영향 관찰하기

자동 확장의 효과를 제대로 테스트하기 위해 챌린지 3에 비해 연결 수를 두 배로 늘립니다.

1. 브라우저에서 Locust 서버로 돌아갑니다. 필드에 다음 값을 입력하고 Start swarming 버튼을 클릭합니다:
   • 사용자 수 – 2000
   • 생성 속도 – 10
   • 호스트 – http://main-nginx-ingress
2. Prometheus 및 Locust 대시보드로 돌아갑니다. Prometheus 그래프 아래의 분홍색 상자는 NGINX Ingress Controller Pod 수가 확장 및 축소되는 모습을 나타냅니다.
   
3. 터미널로 돌아가 KEDA HPA를 직접 확인합니다. 출력의 REPLICAS 필드에는 현재 배포된 Pod 복제본 수가 표시됩니다. (가독성을 위해 출력은 두 줄로 나누어 표시했습니다.)

$ kubectl get hpa
NAME                  REFERENCE                      ... 
keda-hpa-nginx-scale  Deployment/main-nginx-ingress  ... 

    ... TARGETS           MINPODS   MAXPODS   REPLICAS   AGE 
    ... 101500m/100 (avg) 1         20        10         2m45s

다음 단계

활성 연결 수만을 기준으로 자동 확장을 수행하면 잠재적인 한계가 있습니다. 확장을 수행했음에도 NGINX Ingress Controller가 너무 바빠 연결을 끊어야 하는 상황이 발생하면, 자동 확장기는 활성 연결 수가 줄어든 것을 요청이 감소한 것으로 해석하여 복제본 수를 줄입니다. 이로 인해 성능이 더 저하될 수 있지만, 여러 메트릭을 함께 활용하면 이러한 상황을 방지할 수 있습니다. 예를 들어, nginxplus_connections_dropped(NGINX Plus 기반 NGINX Ingress Controller에서 사용 가능)는 이렇게 끊어진 클라이언트 연결을 추적합니다.

NGINX Plus 및 NGINX App Protect가 포함된 NGINX Ingress Controller를 사용해 보려면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

NGINX Open Source와 함께 NGINX Ingress Controller를 사용해 보려면 릴리스 소스 코드를 받거나 DockerHub에서 사전 빌드된 컨테이너를 다운로드할 수 있습니다.

작성자 소개

Daniele Polencic

Daniele Polencic의 다른 블로그 게시물