15장. 짧은 대기 시간 튜닝
15.1. 짧은 대기 시간 이해
Telco/5G 영역에서 Edge 컴퓨팅이 등장하여 대기 시간 및 정체 문제를 줄이고 애플리케이션 성능을 개선하는 데 핵심적인 역할을 하고 있습니다.
간단히 말해, 대기 시간이 데이터(패킷)가 발신자에서 수신자로 이동하고 수신자의 처리 후 발신자로 반환되는 속도를 결정합니다. 5G의 네트워크 성능 요구 사항을 충족하기 위해 대기 시간이 가장 짧은 지연으로 네트워크 아키텍처를 유지보수하는 것이 핵심입니다. 평균 대기 시간이 50ms인 4G 기술과 비교하여 5G는 1ms 이하의 대기 시간 번호에 도달하는 것을 목표로 합니다. 이렇게 대기 시간이 감소하면 무선 처리량이 10배 증가합니다.
Telco 공간에 배포된 많은 애플리케이션에서는 제로 패킷 손실이 가능한 짧은 대기 시간을 요구하고 있습니다. 제로 패킷 손실 튜닝은 네트워크 성능을 저하시키는 고유한 문제를 완화하는 데 도움이 됩니다. 자세한 내용은 RHOSP(Red Hat OpenStack Platform)에서 제로 패킷 손실 튜닝을 참조하십시오.
Edge 컴퓨팅 이니셔티브는 대기 시간을 줄이는 데에도 큰 역할을 합니다. 클라우드 에지에 있고 사용자에게 더 가깝다고 생각해 보십시오. 이렇게 되면 멀리 있는 데이터 센터와 사용자 간 거리를 크게 줄여 애플리케이션 응답 시간과 성능 대기 시간이 단축됩니다.
관리자는 많은 엣지 사이트와 로컬 서비스를 중앙 집중식으로 관리하여 가능한 한 가장 낮은 관리 비용으로 모든 배포를 실행할 수 있어야 합니다. 또한, 실시간 짧은 대기 시간과 높은 성능을 실현할 수 있도록 클러스터의 특정 노드를 쉽게 배포하고 구성할 수 있어야 합니다. 대기 시간이 짧은 노드는 CNF(클라우드 네이티브 네트워크 기능) 및 DPDK(데이터 플레인 개발 키트)와 같은 애플리케이션에 유용합니다.
OpenShift Container Platform에서는 현재 실시간 실행과 짧은 대기 시간(약 20마이크로초 미만의 반응 시간)을 지원하기 위해 OpenShift Container Platform 클러스터의 소프트웨어를 튜닝하는 메커니즘을 제공합니다. 이 메커니즘에는 커널 및 OpenShift Container Platform 설정 값 튜닝, 커널 설치, 머신 재구성이 포함되어 있습니다. 하지만 이 방법을 사용하려면 4가지 Operator를 설정해야 하며 수동으로 수행할 경우 복잡하고 실수하기 쉬운 많은 구성을 수행해야 합니다.
OpenShift Container Platform은 Node Tuning Operator를 사용하여 자동 튜닝을 구현하여 OpenShift Container Platform 애플리케이션에 대해 짧은 대기 시간 성능을 실현합니다. 클러스터 관리자는 이 성능 프로필 구성을 사용하여 보다 안정적인 방식으로 이러한 변경을 더욱 쉽게 수행할 수 있습니다. 관리자는 커널을 kernel-rt로 업데이트할지 여부를 지정하고, Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 CPU를 예약하고, 애플리케이션 컨테이너의 CPU를 분리하여 워크로드를 실행할 수 있습니다.
OpenShift Container Platform에서는 다양한 산업 환경의 요구를 충족하기 위해 PerformanceProfile
을 조정할 수 있는 Node Tuning Operator의 워크로드 팁도 지원합니다. 워크로드 힌트는 높은 PowerConsumption
(전원 소비 증가 시 낮은 대기 시간) 및 realTime
(최적 최적의 대기 시간으로 지정된 우선 순위)에 사용할 수 있습니다. 이러한 힌트에 대한 true/false
설정의 조합을 사용하여 애플리케이션별 워크로드 프로필 및 요구 사항을 처리할 수 있습니다.
워크로드 힌트는 업계 섹터 설정에 대한 성능 세부 조정 작업을 단순화합니다. "하나의 크기가 모든" 접근 방식에 적합한 대신 워크로드 힌트는 우선순위 배치와 같은 사용 패턴에 적합할 수 있습니다.
- 짧은 대기 시간
- 실시간 기능
- 효율적인 전력 사용
이상적인 세계에서 모든 것이 우선 순위가 될 것입니다 : 실제 삶에서, 일부는 다른 사람의 비용으로 발생합니다. Node Tuning Operator는 이제 워크로드의 기대치를 인식하고 워크로드의 요구를 더 잘 충족할 수 있게 되었습니다. 이제 클러스터 관리자가 워크로드가 속하는 사용 사례를 지정할 수 있습니다. Node Tuning Operator는 PerformanceProfile
을 사용하여 워크로드의 성능 설정을 미세 조정합니다.
애플리케이션이 작동하는 환경은 해당 동작에 영향을 미칩니다. 대기 시간 요구 사항이 없는 일반적인 데이터 센터의 경우 일부 고성능 워크로드 Pod에 대한 CPU 파티셔닝을 활성화하려면 최소한의 기본 튜닝만 필요합니다. 대기 시간이 더 높은 데이터 센터 및 워크로드의 경우 전력 소비를 최적화하기 위해 계속 조치를 취해야 합니다. 가장 복잡한 경우는 제조기 및 소프트웨어 정의 무선과 같은 대기 시간에 민감한 장치에 가까운 클러스터입니다. 이 마지막 배포 클래스는 Far edge라고 합니다. Far edge 배포의 경우 대기 시간이 가장 낮은 것이 궁극적인 우선 순위이며 전원 관리 비용으로 달성됩니다.
OpenShift Container Platform 버전 4.10 및 이전 버전에서 Performance Addon Operator는 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 사용되었습니다. 이제 이 기능이 Node Tuning Operator의 일부입니다.
15.1.1. 짧은 대기 시간과 실시간 애플리케이션의 하이퍼 스레딩 정보
하이퍼 스레딩은 물리 CPU 프로세서 코어가 두 개의 논리 코어로 작동하여 두 개의 독립 스레드를 동시에 실행할 수 있는 Intel 프로세서 기술입니다. 하이퍼 스레딩을 사용하면 병렬 처리가 효과적인 특정 워크로드 유형에 대한 시스템 처리량이 향상시킬 수 있습니다. 기본 OpenShift Container Platform 설정에서는 기본적으로 하이퍼 스레딩을 활성화하도록 설정해야합니다.
통신 애플리케이션의 경우 가능한 한 대기 시간을 최소화하도록 애플리케이션 인프라를 설계하는 것이 중요합니다. 하이퍼 스레딩은 성능을 저하시킬 수 있으며 대기 시간이 짧은 컴퓨팅 집약적 워크로드의 처리량에 부정적인 영향을 미칠 수 있습니다. 하이퍼 스레딩을 비활성화하면 예측 가능한 성능이 보장되고 이러한 워크로드의 처리 시간을 줄일 수 있습니다.
OpenShift Container Platform을 실행하는 하드웨어에 따라 하이퍼 스레딩 구현 및 구성이 다릅니다. 해당 하드웨어와 관련된 하이퍼 스레딩 구현에 대한 자세한 내용은 관련 호스트 하드웨어 튜닝 정보를 참조하십시오. 하이퍼 스레딩을 비활성화하면 클러스터 코어당 비용이 증가할 수 있습니다.
추가 리소스