26Y02x2

Young-Kyoo Kim·2026년 7월 2일

설계하신 데이터 파이프라인 스케줄링과 자원 거버넌스 아키텍처는 수백 대 이상의 대규모 멀티 클러스터 환경을 운영하는 엔터프라이즈 플랫폼 관점에서 매우 정석적이고 견고한 FinOps(비용 효율화)/SRE 프레임워크입니다.

구축하신 시스템의 목적 부합성을 최종 검증해 드리고, 매주 개발 부서 담당자들과 실무 협의(Communication) 시 무기로 활용하실 수 있는 ‘데이터 기반 자원 조정 가이드라인 핵심 자료’를 정리해 드립니다.

Part 1. 파이프라인 아키텍처 및 컨셉 점검 (Validation)

구상하신 운영 방식은 목적에 100% 부합하며, 다음과 같은 아키텍처적 강점을 가집니다.

글로벌 Fetch와 클러스터별 루프 분리 (step1 ➡️ step2~6)

대규모 환경에서 프로메테우스 스크랩(Scrape) 부하를 최소화하기 위해 글로벌 메트릭을 새벽에 단 한 번 가져오고(step1), 다운스트림 가공 과정만 도메인별(COMPUTE, STORAGE) 서브폴더 파티션으로 격리해 순회하는 구조는 데이터 레이크하우스 구축 시 성능 경합을 피할 수 있는 가장 훌륭한 선택입니다.

AIStor 내 데이터 생명주기 및 적재 규칙

raw/, enrich/, excel/로 일단위 보관 체계를 잡은 것은 원시 로그 추적 및 장기 트렌드 분석을 위해 완벽한 구조입니다.

배치 범위의 유연성 (Daily vs. Weekly/Monthly)

start-date와 end-date를 파라미터로 받아 하방 파이프라인을 재구동할 수 있게 설계한 덕분에, 주간 단위 배치 워크로드의 변동성(Spike)이나 월간 정산 주기에 맞춰 유연한 통계 윈도우(Time-window)를 가져갈 수 있습니다.

Part 2. 개발 담당자 협의용 자원 조정 가이드라인 (기본 자료)

개발자들은 대개 서비스 안정성을 이유로 자원 축소(Downscaling)에 보수적(반발)입니다. 따라서 협의 시에는 감정적 설득이 아닌, "우리가 수집한 P95 데이터와 커널 가시성(Throttling/OOM)"을 기반으로 객체화된 가이드를 제시해야 합니다.

1. 자원 조정의 대원칙 (Platform & Dev Shared Goal)

목적: 애플리케이션의 안정성(Reliability)을 최우선으로 확보하되, 무의미하게 버려지는 선점 자원(Locked Resource)을 회수하여 전체 인프라의 가용 슬롯을 확보함.
약속: 가이드라인에 따라 자원을 조정한 후 모니터링 중 장애 징후가 보이면, 즉시 이전 상태로 Rollback 하거나 즉각 재조정(Upscaling)을 보장함.

2. 유형별 자원 조정 판단 기준 및 권장 액션 (Thresholds)

주간 데이터에서 최소 7일 이상 지속(지속성 7회 이상) 감지된 워크로드를 대상으로 아래 기준을 적용합니다.

🔴 유형 A. 과다 할당 위반군 (Over-allocated / Waste)

개발팀이 안정성을 이유로 필요 이상의 자원을 선점해 둔 상태입니다.

판단 기준: 7일간 CPU/Memory 평균 실효 활용률(Util) < 15%이면서 동시에 P95 Usage가 Request의 30% 미만인 경우.
가이드 가치 (Talk): "현재 할당된 스펙의 80% 이상이 단 한 번도 사용되지 않고 낭비되고 있어 타 모듈의 파드 배치를 방해하고 있습니다."
조정 가이드: Request 조정: 관측된 `P95 최대 사용량 1.25 (25% 마진)` 수준으로 Request 하향 조정을 권장합니다.
Limit 설정: Limit은 현재 값을 유지하거나 Request의 2배 수준으로 확보하여 급작스러운 스파이크는 흡수할 수 있도록 안전장치를 제공합니다.

🟡 유형 B. 자원 부족 및 병목 위험군 (Shortage / Performance Risk)

실제 서비스 장애(OOM)가 났거나 커널 단에서 연산 속도 제한이 걸려 성능이 저하되고 있는 위험 상태입니다.

판단 기준: 1. Memory: 관측 기간 내 OOMKilled(is_oom_killed) 1회 이상 발생 또는 Memory RSS 사용량이 Limit의 90% 상회.

