26J30f

Young-Kyoo Kim·2026년 6월 29일

[운영 표준 지침서] 클러스터 FinOps 자원 효율성 데이터 레이크하우스 운영 가이드

본 지침서는 대규모 멀티 클러스터 환경(Compute/Storage 인프라)의 자원 사용량을 추적하고, Thanos 직접 쿼리 및 MinIO AIStor 데이터 레이크하우스 파이프라인을 관리하는 신규 운영자를 위한 마스터 매뉴얼입니다.

🏗️ 1. 아키텍처 및 파이프라인 데이터 흐름 개요

신규 운영자는 데이터가 플랫폼 레이어에서 스토리지 레이어로 어떻게 정제 및 영구화되는지 매커니즘을 명확히 이해해야 합니다.

[1단계: 수집] `step1_prom_fetch.py`

매일 새벽 2시(KST) 기동되어 전일 24시간 분량의 원천 시계열(1분 주기 해상도)을 6시간 단위 청크로 타노스에서 분할 조회합니다.
조회 완료 즉시 MinIO AIStor 원천 버킷(enterprise-finops-raw-lake) 내 raw/ 경로로 영구 백업(Archiving)을 집행합니다.

[2단계: 정제 및 리싱크] `step2_pipeline.py`

팟(Pod) 기동 시 생성되는 휘발성 공간(emptyDir)으로 지정 기간의 Parquet 파티션 파일들을 MinIO 버킷에서 고속 다운로드(Sync-Down)합니다.
config.py에 등록된 규칙에 따라 노드 정규식 필터링, 클러스터 용도별 계통 분류(Compute/Storage), 워크로드 도메인 정제, 핵심 Core-Hours 연산을 처리합니다.

[3단계: 시각화] `step3_analytics.py`

정제 원부를 기반으로 노드 밀도 분포도, 일자별 낭비 추이 막대, [요일 × 워크로드] 2차원 패턴 매트릭스 히트맵 이미지를 드로잉합니다.

[4단계: 배포] `step6_excel_builder.py`

정산 조건에 맞춤형 접미사가 붙은 마스터 엑셀 리포트(finops_report_인프라종류_날짜범위.xlsx)를 최종 빌드하여 MinIO 배포 버킷(enterprise-finops-reports)의 reports/ 경로로 자동 푸시(Push) 후 팟의 임시 디스크 공간을 기화시킵니다.

🏃 2. 운영 시나리오별 파이프라인 가동 표준 매뉴얼 (Runbook)

시나리오 A: 매일 아침 전일 정산 자동 크론잡 (CronJob)

시스템 스케줄러에 의해 자동으로 무옵션 기동됩니다. 문제가 발생하여 수동으로 전일 정산 결과를 리빌드해야 할 때는 포드 내부 엔트리포인트를 직접 실행합니다.

# 기본 일배치 구동 (어제 00:00:00 ~ 23:59:59 기준 전체 클러스터 자동 마감)
./run_pipeline.sh

결과 산출물 파일명: finops_report_all_YYYY-MM-DD.xlsx

시나리오 B: [임시 요구사항 1] 특정 기간 연산(Compute) 클러스터 분석

현업 부서의 요청이나 분기 결산을 위해 특정 날짜 범위를 타겟팅하고 스토리지 노드를 제외한 순수 연산 자원만 발라낼 때 가동합니다.

# 환경변수 주입 후 쉘 스크립트 온디맨드 집행
export START_DATE="2026-06-01"
export END_DATE="2026-06-07"
export CLUSTER_TYPE="COMPUTE"
./run_pipeline.sh

결과 산출물 파일명: finops_report_compute_2026-06-01_to_2026-06-07.xlsx

시나리오 C: [임시 요구사항 2] 특정 단독 클러스터 장기 시계열 재처리

특정 스토리지 전용 클러스터의 최근 30일간의 누적 낭비 평점과 팟의 실시간 카운트 가동 시간을 뽑아낼 때 가동합니다. 이미 MinIO 원천 레이크에 데이터가 완비되어 있다면 타노스 조회를 생략하여 초고속 모드로 리빌딩할 수 있습니다.

export DAYS=30
export CLUSTER_NAME="prod-storage-cluster"
export SKIP_STEP1="true" # ◀ Thanos API 호출 생략, 오직 MinIO 원천 Parquet 백엔드만 재스캔
./run_pipeline.sh

결과 산출물 파일명: finops_report_prod-storage-cluster_recent_30days.xlsx

📊 3. 최종 산출물 엑셀 리포트 탭별 구조 및 해석 가이드

