2025-11-20T20:19:15.373671

CPU-Limits kill Performance: Time to rethink Resource Control

Shetty, Chakraborty, Franke et al.
Research in compute resource management for cloud-native applications is dominated by the problem of setting optimal CPU limits -- a fundamental OS mechanism that strictly restricts a container's CPU usage to its specified CPU-limits . Rightsizing and autoscaling works have innovated on allocation/scaling policies assuming the ubiquity and necessity of CPU-limits . We question this. Practical experiences of cloud users indicate that CPU-limits harms application performance and costs more than it helps. These observations are in contradiction to the conventional wisdom presented in both academic research and industry best practices. We argue that this indiscriminate adoption of CPU-limits is driven by erroneous beliefs that CPU-limits is essential for operational and safety purposes. We provide empirical evidence making a case for eschewing CPU-limits completely from latency-sensitive applications. This prompts a fundamental rethinking of auto-scaling and billing paradigms and opens new research avenues. Finally, we highlight specific scenarios where CPU-limits can be beneficial if used in a well-reasoned way (e.g. background jobs).
academic

CPU-Limits kill Performance: Time to rethink Resource Control

기본 정보

  • 논문 ID: 2510.10747
  • 제목: CPU-Limits kill Performance: Time to rethink Resource Control
  • 저자: Chirag Shetty (UIUC), Sarthak Chakraborty (UIUC), Hubertus Franke (IBM Research), Larisa Shwartz (IBM Research), Chandra Narayanaswami (IBM Research), Indranil Gupta (UIUC), Saurabh Jha (IBM Research)
  • 분류: cs.DC (분산 컴퓨팅), cs.OS (운영 체제), cs.PF (성능)
  • 발표 시간: 2025년 10월 (arXiv 사전 인쇄본)
  • 논문 링크: https://arxiv.org/abs/2510.10747

초록

본 논문은 클라우드 네이티브 애플리케이션의 컴퓨팅 자원 관리에서 핵심 메커니즘인 CPU 제한(CPU-Limits)에 대해 근본적인 의문을 제기한다. 학술 연구와 산업 실무에서 CPU 제한이 필수적이라고 널리 인정되고 있음에도 불구하고, 저자들은 실증적 증거를 통해 CPU 제한이 실제로 애플리케이션 성능을 손상시키고 비용을 증가시킨다는 것을 보여준다. 본 논문은 지연 시간에 민감한 애플리케이션이 CPU 제한을 완전히 폐기해야 한다고 주장하며, 이는 자동 확장 및 청구 모델에 대한 근본적인 재검토가 필요함을 의미한다. 동시에 CPU 제한이 백그라운드 작업과 같은 특정 시나리오에서는 합리적인 용도가 있음을 지적한다.

연구 배경 및 동기

문제 정의

컨테이너화된 마이크로서비스의 CPU 자원 관리는 클라우드 컴퓨팅 분야의 핵심 문제이다. 현재의 주류 접근 방식은 CPU-Limits (c.limit) 메커니즘을 통해 컨테이너의 CPU 사용량을 엄격하게 제한하는 것이며, 이 메커니즘은 Linux의 cpu.cfs_quota_us를 기반으로 구현된다. 그러나 저자들은 실제 배포에서 이론과 실무 사이에 상당한 괴리가 존재함을 관찰했다.

문제의 중요성

  1. 성능 영향: CPU 제한으로 인한 throttling은 애플리케이션 지연 시간을 급격하게 악화시키며, 심지어 연쇄 장애를 유발할 수 있다
  2. 비용 문제: throttling을 피하기 위해 설정된 안전 마진으로 인해 25-45%의 자원 과다 배치 발생
  3. 운영 복잡성: DevOps 담당자는 여러 세분화된 CPU 제한 사이에서 복잡한 트레이드오프를 수행해야 한다

기존 방법의 한계

