9.2. 라우팅 최적화


OpenShift Container Platform HAProxy 라우터는 성능을 최적화하도록 확장 또는 구성할 수 있습니다.

9.2.1. 기본 Ingress 컨트롤러(라우터) 성능

OpenShift Container Platform Ingress 컨트롤러 또는 라우터는 경로 및 인그레스를 사용하여 구성된 애플리케이션 및 서비스의 수신 트래픽의 수신 지점입니다.

초당 처리된 HTTP 요청 측면에서 단일 HAProxy 라우터 성능을 평가할 때 성능은 여러 요인에 따라 달라집니다. 특히 중요한 요인은 다음과 같습니다.

  • HTTP 연결 유지/닫기 모드
  • 경로 유형
  • TLS 세션 재개 클라이언트 지원
  • 대상 경로당 동시 연결 수
  • 대상 경로 수
  • 백엔드 서버 페이지 크기
  • 기본 인프라(네트워크/SDN 솔루션, CPU 등)

특정 환경의 성능은 달라질 수 있으나 Red Hat 랩은 크기가 4 vCPU/16GB RAM인 퍼블릭 클라우드 인스턴스에서 테스트합니다. 1kB 정적 페이지를 제공하는 백엔드에서 종료한 100개의 경로를 처리하는 단일 HAProxy 라우터가 처리할 수 있는 초당 트랜잭션 수는 다음과 같습니다.

HTTP 연결 유지 모드 시나리오에서는 다음과 같습니다.

EncryptionLoadBalancerServiceHostNetwork

none

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

HTTP 닫기(연결 유지 제외) 시나리오에서는 다음과 같습니다.

EncryptionLoadBalancerServiceHostNetwork

none

5719

8273

edge

2729

4069

passthrough

4121

5344

re-encrypt

2320

2941

기본 Ingress 컨트롤러 구성은 spec.tuningOptions.threadCount 필드에서 4 로 설정된 상태에서 사용되었습니다. 두 가지 엔드 포인트 게시 전략이 테스트되었습니다: Load Balancer Service 및 Host Network. 암호화된 경로에는 TLS 세션 재개가 사용되었습니다. HTTP keep-alive를 사용하면 단일 HAProxy 라우터가 8kB의 작은 페이지 크기에서 1Gbit NIC를 포화시킬 수 있습니다.

최신 프로세서가 있는 베어 메탈에서 실행하는 경우 성능이 위 퍼블릭 클라우드 인스턴스의 약 2배가 될 것을 예상할 수 있습니다. 이 오버헤드는 퍼블릭 클라우드에서 가상화 계층에 의해 도입되며 프라이빗 클라우드 기반 가상화에도 적용됩니다. 다음 표는 라우터 뒤에서 사용할 애플리케이션 수에 대한 가이드입니다.

애플리케이션 수애플리케이션 유형

5-10

정적 파일/웹 서버 또는 캐싱 프록시

100-1000

동적 콘텐츠를 생성하는 애플리케이션

일반적으로 HAProxy는 사용 중인 기술에 따라 최대 1000개의 애플리케이션 경로를 지원할 수 있습니다. Ingress 컨트롤러 성능은 언어 또는 정적 콘텐츠 대비 동적 콘텐츠 등 지원하는 애플리케이션의 기능과 성능에 따라 제한될 수 있습니다.

Ingress 또는 라우터 샤딩을 사용하여 애플리케이션에 대한 경로를 더 많이 제공하면 라우팅 계층을 수평으로 확장하는 데 도움이 됩니다.

Ingress 샤딩에 대한 자세한 내용은 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성 및 네임스페이스 라벨 을 사용하여 Ingress 컨트롤러 샤딩 구성을 참조하십시오.

시간 초과에 대한 스레드 및 Ingress 컨트롤러 구성 매개변수 설정에 제공된 정보를 사용하여 Ingress 컨트롤러 배포 및 Ingress 컨트롤러 사양의 기타 튜닝 구성 을 사용하여 Ingress 컨트롤러 배포를 수정할 수 있습니다.

9.2.2. Ingress 컨트롤러 활동성, 준비 상태, 시작 프로브 구성

