Kubernetes CPU 스로틀링: 응답 시간의 조용한 킬러

오늘날 Kubernetes에서 미션 크리티컬 애플리케이션을 실행하는 대부분의 조직은 멀티테넌트 환경에서 이를 수행하고 있습니다. 이러한 멀티테넌트 환경에서는 테넌트 워크로드의 자원 사용량을 조절하기 위해 한계값을 설정하거나, 사용량에 따른 비용 청구를 제한하기 위해 한계값을 설정합니다. 일부 개발자는 애플리케이션의 벤치마크 테스트를 위해 CPU 또는 GPU 제한을 설정하기도 합니다.

물리적 CPU 코어의 작업 스케줄링 속도가 의도치 않게 감소하여 애플리케이션 응답 시간이 원치 않게 증가하는 현상인 CPU 스로틀링은 이 설계의 의도하지 않은 결과입니다. 다음 예시를 살펴보겠습니다.

위 그림에서 컨테이너의 CPU 사용률이 25%에 불과하므로 크기를 줄이기에 적합한 후보입니다.

그러나 컨테이너의 크기를 조정한 후(컨테이너 CPU 사용량은 현재 50%이지만, 여전히 높지는 않음) 응답 시간이 4배로 늘어났습니다.

그래서 무슨 일이 벌어지고 있는 걸까요? CPU 제한을 컨테이너에 구성할 때 CPU 스로틀링이 발생하는데, 이로 인해 오히려 애플리케이션의 응답 시간이 느려지고 제한 문제가 발생할 수 있습니다. 기본 노드에 리소스가 충분하더라도 컨테이너 워크로드가 제대로 구성되지 않았기 때문에 여전히 제한됩니다. 또한 스로틀링의 성능 영향은 기본 물리적 프로세서(Intel, AMD, NVIDIA)에 따라 달라질 수 있습니다. 높은 응답 시간은 높은 CPU 스로틀링 기간과 직접적인 상관관계가 있으며, 이것이 바로 Kubernetes가 작동하도록 설계된 방식입니다.

이 내용을 구체적으로 설명하자면, CPU 제한을 200ms로 설정했다고 가정해 봅시다. 이 제한은 기본적으로 Linux 시스템의 그룹 쿼터로 변환됩니다. 컨테이너는 기본 실행 주기가 100ms이기 때문에 한 번에 20ms의 CPU 시간(이를 CPU 타임 슬라이스라고 함)만 사용할 수 있습니다. 작업이 20ms보다 길면 스로틀링이 발생하고 작업을 완료하는 데 4배 더 오래 걸립니다.

이 동작에 따라 스로틀링으로 인한 응답 시간 증가로 인해 애플리케이션의 성능이 저하되며 문제를 찾기 위한 문제 해결이 시작됩니다.

소규모 배포를 실행하는 경우 스로틀링 문제를 수동으로 해결할 수 있습니다.

먼저, kubectl과 같은 도구를 사용하여 영향을 받는 파드를 식별합니다. 다음으로 파드의 리소스 요청 및 제한을 검토하여 적절하게 설정되었는지 확인합니다. 스로틀링을 유발할 수 있는 컨테이너 내에서 실행 중인 리소스를 많이 소모하는 프로세스를 확인하고 CPU 사용률 및 제한을 분석합니다.

CPU 스로틀링이 지속되면 수평적 파드 자동 크기 조정을 고려하여 더 많은 파드에 워크로드를 분산하거나 수요에 맞게 클러스터의 노드 리소스를 조정합니다. 리소스 설정을 지속적으로 모니터링하고 미세 조정하여 성능을 최적화하고 추가적인 스로틀링 문제를 방지합니다.

대규모 배포에서는 파드를 더 추가함에 따라 이 접근 방식이 확장되거나 지속되지 않을 것입니다.

CPU 스로틀링은 응답 시간과 CPU 스로틀링 간의 직접적인 상관관계 때문에 애플리케이션 성능의 핵심 지표입니다. 좋은 소식은 Kubernetes와 OpenShift에서 직접 이 지표를 얻을 수 있다는 것입니다.

애플리케이션 응답 시간을 낮게 유지하고 CPU가 스로틀링되지 않고 고성능 애플리케이션을 계속 사용하려면 먼저 CPU 스로틀링이 발생할 때 CPU 코어 사용률에만 의존할 수 없다는 점을 이해해야 합니다. 애플리케이션 성능에 영향을 미치는 모든 분석 및 리소스 종속성을 고려해야 합니다. IBM® Turbonomic은 이러한 고려 사항을 분석 플랫폼에 통합했습니다.

컨테이너 규모 최적화 조치 작업을 결정할 때 Turbonomic은 다음 네 가지 차원을 지속적으로 분석합니다.

1. CPU 제한
2. CPU 요청
3. 메모리 제한
4. 메모리 요청

Turbonomic은 스로틀링 위험을 완화하고 애플리케이션이 제약 없이 성능을 발휘할 수 있도록 하는 CPU 제한을 결정할 수 있습니다. 이 모든 것은 CPU 스로틀링을 플랫폼 차원으로 추가하여 여러 가지 상충 관계를 분석하고 관리할 수 있는 능력을 확보한 덕분입니다. CPU 스로틀링 차원을 추가하면 애플리케이션 응답 시간을 단축할 수 있습니다.

게다가 Turbonomic은 파드를 이동시키고 클러스터를 확장하는 작업을 자동으로 생성합니다. 모두가 알다시피, 이는 풀 스택 과제입니다. 고객은 KPI를 보고 '내 서비스 중 어떤 서비스가 스로틀링되고 있나요?'라고 질문할 수 있습니다. 또한 각 서비스의 CPU 스로틀링 이력을 파악하고 각 서비스가 애플리케이션 응답 시간과 직접적인 상관관계가 있음을 기억하여 사용자가 시스템 성능을 파악할 수 있도록 유용한 창을 제공합니다.

Kubernetes 컨텍스트에서 Turbonomic의 주요 이점 중 하나는 고객이 멀티테넌트 플랫폼 전략을 재설계하는 대신 플랫폼 전략의 의도하지 않은 결과를 신속하게 식별하고 수정할 수 있는 기능입니다. Turbonomic은 CPU 스로틀링 지표를 모니터링할 수 있을 뿐만 아니라 플랫폼에서 CPU 제한을 자동으로 적정 크기로 조정하여 스로틀링을 관리 가능한 수준으로 낮출 수 있습니다.

IBM® Turbonomic은 클라우드 지출과 성능을 동시에 최적화하는 데 도움을 줄 수 있습니다. 사람의 개입 없이도 중요한 작업을 지속적으로 실시간 자동화하여, 스택의 전 계층에서 앱에 컴퓨팅, 스토리지 및 네트워크 리소스를 가장 효율적으로 사용할 수 있습니다.