기존의 자동 확장 연구(FIRM, Cilantro, Autothrottle 등)는 모두 CPU 제한의 필요성이라는 가정 위에 구축되어 있으며, 메커니즘 자체에 의문을 제기하기보다는 제한값 최적화에 초점을 맞추고 있다. 저자들의 분석을 통해 이러한 방법들은 CPU 제한을 제거한 후 모두 작동하지 않음을 발견했다.

연구 동기

SRE(사이트 신뢰성 엔지니어)와의 인터뷰 및 온라인 토론 조사를 통해, 저자들은 운영 커뮤니티가 CPU 제한에 대해 의견이 분분함을 발견했다. 많은 실무자들이 이미 성능 개선을 위해 CPU 제한을 제거하기 시작했으며, 이는 학계의 주류 관점과 대조를 이룬다.

핵심 기여

  1. 전통적 관념에 도전: 지연 시간에 민감한 애플리케이션에서 CPU 제한의 필요성에 대해 처음으로 체계적으로 의문을 제기하며, 충분한 실증적 증거 제공
  2. 성능 분석: CPU 제한이 지연 시간, 신뢰성 및 비용에 미치는 부정적 영향 메커니즘을 심층 분석
  3. 대안 설계: CPU-Requests (c.req)만을 사용한 자원 관리의 가능성과 장점 입증
  4. 새로운 패러다임 제시: overage와 노드 활용률을 기반으로 한 새로운 자동 확장 설계 및 성능 기반 청구 모델 제안
  5. 프로토타입 구현: YAAS(Yet Another AutoScaler) 프로토타입 구축으로 51%의 자원 절감 달성
  6. 적용 시나리오 구분: 백그라운드 작업, CPU 바운드 작업 등 CPU 제한의 합리적 사용 시나리오 명확히 정의

방법론 상세 설명

작업 정의

연구 목표는 CPU 제한을 사용하지 않으면서 CPU-Requests와 노드 활용률 최적화를 통해 더 나은 성능-비용 트레이드오프를 달성하는 컨테이너 CPU 자원 관리 메커니즘을 재설계하는 것이다.

핵심 논증 프레임워크

저자들은 CPU 제한의 다양한 구성 시나리오를 체계적으로 분석하기 위한 의사결정 트리(그림 1)를 구축했다:

  1. limit = req: 비용 증가를 초래하며, 25-45%의 안전 마진 필요
  2. limit > req:
    • 제한에 도달하지 않으면 불필요함
    • 제한에 도달할 수 있으면 자동 확장이 "중단"되거나 지연 시간이 급격하게 악화됨

CPU-Requests 충분성 증명

저자들은 두 가지 수준에서 CPU-Requests만 사용하는 것의 충분성을 증명했다:

CFS 스케줄러 보장: Linux CFS 스케줄러는 비례 공정성 보장을 제공하여, CPU-Requests r_i를 가진 Pod P_i가 총 CPU C인 노드에서 최소한 (r_i/Σr_j) × C의 CPU 시간을 획득하도록 보장한다.

오케스트레이터 게이팅: Kubernetes 등의 오케스트레이터는 노드 상의 모든 컨테이너의 CPU-Requests 합계가 노드 용량을 초과하지 않도록 보장하여, CPU-Requests를 절대 최소 보장으로 만든다.

YAAS 프로토타입 설계

YAAS는 두 가지 핵심 제어 변수를 기반으로 한다:

  1. Overage (U-R): Pod의 실제 사용량과 할당량의 차이
  2. 노드 활용률 (N): Pod이 위치한 노드의 총 CPU 활용률

핵심 전략:

  • overage ≥ 0을 유지하며, SLO 위반이 임박할 때만 자원 증가
  • Pod 마이그레이션을 통한 노드 활용률 최적화
  • 수직 및 수평 확장 결합

실험 설정

데이터셋

DeathStarBench의 두 가지 마이크로서비스 애플리케이션 사용:

  • HotelReservation (HR): 호텔 예약 시스템
  • SocialNetwork (SN): 소셜 네트워크 애플리케이션