클러스터 관리자는 OpenShift Container Platform Ingress 컨트롤러(라우터)에서 관리하는 라우터 배포에 대한 kubelet의 활동성, 준비 상태 및 시작 프로브에 대한 시간 초과 값을 구성할 수 있습니다. 라우터의 활성 상태 및 준비 상태 프로브는 기본 시간 초과 값이 1초이며, 네트워킹 또는 런타임 성능이 크게 저하될 때 너무 짧습니다. 프로브 시간 초과로 인해 애플리케이션 연결을 중단하는 원치 않는 라우터 재시작이 발생할 수 있습니다. 더 큰 타임아웃 값을 설정하는 기능은 불필요하고 원치 않는 재시작 위험을 줄일 수 있습니다.

라우터 컨테이너의 livenessProbe,readinessProbe, startupProbe 매개변수에서 timeoutSeconds 값을 업데이트할 수 있습니다.

매개변수설명

livenessProbe

livenessProbe 는 Pod가 종료되었는지 여부를 kubelet에 보고하고 다시 시작해야 합니다.

readinessProbe

readinessProbe 는 Pod가 정상인지 비정상적인지 여부를 보고합니다. 준비 상태 프로브에서 비정상 Pod를 보고하면 kubelet은 Pod를 트래픽을 수락할 준비가 되지 않은 것으로 표시합니다. 결과적으로 해당 Pod의 끝점이 준비되지 않은 것으로 표시되고 이 상태는 kube-proxy로 전달됩니다. 로드 밸런서가 구성된 클라우드 플랫폼에서 kube-proxy는 해당 Pod를 사용하여 노드로 트래픽을 보내지 않도록 클라우드 로드 밸런서와 통신합니다.

startupProbe

startupProbe 는 kubelet이 라우터 활동성 및 준비 상태 프로브 전송을 시작하기 전에 초기화할 최대 2분 동안 라우터 Pod를 제공합니다. 이 초기화 시간은 많은 경로 또는 엔드 포인트가 있는 라우터가 조기 다시 시작되지 않을 수 있습니다.

중요

시간 초과 구성 옵션은 문제를 해결하는 데 사용할 수 있는 고급 튜닝 기술입니다. 그러나 이러한 문제는 결국 진단되어야 하며 프로브의 시간 초과를 유발하는 모든 문제에 대해 지원 케이스 또는 Jira 문제가 열리게 됩니다.

다음 예제에서는 기본 라우터 배포를 직접 패치하여 활성 상태 프로브 및 준비 상태 프로브에 대해 5초의 타임아웃을 설정하는 방법을 보여줍니다.

$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'

검증

$ oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
    Liveness:   http-get http://:1936/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:1936/healthz/ready delay=0s timeout=5s period=10s #success=1 #failure=3

9.2.3. HAProxy 재로드 간격 구성

경로와 연결된 경로 또는 끝점을 업데이트하면 OpenShift Container Platform 라우터에서 HAProxy 구성을 업데이트합니다. 그런 다음 HAProxy는 이러한 변경 사항을 적용하기 위해 업데이트된 구성을 다시 로드합니다. HAProxy가 다시 로드되면 업데이트된 구성을 사용하여 새 연결을 처리하는 새 프로세스가 생성됩니다.

HAProxy는 해당 연결이 모두 닫힐 때까지 기존 프로세스를 실행하여 기존 연결을 처리합니다. 이전 프로세스에 수명이 긴 연결이 있는 경우 이러한 프로세스에서 리소스를 누적하고 사용할 수 있습니다.

기본 최소 HAProxy 재로드 간격은 5초입니다. spec.tuningOptions.reloadInterval 필드를 사용하여 Ingress 컨트롤러를 구성하여 최소 다시 로드 간격을 더 길게 설정할 수 있습니다.

주의

최소 HAProxy 재로드 간격에 큰 값을 설정하면 경로 및 해당 엔드포인트에 대한 업데이트를 관찰하는 대기 시간이 발생할 수 있습니다. 위험을 줄이려면 업데이트에 허용 가능한 대기 시간보다 큰 값을 설정하지 마십시오.

절차

  • 다음 명령을 실행하여 기본 Ingress 컨트롤러의 최소 HAProxy 재로드 간격을 15초로 변경합니다.

    $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"tuningOptions":{"reloadInterval":"15s"}}}'
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.