FinOps, 캐파 계획, 성능/비용 트레이드오프

**단위경제(Unit Economics)**를 KPI로 고정: ₩/req, ₩/세션, ₩/주문, ₩/MAU
태깅/라벨링 표준화: env, app, service, team, org, feature 없으면 비용 분석 불가
캐파 계획: Little’s Law로 동시성=RPS×지연 산출 → HPA/KEDA/노드수 역산
빠른 절감 8가지: 캐시 히트율↑, Edge 캐시, ARM·스팟 혼합, 빌드 캐시, 로그 샘플링, Dev 스케줄 종료, 이미지 다이어트, HPA scaleDown 공격적
구성의 비용을 숫자로 비교: SSG/ISR vs SSR, 캐시 미스 1건의 비용 vs Redis 1GB/월
구매전략: 온디맨드 → Savings Plans/RI, 스토리지 라이프사이클, 데이터 전송 최소화

1) 단위경제 템플릿(복붙용)

서비스별로 한 눈에 보이게 요약하세요.

A. 핵심 지표

트래픽: RPS_peak, 일요청수, MAU
성능: p95 API, p95 TTFB(SSR)
비용: 월 총비용(₩), 컴퓨트/DB/스토리지/전송/3rd 분해
단위경제:
- ₩/req = 월총비용 / 월요청수
- ₩/세션 = 월총비용 / 월세션수
- ₩/주문 = 월총비용 / 월주문수

B. 분해 뷰(예시)

비용 기여 상위 5
1) RDS(40%)  2) EKS 노드(25%)  3) 데이터 전송(12%)
4) 로깅 스토리지(10%)  5) 이미지 처리(6%)

C. 레버(조정 손잡이)

캐시 히트율 +10% → DB QPS -30% → ₩/req -18% (실측 반영)
ARM 전환(50%) → 컴퓨트 단가 -20~30%
로그 보존 30→14일 → 스토리지 -40%

2) 비용 가시성(태깅·지표·알람)

클라우드 태그/라벨 표준: env(dev/stage/prod), app(api/web/worker), service, team, org, feature. IaC/Helm 차트에 강제.
예산/알람: 월 예산의 50/80/100% 구간 알람, 전일 대비 +X% 급등 알람.
메트릭으로 연결: RED/USE 대시보드 옆에 ₩/req, ₩/세션 패널 추가(커스텀 게이지).

팁: trace_id에 요청당 바이트/외부호출 횟수 태그를 넣어두면 비용 급증 원인을 트레이스에서 바로 확인 가능.

3) 캐파(용량) 계획 ─ 수식으로 끝내기

Little’s Law: 동시성(N) = 도착률(λ=RPS) × 평균 체류시간(W=평균 지연).

예)

피크 RPS=800, 평균 지연 W=0.12s → N≈96 동시 처리 필요
ASGI 한 파드가 안정적으로 120 동시 처리(limit-concurrency=120)라면,
- 파드 1개로 충분이지만 리던던시 2개 + 버퍼 30% → 파드 3개
DB 커넥션: 파드×(파드당 최대 세션) ≤ PgBouncer 허용치(여유 20%)

역산 표

목표 p95 / RPS_peak → 동시성 N
워커/파드 처리량 qps/pod → 파드 수
TopologySpread/PDB 고려해 minReplicas ≥ 2, HPA max는 피크×1.5

4) 캐시 vs DB 비용 모델(빠른 의사결정)

물음: “Redis 2GB 늘리는 게 이득인가, DB 증설이 이득인가?”

가정:
- DB 미스 1건 비용 ≈ (DB vCPU 시간 + IO + 네트워크) 단가 환산
- Redis 히트 1건 비용 ≈ (메모리 GB-월/초 + 네트워크)
- 히트율 H일 때 평균 비용: C = H·C_hit + (1−H)·C_miss
의사결정: ΔC = (C_before − C_after)가 Redis 증설비용보다 크면 캐시 증설.

실무 팁: “핫 조회 TOP 10 엔드포인트”에 대해 **히트율 목표(≥85%)**와 미스당 비용을 메모해 두면 빠르게 판단 가능.

5) SSR/ISR/Static의 비용·성능 트레이드오프

SSG/ISR: CDN 히트 시 거의 0원(요청당) + 초저지연. 빌드/리밸리date 코스트 존재.
SSR(스트리밍): 사용자별 페이지/세션 의존 시 필수. CPU/메모리·오리진 전송 비용↑.
룰: 캐시 가능한 건 ISR/태그 무효화, 사용자 맞춤만 SSR.
측정: 페이지별 TTFB와 오리진 히트율 vs 월 비용을 같은 보드에 그라프.

6) “48시간 내” 절감 플레이북