실험 환경

  • 플랫폼: Amazon EC2 클러스터
  • 부하 패턴: 변화하는 요청 부하로 실제 프로덕션 환경 모의
  • 평가 지표:
    • 종단 간 꼬리 지연 시간(P99)
    • CPU 자원 사용량
    • 확장 횟수 및 수렴 시간
    • 비용 효율성

비교 방법

  • CPU 제한 기반의 전통적 HPA (Horizontal Pod Autoscaler)
  • 수동으로 최적화된 CPU 제한 구성
  • 다양한 안전 마진 설정(20%-30%)

실험 결과

주요 결과

지연 시간 영향:

  • 19개 Pod 중 단 1개에만 CPU 제한을 설정해도 종단 간 꼬리 지연 시간이 5배 악화됨
  • CPU 제한은 두 가지 메커니즘을 통해 성능을 손상시킴: 단일 요청 throttling 및 교차 요청 큐 형성

비용 분석:

  • throttling을 피하려면 25-45%의 자원 과다 배치 필요
  • 단순히 CPU 제한을 제거하면 38%의 자원 절감 가능
  • YAAS는 추가로 51%의 자원 절감 달성

자동 확장 성능:

  • 부하 증가 25%일 때, 확장 임계값을 60%에서 70%로 올리면 SLO 만족 시간이 4배 증가
  • CPU 제한이 자동 확장 민감도에 미치는 영향을 보여줌

소거 실험

안전 마진 분석: 다양한 애플리케이션이 서로 다른 안전 마진을 필요로 함:

  • nginx-thrift: 30%
  • user-timeline-service: 45%

큐 형성 메커니즘: 이론 분석 및 실험을 통해 CPU 제한이 낮은 부하에서 어떻게 큐를 형성하는지, 그리고 CPU-Requests는 이 문제를 발생시키지 않음을 검증

사례 분석

다중 테넌트 시나리오: 실험 결과 두 애플리케이션이 공존할 때, CPU-Requests가 준수하는 애플리케이션을 버스팅 애플리케이션으로부터 효과적으로 보호할 수 있으며, CPU 제한은 오히려 성능을 악화시킴을 보여줌

연쇄 장애: CPU 제한으로 인한 긴 큐가 Pod 메모리 초과를 유발하여 Pod 재시작을 초래하고, 이는 다른 Pod이 제한에 도달하거나 요청 시간 초과를 야기할 수 있음

관련 연구

자동 확장 연구

논문은 최근 상위 컨퍼런스의 자동 확장 연구를 체계적으로 분석하여 모두 CPU 제한에 의존함을 발견했다:

  • FIRM: 강화 학습을 사용한 CPU 제한 최적화
  • Cilantro: 온라인 피드백 기반 자원 할당 조정
  • Autothrottle: SLO 목표 처리를 위한 이중 계층 방법
  • Ursa: 분석 기반 자원 관리

산업 실무

  • Kubernetes QoS 분류는 중요 컨테이너에 CPU 제한 설정 요구
  • 클라우드 서비스 제공자(예: GCP Autopilot)는 자동으로 CPU 제한 적용
  • 다중 테넌트 모범 사례는 CPU 제한 사용 권장

결론 및 토론

주요 결론

  1. CPU 제한의 해로움: 지연 시간에 민감한 애플리케이션의 경우, CPU 제한은 해롭거나(throttling 유발) 불필요함(절대 도달하지 않음)
  2. CPU-Requests의 충분성: 현대 오케스트레이터와 스케줄러의 보장으로 인해 CPU-Requests는 자원 격리를 제공하기에 충분함
  3. 새로운 설계 공간: CPU 제한 제거는 overage와 노드 활용률을 기반으로 한 새로운 최적화 차원을 개방함
  4. 패러다임 전환 필요: 자동 확장 및 청구 모델의 재설계 필요

