13장. 라우팅 최적화
OpenShift Container Platform HAProxy 라우터는 스케일링을 통해 성능을 최적화합니다.
13.1. 기본 Ingress 컨트롤러(라우터) 성능
OpenShift Container Platform Ingress 컨트롤러 또는 라우터는 OpenShift Container Platform 서비스를 대상으로 하는 모든 외부 트래픽의 Ingress 지점입니다.
초당 처리된 HTTP 요청 측면에서 단일 HAProxy 라우터 성능을 평가할 때 성능은 여러 요인에 따라 달라집니다. 특히 중요한 요인은 다음과 같습니다.
- HTTP 연결 유지/닫기 모드
- 경로 유형
- TLS 세션 재개 클라이언트 지원
- 대상 경로당 동시 연결 수
- 대상 경로 수
- 백엔드 서버 페이지 크기
- 기본 인프라(네트워크/SDN 솔루션, CPU 등)
특정 환경의 성능은 달라질 수 있으나 Red Hat 랩은 크기가 4 vCPU/16GB RAM인 퍼블릭 클라우드 인스턴스에서 테스트합니다. 1kB 정적 페이지를 제공하는 백엔드에서 종료한 100개의 경로를 처리하는 단일 HAProxy 라우터가 처리할 수 있는 초당 트랜잭션 수는 다음과 같습니다.
HTTP 연결 유지 모드 시나리오에서는 다음과 같습니다.
| Encryption | LoadBalancerService | HostNetwork |
|---|---|---|
| none | 21515 | 29622 |
| edge | 16743 | 22913 |
| passthrough | 36786 | 53295 |
| re-encrypt | 21583 | 25198 |
HTTP 닫기(연결 유지 제외) 시나리오에서는 다음과 같습니다.
| Encryption | LoadBalancerService | HostNetwork |
|---|---|---|
| none | 5719 | 8273 |
| edge | 2729 | 4069 |
| passthrough | 4121 | 5344 |
| re-encrypt | 2320 | 2941 |
ROUTER_THREADS=4로 설정된 기본 Ingress 컨트롤러 구성이 사용되었고 두 개의 서로 다른 끝점 게시 전략(LoadBalancerService/HostNetwork)이 테스트되었습니다. 암호화된 경로에는 TLS 세션 재개가 사용되었습니다. HTTP 연결 유지 기능을 사용하면 단일 HAProxy 라우터가 8kB의 작은 페이지 크기에서 1Gbit NIC를 수용할 수 있습니다.
최신 프로세서가 있는 베어 메탈에서 실행하는 경우 성능이 위 퍼블릭 클라우드 인스턴스의 약 2배가 될 것을 예상할 수 있습니다. 이 오버헤드는 퍼블릭 클라우드에서 가상화 계층에 의해 도입되며 프라이빗 클라우드 기반 가상화에도 적용됩니다. 다음 표는 라우터 뒤에서 사용할 애플리케이션 수에 대한 가이드입니다.
| 애플리케이션 수 | 애플리케이션 유형 |
|---|---|
| 5-10 | 정적 파일/웹 서버 또는 캐싱 프록시 |
| 100-1000 | 동적 콘텐츠를 생성하는 애플리케이션 |
일반적으로 HAProxy는 사용 중인 기술에 따라 5~1,000개의 애플리케이션 경로를 지원할 수 있습니다. Ingress 컨트롤러 성능은 언어 또는 정적 콘텐츠 대비 동적 콘텐츠 등 지원하는 애플리케이션의 기능과 성능에 따라 제한될 수 있습니다.
Ingress 또는 라우터 샤딩을 사용하여 애플리케이션에 대한 경로를 더 많이 제공하면 라우팅 계층을 수평으로 확장하는 데 도움이 됩니다.
Ingress 샤딩에 대한 자세한 내용은 경로 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성 및 네임스페이스 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성을 참조하십시오.