캐시 키/TTL 재설계: 상위 3개 조회 엔드포인트 히트율 +20%
Edge 캐시: 정적/공개 API Cache-Control + ETag 기본값 강화
ARM(Graviton) 노드 풀로 web/worker 절반 이전(멀티아치 빌드)
Dev/Preview 환경 스케줄 종료: 20:00–08:00, 주말 오프
KEDA minReplicaCount: 0(워커) + 반응형 scaleDown(쿨다운 2–5분)
로그 샘플링/필터링: 헬스체크/정상 2xx는 샘플 또는 집계만
이미지 다이어트: python:slim/node:alpine, readOnlyRootFS → 디스크/전송↓
데이터 전송 절감: 이미지 원본을 리사이즈 후 CDN으로만 노출

7) 2주 실행 플랜(템플릿)

태그/라벨 표준 릴리스(미준수 배포 차단)
“단위경제” 대시보드(₩/req, ₩/세션, 오리진/전송 분해)
상위 비용 리소스 5개 권고안: ARM 전환/스팟/라이프사이클/샘플링
캐파 계획 표(RPS→파드→노드→DB연결) 작성 & HPA/KEDA 상수 업데이트
비용 알람(50/80/100%) + 전일 대비 급등(>25%) 룰
CI 빌드 캐시 최적화(모노레포 캐시 키, cache: gha 전면 적용)

8) 로그/메트릭/트레이스 비용 통제

로그: 레벨 기본 INFO → 라우팅으로 에러/경고 우선 수집, 2xx 대량 엔드포인트는 샘플링 또는 집계 로그(분당 카운트).
메트릭: 고카디널리티 라벨 금지(사용자ID/세션ID X). 히스토그램 버킷 5~8개로 정리.
트레이스: Tail Sampling(에러/느림만 100%, 정상 5–10%). 보존 7–14일.

9) 빌드/테스트 비용 절감

캐싱: Node npm ci + 캐시, Docker buildx GHA 캐시
테스트 병렬/필터: 변경 경로만 실행(모노레포 워크스페이스), E2E는 나이트리 빌드로 집중
프리뷰 TTL: 자동 소멸(48–72h), 스토리지/DB 스냅샷은 보관 7일

10) 네트워크 비용(가끔은 핵심)

CDN 히트율 목표 ≥ 90%(정적·공개 API)
이미지: WebP/AVIF, next/image sizes 지정(7편)
지역 간 전송 줄이기: DB/워커 같은 AZ 배치, 크로스리전 전송은 DR용만
대용량 다운로드: 프리사인 URL로 직접 S3에서

11) 구매 전략(Compute/Storage)

온디맨드 → Savings Plans/RI: 베이스라인 50–70% 커버(12–36개월 혼합)
스팟: 워커/비핵심, PDB+재시도/큐로 탄력성 보강
스토리지: S3 Standard → IA(30d) → Glacier(90d) 라이프사이클, 로그는 14–30일

12) 운영 정책(문서로 못 박기)

목표치: ₩/req, ₩/세션, 캐시 히트율, CDN 히트율, 전송량/사용자
결정 규칙: “SSR → ISR 전환 기준”, “DB 스케일 vs 캐시 증설 기준”, “에러버짓/비용버짓 상충 시 우선순위”
분기별 리뷰: 인스턴스 타입/아키텍처(ARM) A/B, 로그 보존/샘플링 재평가

13) “복붙” 모음

A. HPA 다운스케일(비용 우선)

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
      - type: Percent
        value: 50
        periodSeconds: 60

B. 워커 KEDA 0까지 줄이기

spec:
  minReplicaCount: 0
  cooldownPeriod: 120
  triggers:
    - type: aws-sqs-queue
      metadata: { queueLength: "100", ... }

C. Loki 로그 드롭(헬스체크/잡음)

pipeline_stages:
- match:
    selector: '{app="api",status="200",path="/healthz"}'
    action: drop

D. 비용 대시보드(커스텀 메트릭 예시)

# req당 비용(추정): (컴퓨트(₩/초)×CPU사용초 + 전송(₩/바이트)×응답바이트) / 요청수
(sum(rate(app_cpu_seconds_total[5m]))*COST_PER_CPU_SEC
 + sum(rate(app_response_bytes_total[5m]))*COST_PER_BYTE)
/
sum(rate(http_requests_total[5m]))

COST_PER_CPU_SEC, COST_PER_BYTE는 월 청구서에서 추정치로 업데이트.

E. Dev 네임스페이스 스케줄러(끄기/켜기)

# 평일 20:00 off
kubectl scale deploy -n dev --replicas=0 --all
# 평일 08:00 on (HPA가 다시 확장)

마무리

비용 최적화는 “보이는 만큼 줄일 수 있다”가 법칙이에요.
단위경제를 수치로 고정하고, 캐파를 수식으로 역산, 캐시·엣지·ARM·스팟 같은 레버를 규칙으로 굳히면 성능을 해치지 않고 비용을 내려갈 수 있습니다.

[카테고리:] 미분류

비용·운영 최적화