한계

  1. 적용 범위: 주로 지연 시간에 민감한 애플리케이션을 대상으로 하며, 백그라운드 작업 등의 시나리오는 여전히 CPU 제한 필요
  2. 실험 규모: 실험은 특정 마이크로서비스 벤치마크를 기반으로 하며, 더 광범위한 검증 필요
  3. 프로덕션 배포: 프로토타입 YAAS는 프로덕션 환경에서 사용하기 위해 추가 엔지니어링 필요
  4. 생태계: 오케스트레이터, 모니터링 및 청구 시스템의 협력적 변화 필요

향후 방향

  1. 지능형 스케줄링: 마이크로아키텍처 자원(캐시, 메모리 대역폭)의 간섭 인식 스케줄링 결합
  2. 성능 기반 청구: 자원 사용량이 아닌 SLO 만족도를 기반으로 한 청구 모델
  3. 수직 확장: CPU 제한 없는 환경에서의 수직 확장 최적화
  4. 다중 차원 최적화: Pod 확장과 노드 확장의 결합 최적화

심층 평가

장점

  1. 혁신적 관점: 분야의 기본 가정에 도전하는 용기로 학술적 가치 높음
  2. 충분한 실증: 이론 분석, 실험 검증 및 산업 조사를 통한 다차원적 지지
  3. 실용적 가치: 구체적인 대안 방안 및 프로토타입 구현으로 직접적인 응용 가치 제공
  4. 체계적 분석: 성능, 비용, 신뢰성 등 다양한 관점에서 포괄적 분석
  5. 균형잡힌 관점: CPU 제한의 오용을 비판하면서도 합리적 사용 시나리오 지적

부족한 점

  1. 실험 한계: 실험이 주로 두 가지 마이크로서비스 애플리케이션을 기반으로 하며, 더 광범위한 애플리케이션 유형 검증 부족
  2. 프로덕션 검증: 대규모 프로덕션 환경의 장기 검증 데이터 부족
  3. 호환성: 기존 시스템 및 도구 체인 개조 비용 분석 부족
  4. 보안 고려: CPU 제한 제거로 인한 잠재적 보안 위험에 대한 심층 논의 부족

영향력

학술적 영향:

  • 자원 관리 분야의 패러다임 전환 가능성
  • 자동 확장 연구에 새로운 설계 사상 제공
  • 10년 이상의 산업 모범 사례에 도전

산업적 영향:

  • 클라우드 서비스 제공자에게 비용 최적화의 새로운 경로 제시
  • Kubernetes 등 오케스트레이터의 향후 설계에 영향 가능
  • 성능 기반 청구 모델 혁신 추진

적용 시나리오

직접 적용 가능:

  • 지연 시간에 민감한 온라인 서비스
  • 비용에 민감한 클라우드 네이티브 애플리케이션
  • 높은 성능 보장이 필요한 마이크로서비스 아키텍처

신중한 검토 필요:

  • 다중 테넌트 환경(추가 격리 메커니즘 필요)
  • 백그라운드 작업을 포함한 혼합 워크로드
  • 자원 사용에 대한 엄격한 규정 준수 요구 시나리오

참고 문헌

논문은 83개의 관련 문헌을 인용하며, 컨테이너 오케스트레이션, 자원 관리, 자동 확장 등 다양한 분야의 중요 연구를 포함한다. 주요 참고 문헌은 다음을 포함한다:

  • Kubernetes 공식 문서 및 모범 사례
  • 최근 상위 컨퍼런스의 자동 확장 연구(OSDI, NSDI, EuroSys 등)
  • Linux 커널 CPU 스케줄링 및 제어 그룹 관련 문서
  • 산업계의 실무 경험 및 사례 연구

본 논문은 혁신적인 관점과 충분한 실증 분석으로 클라우드 네이티브 자원 관리 분야에 중요한 도전을 제기한다. CPU 제한을 완전히 제거하는 것이 생태계의 광범위한 변화를 필요로 할 수 있지만, 제시된 통찰력과 대안 방안은 해당 분야의 향후 발전 방향을 제시한다. 본 논문의 가치는 기술적 기여뿐만 아니라 산업의 기존 관념에 대한 깊이 있는 성찰에 있다.