운영자는 산출된 엑셀 통합 문서를 보고 어떤 팟이 인프라 공해를 유발하는지, 혹은 어떤 시스템이 가용성 장애 상태에 빠져 있는지 명확하게 진단 및 조치할 수 있어야 합니다.

[0번 탭] 0. 전사종합요약 (Global Operations Scorecard)

목적: 현재 뽑아낸 인프라 성적표의 조건 메타데이터와 전사 거버넌스 위반 상태 총량을 한눈에 보는 대시보드입니다.
운영자 해석 포인트:
자원 최적화 권고 대상 범위: 전체 수집된 팟 중 정확히 상위 30%에 해당하는 컷오프 행 수량을 보여줍니다. 2번 탭에 수록될 대상 크기입니다.
리소스 미설정 위반 팟 수 및 OOMKilled 장애 발생 팟 수가 전주 대비 스파이크를 쳤다면 클러스터의 전반적인 규격 준수 지표 및 가용성 평점이 악화된 것으로 판단합니다.

[1번 탭] 1. 파레토분석_NS (Cost-Driver Destination)

목적: 전사 6,000여 개 네임스페이스 중 길바닥에 버려지는 자원 낭비의 80%를 단독 유발하는 '핵심 비용 주범 부서'를 서열화하여 보여줍니다.
운영자 해석 포인트: is_top_80_percent_offender 컬럼이 True인 네임스페이스들만 상단 필터링하여 금주의 FinOps 자원 회수 공문 발송 대상 리스트로 격리합니다. 여기에 찍힌 부서장들에게 2번 탭의 상세 로우 명세를 첨부하여 최적화 롤백 티켓을 발행합니다.

[2번 탭] 2. 컨테이너낭비Top30P (★동적 최적화 권고 타겟 명세)

목적: 전체 컨테이너 전수 중 자원 누수량 순서대로 정렬하여 상위 30% 수량만큼 정확하게 슬라이싱한 진짜 돈 구멍 목록입니다.
운영자 해석 포인트: 팟의 실제 가동 시간(minutes_running) 가중치가 완벽하게 녹아있는 시간당 누수 비용 지표입니다. 여기에 수록된 팟들은 cpu_usage_p95 피크 하중을 넉넉히 감안해 주었음에도 불구하고 과도하게 큰 Request 사양을 선점하고 있는 팟들이므로 현업 개발자에게 구체적인 스케일 다운(Scale-Down) 수치를 제시할 수 있습니다.

[3번 탭] 3. 자원부족및OOM장애군 (Risk Mitigation)

목적: 비용 절감이 아닌 클러스터 안정성을 위해 플랫폼팀이 선제적으로 스펙을 올려주어야 하는(Scale-Up) 위험군 목록입니다.
운영자 해석 포인트: 주간 가동 중 단 한 번이라도 OOMKilled 사살 이력이 포착된 팟은 💥 OOM장애발생 상태가 부여되어 최상단에 강제 우선 정렬됩니다. 이 팟들은 메모리 상한선(mem_limit_max)이 너무 밭게 설정되어 비정상 강제 종료를 겪었음을 뜻하므로 즉각 한도를 늘리도록 강제 조치합니다.

[4번 탭] 4. 리소스미설정위반군 (Compliance Watchlist)

목적: 쿠버네티스의 기본 규격(YAML 정의)을 무시하고 Request나 Limit 설정을 공백으로 배포한 무법지대 좀비 워크로드 전수 조사 탭입니다.
운영자 해석 포인트: has_no_request 나 has_no_limit 이 단 하나라도 True인 팟들입니다. 이 팟들은 노드의 스케줄러 연산 오버헤드를 유발하고 이웃 팟의 자원을 잠식하는 주범이므로 어드미션 컨트롤러(Admission Controller) 차단 정책을 적용하기 전 경고장을 발송하는 기본 블랙리스트 명단이 됩니다.

💾 4. 리포트 항목별(컬럼별) 세부 명세서 (Data Dictionary)

모든 탭에서 공통 및 개별적으로 활용되는 24개 핵심 컬럼 항목의 데이터 타입, 연산 산출 공식 및 실무 해석 명세서입니다.

📋 4.1 인프라 식별 및 물리 분류 레이어 (Identity Layers)

1. `date` [String]

설명 및 기준 단위: 관측 정산 일자 (YYYY-MM-DD)
운영자 해석 의미: 모든 시계열 타임라인이 KST(한국 표준시) 정각 기준으로 락 정렬되어 인덱싱된 키입니다. 특정 요일에 배치가 몰려 자원 비용 스파이크가 튀었는지 종단간 추이 파악의 핵심 축이 됩니다.

2. `cluster` [String]

