해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 83 - Saving Cloud Costs Using Existing Prometheus Metrics
1. KRR (Kubernetes Resource Recommender) 란?
최근 1~2년 사이 많은 기업들이 클라우드 비용 절감을 위해 온프레미스로 회귀하거나 하이브리드 클라우드 전략을 채택하고 있다.
하지만 온프레미스는 확장성과 유지보수 측면에서 명확한 한계가 있다. 클라우드의 이점을 유지하면서 비용을 줄이는 방법은 없을까?
연구에 따르면, 쿠버네티스 클러스터 비용의 69% 이상이 리소스 과다 할당으로 인해 낭비되고 있다고 한다.
즉, 애플리케이션에 적절한 리소스(Request/Limit)만 할당해도 막대한 비용을 절감할 수 있다는 것이다.
따라서 프레젠테이션에서는 기존 Prometheus 데이터를 활용하여 데이터 기반의 리소스 최적화 권장 사항을 제공하는 오픈 소스 도구, KRR(Kubernetes Resource Recommender)에 대해 제시한다.
KRR (Kubernetes Resource Recommender)이란, Robusta에서 개발한 KRR은 쿠버네티스 리소스(CPU/Memory)의 Request과 Limit 값을 최적화할 수 있도록 도와주는 오픈 소스 CLI 도구이다.
-
에이전트리스 (No Agent): 클러스터에 별도의 에이전트를 지속적으로 실행할 필요가 없다.
-
Prometheus 통합: 이미 수집된 Prometheus의 히스토리 데이터를 활용한다.
즉, 추측이 아닌 실제 내 애플리케이션의 데이터를 기반으로 분석한다. -
즉시 실행: 한 번의 CLI 실행으로 즉각적인 결과를 얻을 수 있다.
-
확장성: Python 기반으로 작성되어 있어 알고리즘을 사용자가 직접 커스터마이징할 수 있다.
2. 설치 및 실행 방법
2-1. 사전 요구 사항
-
Prometheus: 클러스터 메트릭을 수집 중이어야 한다.
-
kube-state-metrics: KRR이 분석에 필요한 메트릭을 제공한다.
- 참고:
kube-prometheus-stack을 사용 중이라면 이미 포함되어 있어 별도 설정이 필요 없다.
- 참고:
2-2. 실행 및 결과 분석
KRR을 실행하면 지난 14일간의 데이터를 분석하여 다음과 같은 권장 사항 테이블을 출력한다.
-
Pods/Old Pods: 현재 실행 중인 파드와 과거 파드 수.
-
Container: 파드 내 각 컨테이너별로 분석 결과를 제공한다.
-
Recommended Request/Limit: 데이터 기반으로 산출된 최적의 CPU/Memory 값.
-
Diff: 현재 설정값과 권장 값의 차이를 보여준다. (예: +251m은 추가 필요, -925Mi는 절감 가능)
이 결과를 통해 사용자는 어떤 서비스가 과다 할당되었는지, 혹은 리소스 부족 위험이 있는지 한눈에 파악할 수 있다.
3. KRR에서는 왜 CPU Limit을 설정하지 말아야 하는가
KRR을 실행해보면 대부분의 권장 사항이 CPU Limit을 설정 해제(Unset)하라는 내용임을 알게 된다.
이는 많은 엔지니어들이 의아해하는 부분이지만, 첨부된 이미지를 통해 그 이유를 명확히 이해할 수 있다.
해당 이미지는 CPU Request와 Limit 설정 조합에 따른 파드의 동작 방식을 4분면으로 나누어 설명한다.
-
CPU Requests + CPU Limits (주황색 - 좌상단)
-
상태: Request와 Limit을 모두 설정한 경우.
-
동작: Request만큼의 CPU는 보장받는다. 하지만 Limit을 초과하는 CPU 사용은 불가능하다.
-
문제점: 노드에 유휴 CPU 자원이 남더라도, 파드는 Limit에 막혀 이를 사용할 수 없다. 이는 CPU Throttling을 유발하여 애플리케이션의 성능 저하(Latency 증가)로 이어진다.
-
-
CPU Requests + No CPU Limits (초록색 - 우상단, 권장)
-
상태: Request는 설정하고, Limit은 설정하지 않은 경우.
-
동작: Request만큼의 CPU 자원은 확실히 보장받는다.
-
장점: 노드에 남는 CPU 자원이 있다면, 파드는 필요한 만큼 이를 가져다 쓸 수 있다.
-
결론: CPU는 압축 가능한 자원이다.
즉, 시스템이 바쁠 때는 조금 느려질 뿐 죽지는 않는다. 따라서 Limit을 없애 유휴 자원을 최대한 활용하여 성능을 높이는 것이 효율적이다. KRR이 이 방식을 권장하는 이유다.
-
-
No CPU Requests (하단 영역)
-
No Requests + Limits (주황색): 쿠버네티스가 자동으로 Request를 Limit과 동일하게 설정한다. Limit만큼 보장되지만 그 이상은 사용 불가하다.
-
No Requests + No Limits (빨간색 - 우하단): 아무런 자원 보장도 받지 못한다. 노드 자원이 부족하면 가장 먼저 성능이 저하되거나 죽을 수 있다. 절대 권장하지 않는다.
-
- 주의: 위 내용은 CPU에만 해당된다. Memory는 압축 불가능한 자원이므로, Limit을 초과하면 OOM Kill이 발생한다. 따라서 메모리는 Limit 설정이 필수적이다.
4. KRR vs VPA (Vertical Pod Autoscaler)
KRR과 유사한 기능을 하는 쿠버네티스 네이티브 도구인 VPA와의 차이점은 다음과 같다.
| 특징 | KRR (Robusta) | VPA (Kubernetes Native) |
|---|---|---|
| 실행 방식 | CLI 도구 (필요할 때 실행) | 클러스터 내 상시 실행 데몬 |
| 결과 도출 | 즉시 (기존 Prometheus 데이터 활용) | 일정 기간 데이터 수집 필요 (Warm-up) |
| 적용 방식 | 권장 사항 리포트 제공 (사람이 판단) | 파드 설정을 직접/자동으로 수정 |
| 커스텀 | 알고리즘 확장 및 수정 용이 | 설정이 제한적 |
KRR은 즉각적인 가시성을 제공하고, 변경 사항을 적용하기 전 엔지니어가 검토할 수 있다는 점에서 운영 안정성이 높다.
5. 추가 기능 및 활용
KRR은 단순 CLI를 넘어 다양한 방식으로 활용 가능하다.
-
Slack 통합: Robusta와 연동하여 주기적으로 리소스 최적화 리포트를 슬랙으로 받아볼 수 있다.
-
상세 분석: Robusta UI를 통해 특정 권장 사항이 도출된 근거(히스토리 그래프 등)를 시각적으로 확인할 수 있다.
-
K9s 플러그인: 터미널 UI 도구인 K9s에 플러그인으로 설치하여, 실시간으로 파드 리스트 옆에서 권장 값을 확인할 수 있다.
6. 정리
-
리소스의 Request/Limit 최적화만으로도 상당한 비용을 아낄 수 있다.
-
새로운 데이터 수집 도구 필요 없이, 기존 Prometheus 데이터를 활용하면 된다.
-
KRR을 사용하면 별도의 에이전트 없이 즉각적인 최적화 권고안을 얻을 수 있다.
-
CPU Limit을 제거하고 Request를 적절히 설정하는 것이 리소스 효율성과 성능 면에서 가장 유리하다.