CPU: CFS Throttling Peak(cpu_throttled_max) > 20% 상태가 빈번하여 애플리케이션 지연(Latency) 유발 처리가 확인된 경우.

가이드 가치 (Talk): "해당 모듈은 리소스 부족으로 인해 컨테이너가 강제 종료되거나 커널 단에서 연산 스로틀링(지연)이 걸려 서비스 품질에 악영향을 주고 있습니다."
조정 가이드:
Memory: 즉시 Limit 규격을 기존 Limit * 1.3 (30% 상향) 조정하거나, 가공 원부의 Mem RSS 최고점 대비 20% 마진을 두어 메모리 누수(Leak) 여부 확인을 요청합니다.
CPU: Request를 CPU P95 수준으로 현실화하고, Limit을 대폭 늘려주거나 자바/Go의 런타임 스레드 풀 수치를 k8s 쿼터와 매칭하도록 가이드합니다.

🟠 유형 C. 규격 미설정 위반군 (Violation / Missing Settings)

Request나 Limit 중 하나라도 누락되어 노드 전반의 동반 자원 고갈(Noisy Neighbor)을 유발하는 상태입니다.

판단 기준: has_no_request == True 또는 has_no_limit == True
가이드 가치 (Talk): "자원 설정이 누락되어 해당 파드가 유실되거나 노드 내 다른 정상 서비스의 자원을 침범할 위험이 있습니다. 클러스터 거버넌스 규격 준수가 강제됩니다."
조정 가이드: 지난 7일간 수집된 실제 daily_enriched 데이터의 평균 사용량을 기반으로 최소한의 Request/Limit 세팅을 의무화합니다.

3. 개발 담당자 커뮤니케이션용 핵심 지표 용어 해석 사전

개발자들이 인프라 메트릭을 쉽게 이해할 수 있도록 리포트 전달 시 아래 용어 설명을 동봉합니다.

P95 사용량 (95th Percentile): 전체 실행 시간 중 상위 5%에 해당하는 피크 수치입니다. 평균치만 보고 자원을 줄이면 피크 시 서비스가 터지므로, 플랫폼 팀은 개발팀의 안정성을 보장하기 위해 이 P95 수치를 기준선으로 대화합니다.
CPU Throttling (스로틀링): 컨테이너가 배정된 CPU 한도(Limit)를 초과하여 커널이 강제로 프로세스를 멈추고 대기시킨 비율입니다. 이 수치가 높으면 소스 코드가 아무리 좋아도 인프라 쿼터 제약 때문에 API 응답 속도가 느려집니다.
Memory RSS vs WorkingSet: WorkingSet은 커널 캐시를 포함한 느슨한 지표이지만, RSS는 프로세스가 물리 메모리에 직접 상주 시킨 진짜 자원 소모량입니다. OOMKilled는 이 RSS가 Limit을 칠 때 발생하므로, 3번 시트의 RSS 데이터를 보고 메모리 증설 여부를 정확히 판단할 수 있습니다.

Part 3. 주간 커뮤니케이션 가동 워크플로우 예시 (일주일에 한번)

매주 월요일 아침, 주간 lookback 파이프라인을 돌려 나온 excel 결과물에서 가장 낭비가 심한 상위 5개 네임스페이스(Step6 파레토 Critical 등급)와 장애 위험 상위 5개 네임스페이스를 추출하여 아래 템플릿 형태로 던져 소통하시면 됩니다.

[주간 자원 거버넌스 공람 템플릿 예시]

수신: 메인 모듈 개발 리드

발신: 플랫폼 DevOps 파트

내용: 지난 주간 COMPUTE 클러스터 정산 결과 기반 최적화 대상 권고

대상 워크로드: order-api-pod (Namespace: production-order)

인프라 진단 데이터:

할당 자원: CPU Request 8 Cores / Memory Limit 16 GB

실제 사용량: CPU P95 0.8 Cores (활용률 10%) / Mem RSS Peak 4 GB (활용률 25%)

특이사항: 7일 연속 피크 타임에도 자원 소모량 변동 없음 (과다 할당 등급: Critical)

플랫폼 팀 제안 권고사항:

CPU Request를 8 Cores ➡️ 2 Cores로 하향 조정 제안 (Limit은 8 Cores 유지하여 스파이크 보장)

회수된 자원은 다음 주 배포 예정인 신규 인프라 데이터 레이크 파드 배치 비용으로 재활용됩니다.