설명 및 기준 단위: 물리 노드의 호스트네임 명명 규칙을 파싱하여 역추적해 낸 클러스터 실명
운영자 해석 의미: 타노스 수집 레이어에서 라벨이 유실되거나 오염되어 인입되어도 config.py 시스템에 의해 prod-compute-cluster, prod-storage-cluster 등으로 완전 복구되어 정산 단위를 가르는 기준점이 됩니다.

3. `cluster_type` [String]

설명 및 기준 단위: 해당 인프라 자원의 용도 분류 표준 레이블 (COMPUTE / STORAGE)
운영자 해석 의미: 인프라 자원의 성격을 대변합니다. STORAGE 클러스터는 오브젝트 스토리지 가동을 위한 고정 기본 인프라 원가로 묶고, COMPUTE 클러스터는 현업 부서별 비즈니스 어플리케이션 가용 비용으로 분리 격리하여 정산 체계를 운영합니다.

4. `namespace` [String]

설명 및 기준 단위: 쿠버네티스 네임스페이스 식별자
운영자 해석 의미: 사내 6,000개 이상의 멀티 테넌트 환경에서 비용을 최종 귀속하고 책임 가이드라인을 발행할 '실제 예산 책임 부서/프로젝트 유닛'의 이름입니다.

5. `workload_type` [String]

설명 및 기준 단위: 팟 실명 정규식을 파싱해 추출한 오픈소스 기술 도메인 카테고리 레이블
운영자 해석 의미: 어떤 오픈소스 기술 스택에서 낭비가 발생하는지 계통 분류합니다. config.py 규칙에 따라 사번 기반으로 파편화된 HYPERSET을 단일 항목으로 압축 수렴하고, statsd를 포함한 AIRFLOW_SYSTEM, postgresql-backup을 저격 추출하여 시스템의 상주형 vs 휘발 배치형 성격을 정의합니다.

6. `node` [String]

설명 및 기준 단위: 팟이 실제로 배치되어 스케줄링된 물리 베어메탈 서버 호스트네임
운영자 해석 의미: config.py에 등재된 name1wk\d+ 규칙에 부합하여 입구 컷 통과 후 최종 생존한 물리 서버의 이름입니다.

7. `pod` / `container` [String]

설명 및 기준 단위: 쿠버네티스 팟 실명 및 컨테이너 단일 유닛 실명
운영자 해석 의미: 현업 개발 파트장에게 기술 자원 튜닝 요청(Jira 티켓 발행) 시 컨테이너 스키마 사양서에 명시할 '최종 실명 저격 주소'입니다.

⏱️ 4.2 자원 타임트래킹 및 물리 스펙 레이어 (Sizing Layers)

8. `minutes_running` [Integer]

설명 및 기준 단위: 해당 정산 범위 내에서 1분 해상도 시계열 데이터프레임 행 개수의 누적 총합 (Minutes)
운영자 해석 의미: [오픈코스트 원천 버그 해결 지표] 블랙박스형 유사 팟 묶음 연산으로 인해 가동 시간이 0분으로 뭉개지던 오류를 엔지니어링적으로 치료한 무결성 수치입니다. 팟이 실제 클러스터 디스크 상에 살아 숨 쉰 '순수 실가동 분 수'를 뜻합니다.

9. `cpu_request_max` [Float]

설명 및 기준 단위: 관측 기간 내 해당 컨테이너에 선언된 최대 CPU 요청량 사양 수치 (Cores)
운영자 해석 의미: 컨테이너가 쿠버네티스 스케줄러로부터 노드의 하드웨어에서 독점적으로 보장받아 묶어버린 공급 자원의 크기입니다. 현업이 청구받는 인프라 비용 분모의 원천입니다.

10. `cpu_limit_max` [Float]

설명 및 기준 단위: 관측 기간 내 해당 컨테이너에 선언된 최대 CPU 제한 상한선 수치 (Cores)
운영자 해석 의미: 컨테이너가 하이퍼바이저 커널 단에서 최대로 뿜어낼 수 있는 초과 스로틀링 임계선입니다. 이 값이 cpu_request_max와 완전히 일치해야 클러스터 내 최고 등급의 자원 보장 안정성 등급인 Guaranteed QoS 클래스를 영위하게 됩니다.

11. `cpu_usage_p95` [Float]

설명 및 기준 단위: 실시간 CPU 사용량 중 상위 95% 피크 지점의 단일 실측값 (Cores)
운영자 해석 의미: [FinOps 핵심 가드레일] 평균값(Average)의 착시에 빠지면 현업의 주기적인 업무 피크 하중 스파이크를 놓쳐 최적화 가이드 배포 시 배치가 터지는 대형 장애를 유발합니다. 따라서 상위 95% 컷오프 피크 수치를 실효 사용량의 기준으로 삼아 현업의 성능 안정 마진을 100% 보장합니다.

12. `mem_request_max` [Float]

설명 및 기준 단위: 컨테이너에 선언된 최대 Memory 요청량 사양 (GB 단위 정규화 완료)
운영자 해석 의미: 원천 바이트 단위를 기가바이트(GB) 규격으로 나눈 값입니다. 메모리 자원을 노드 디스크 풀에서 독점 격리 선점한 물리 공급 한도입니다.

13. `mem_limit_max` [Float]

설명 및 기준 단위: 컨테이너에 선언된 최대 Memory 제한 상한선 (GB 단위 정규화 완료)
운영자 해석 의미: 메모리는 CPU와 달리 압축이 불가능한 자원(Non-Compressible)이므로, 컨테이너의 실시간 사용량이 이 제한 한도 수치를 터치하는 즉시 리눅스 커널 프로세스 사살 규칙에 의거해 팟이 공중 분해(OOMKilled)됩니다.

14. `mem_usage_p95` [Float]

설명 및 기준 단위: 실시간 메모리 작업 세트(Working Set Bytes) 사용량 중 상위 95% 피크값 (GB)
운영자 해석 의미: 팟이 가동되면서 메모리 내부에서 실제로 페이지를 점유한 하이 워터마크(High Watermark)의 실효 스펙 수치입니다.

📉 4.3 FinOps 고정밀 시간 가중치 및 거버넌스 판정 레이어 (FinOps Logic Layers)

15. `cpu_allocated_core_hours` [Float]

공식: $\text{cpu\_request\_max} \times (\text{minutes\_running} / 60)$
운영자 해석 의미: 공급 자원의 시간 가중치 총합 비용 분모 단위인 총 할당 코어 시간입니다. 사내 코어당 시간 단가(KRW)를 곱하면 즉시 화폐 가치로 환산되는 기초 정산 원부입니다.

16. `cpu_usage_core_hours` [Float]

공식: $\text{cpu\_usage\_p95} \times (\text{minutes\_running} / 60)$
운영자 해석 의미: 현업 어플리케이션이 공급받은 인프라 위에서 실제 유효하게 연산 처리 트래픽을 소모한 총 유효 코어 시간입니다.

17. `cpu_waste_core_hours` [Float]

공식: $\text{cpu\_allocated\_core\_hours} - \text{cpu\_usage\_core\_hours} \text{ (하한선 0 제한)}$
운영자 해석 의미: [★최우선 FinOps 핵심 척도] 사용자가 자원을 선점해 잠가놓고는 피크 타임 때조차 전혀 쓰지 않고 공중으로 날려버린 '순수 CPU 자원 낭비 총량'입니다. 2번 탭은 이 컬럼을 기준으로 전사 내림차순 정렬됩니다.

18. `mem_allocated_gb_hours` [Float]

공식: $\text{mem\_request\_max} \times (\text{minutes\_running} / 60)$
운영자 해석 의미: 공급받은 총 메모리 시간 누적 스케일 지표입니다.

19. `mem_waste_gb_hours` [Float]

공식: $\text{mem\_allocated\_gb\_hours} - \text{mem\_usage\_gb\_hours} \text{ (하한선 0 제한)}$
운영자 해석 의미: 메모리를 과도하게 알박기하여 타 부서의 대형 배치를 Pending 시키고 인프라 유연성을 마비시킨 '순수 메모리 낭비 총량' 지표입니다.

20. `cpu_shortage_cores` [Float]

공식: $\text{cpu\_usage\_p95} - \text{cpu\_request\_max} \text{ (하한선 0 제한)}$
운영자 해석 의미: 팟이 보장받은 Request 자원 한도를 넘어 노드의 공용 유휴 버스팅 자원을 침범해 위태롭게 가동된 '인프라 공급 부족 수치'입니다. 0보다 크면 성능 병목 및 위험군으로 분류됩니다.

21. `is_oom_killed` [Boolean]

설명 및 기준 단위: 관측 기간 중 쿠버네티스 원천 상태 코드 내 OOMKilled 사살 이력 포착 플래그 (True / False)
운영자 해석 의미: 해당 주간에 자원 스펙 설계 미비로 커널에 의해 강제 살해된 장애의 팩트 지표입니다.

22. `has_no_request` / 23. `has_no_limit` [Boolean]

설명 및 기준 단위: YAML 명세 사양서에 자원 한도값 선언 누락 플래그 (True / False)
운영자 해석 의미: 규칙 위반 좀비 팟을 단속하는 잣대입니다. True가 찍힌 팟들은 클러스터 자원 관리 거버넌스를 어긴 대상입니다.

24. `status` [String]

설명 및 기준 단위: 위 지표들을 조합해 운영자가 필터링하기 쉽도록 바인딩한 최종 상태 텍스트
운영자 해석 의미: 조치 액션 플랜을 매핑하는 최종 등급 평점입니다.
💥 OOM장애발생: 최우선 가용성 복구 지원군 대상
⚠️ Request부족: 선제적 사양 증설 권고 대상
📉 과다할당: 자원 회수 및 다운사이징 단속 대상
✅ 최적화완료: 거버넌스 규격을 준수하는 우수 모범 워크로드

🛠️ 5. 운영자 조치 처리 절차 가이드라인 (Standard Action Plan)

엑셀 리포트 분석 후 신규 운영자가 현업 부서에 발행해야 할 표준 조치 가이드 프레임워크입니다.

엑셀 검출 탭 및 조건	판정 상태 레이블	운영자 현업 가이드라인 조치 표준 (Action Plan)

| 3번 탭 상단 정렬 및

is_oom_killed == True | 💥 OOM장애발생 | [가용성 Scale-Up] 즉시 해당 부서에 장애 경보를 발행합니다. 현재 설정된 mem_limit_max 수치가 mem_usage_p95 피크 스파이크를 견디지 못하므로, 최대 메모리 제한량을 실측 피크치 대비 최소 1.2배(20% 버퍼 마진) 이상 증설하여 Helm Chart를 리배포하도록 강제합니다. |
| 2번 탭 상위 라인 정렬 및

cpu_waste_core_hours 고부하 팟 | 📉 과다할당 | [비용 스케일 다운] 자원 회수 공문을 발행합니다. 해당 개발 파트장에게 엑셀 로우 행을 증거로 제시하고, 과도하게 잡힌 cpu_request_max 사양을 본 엑셀에 실측 수치로 포착된 cpu_usage_p95 지점까지 하향 조정하여 인프라 선점 자원을 반납하도록 조치합니다. |
| 4번 탭 목록 전체 | 리소스미설정위반 | [클린 거버넌스 단속] YAML 스펙 위반 조치서를 발행합니다. "차기 분기 클러스터 격리 정책 제어 레이어(Admission Webhook) 가동 시 Request/Limit이 없는 팟은 배포 단계에서 무조건 거절(Reject)될 예정이오니, cpu_request_max 수치 자리에 금번 실측된 cpu_usage_p95 값을 기입하여 사양 명세서를 규격화하십시오"라고 배포 규격을 강제 통보합니다. |

Young-Kyoo Kim

engineer

이전 포스트

26J30e2

다음 포스트

26J30f

[운영 표준 지침서] 클러스터 FinOps 자원 효율성 데이터 레이크하우스 운영 가이드

🏗️ 1. 아키텍처 및 파이프라인 데이터 흐름 개요

🏃 2. 운영 시나리오별 파이프라인 가동 표준 매뉴얼 (Runbook)

시나리오 A: 매일 아침 전일 정산 자동 크론잡 (CronJob)

시나리오 B: [임시 요구사항 1] 특정 기간 연산(Compute) 클러스터 분석

시나리오 C: [임시 요구사항 2] 특정 단독 클러스터 장기 시계열 재처리

📊 3. 최종 산출물 엑셀 리포트 탭별 구조 및 해석 가이드

[0번 탭] 0. 전사종합요약 (Global Operations Scorecard)

[1번 탭] 1. 파레토분석_NS (Cost-Driver Destination)

[2번 탭] 2. 컨테이너낭비Top30P (★동적 최적화 권고 타겟 명세)

[3번 탭] 3. 자원부족및OOM장애군 (Risk Mitigation)

[4번 탭] 4. 리소스미설정위반군 (Compliance Watchlist)

💾 4. 리포트 항목별(컬럼별) 세부 명세서 (Data Dictionary)

📋 4.1 인프라 식별 및 물리 분류 레이어 (Identity Layers)

1. date [String]

2. cluster [String]

3. cluster_type [String]

4. namespace [String]

5. workload_type [String]

6. node [String]

7. pod / container [String]

⏱️ 4.2 자원 타임트래킹 및 물리 스펙 레이어 (Sizing Layers)

8. minutes_running [Integer]

9. cpu_request_max [Float]

10. cpu_limit_max [Float]

11. cpu_usage_p95 [Float]

12. mem_request_max [Float]

13. mem_limit_max [Float]

14. mem_usage_p95 [Float]