Data Eng Wiki

Cost and Efficiency

17 min read

Cost and Efficiency

“튜닝은 시간을 살 뿐 무한한 스케일을 사지 않는다. 기저 데이터 모델이 무제한 성장을 허용하면 결국 아키텍처 자체가 바뀌어야 한다.”

개요

비용 최적화 사례는 대개 “X% 절감”이라는 숫자로 소비되지만, 어디를 건드려서 그 숫자가 나왔는지가 이전 가능한 부분이다. 이 토픽은 여러 사례에서 반복되는 레버의 종류, 비대칭 원칙, 그리고 튜닝으로 못 넘는 선을 정리한다.

가장 중요한 구분 하나:

비용 곡선이 워크로드 곡선보다 가파르게 올라가면, 그건 튜닝 문제가 아니라 아키텍처 신호다.

1. 비용은 한 종류가 아니다

비용 축무엇이 돈을 쓰나대표 증상대표 레버
컴퓨트 (배치)executor·slot 시간OOM, spill, 재시도per-row 폭 축소, join 전략, 파티션
컴퓨트 (스트리밍)24/7 상주야간·주말 유휴오토스케일링, in-place rescale
스토리지/IO파일 수, 커밋, API 호출메타데이터 폭증조율 단위 분리, 카탈로그 위치
조율(coordination)컨트롤 플레인 객체 수서버는 여유, 운영이 느림저장 단위 ≠ 조율 단위
유휴(unused spend)할당 안 된 노드 용량bin-packing 실패동적 프로비저닝, 형상 표준화
토큰/추론컨텍스트 × 호출대화형 BI 폭주verified query 승격, 배칭

핵심: 조율 비용과 유휴 비용은 대시보드에 “컴퓨트 비용”으로 뭉뚱그려 나타나서 원인 진단이 어렵다. → Control Plane Cardinality, Data Engineering FinOps

2. 반복되는 레버 — 사례와 대가

레버사례효과대가
per-row 폭 축소Netflix member-sessionizer — Option 언박싱, event bag 슬림화peak 메모리 112% → 58%, spill 0스키마 변경, 다운스트림 조율
AQE broadcast 임계 조정같은 사례 — 런타임 임계만 10MB로executive 메모리 ~3.1GB 확보컴파일 타임 플래닝은 그대로 유지해야
스트리밍 오토스케일링Netflix Flink (1세대)리소스 25~45%클러스터 단위만 조절
vertex별 오토스케일링Netflix Flink (OSS, TPR 기반)연환산 지출 58%, 약 $110만지표 신뢰성·안전 가드 필요
오토스케일 + 동적 노드Lyft (Apache operator + Karpenter)연 수백만 달러 과프로비저닝 해소오토튜닝↔in-place 충돌, 2-tier 정책 필요
전용 엔진으로 교체Booking.com 벡터 DB동일 recall/SLO에서 ~40%마이그레이션 (추상화 없으면 비쌈)
쓰기 레이아웃 최적화Fabric V-Order빌드 컴퓨트 **+8%**로 쿼리 capacity 2.8배(3,769→1,332 CU)쓰기 프리미엄, 설정 발견성 낮음
카탈로그 위치 변경DuckLake vs Iceberg COW (CDC flush)269,344ms → 6,576ms (~40배), 오브젝트 806→405엔진 상호운용성 포기
조율 단위 확대Pinot Segment Group컨트롤 플레인 카디널리티 ~2자릿수브로커 pruning이 거칠어짐
파이프라인 재설계CDC 비용 150/월~95%재구축 비용
Spark 파이프라인 튜닝최대 파이프라인 52% 절감—지속적 관리

⚠️ 표의 숫자를 그대로 기대치로 쓰지 마라. 대부분 그 조직의 특정 병목에 맞은 레버였고, 같은 레버가 다른 병목에서는 0을 산다.

3. 세 가지 비대칭 — 여기가 실무 판단이 갈리는 곳

① 쓰기는 한 번, 읽기는 매일

V-Order가 이 원칙의 가장 깨끗한 사례다 — 빌드 컴퓨트를 8% 더 쓰고 쿼리 capacity를 2.8배 줄인다.

쓰기 프리미엄은 한 번 내지만 쿼리는 매일 낸다.

같은 논리가 의미의 pre-modeling에도 적용된다 — 비정형 데이터에 AI tagger를 한 번, 오프라인으로 돌려 구조를 박아두면, 이후 모든 질문이 GROUP BY로 싸진다. 매 질문마다 10만 건 전사를 LLM으로 파싱하는 것과 비교하면 자릿수 차이다. → Consensus Engineering

판단 규칙: 읽기 빈도 ÷ 쓰기 빈도가 클수록 쓰기 시점 투자가 정당화된다.

② 스케일 다운 실수가 스케일 업 실수보다 비싸다

스케일 업 실수는 돈을 쓰고, 스케일 다운 실수는 서비스를 죽인다.

너무 깊게 자르면 CPU가 포화되고 lag이 급증하는데, 지표 윈도우와 stabilization period가 재시작마다 다시 쌓여야 해서 즉시 반응할 수 없다. 스스로 판 구덩이에서 나오는 데 몇 사이클이 걸린다.

Netflix의 대응: 커뮤니티 기본값 0.7보다 낮은 목표 활용률 0.45 — 의도적으로 약간의 효율을 안정성과 교환한다.

큰 stateful 잡에는 적고 차분한 rescale이 marginal 비용만큼의 가치가 있다.

→ Stream Autoscaling

③ 총량이 아니라 단위 폭을 먼저 봐라

Netflix Spark 사례의 교훈:

메모리 문제에서는 총 데이터 볼륨만이 아니라 per-row 폭을 먼저 보라. 큰 필드 타입, Option boxing, 뚱뚱한 미사용 문자열이 전부 collect_list bag 안에서 누적된다.

collect_list가 각 bag을 통째로 메모리에 버퍼링하므로 OOM은 총 데이터셋 크기가 아니라 개별 bag 크기가 주도했다. 레거시 파이프라인이 같은 행 수를 크래시 없이 처리했다는 사실이 그 증거였다.

반직관적 따름정리: 행을 좁히면 OOM이 더 빨리 올 수도 있다 — 테이블이 auto-broadcast 임계 아래로 떨어져 플래너가 broadcast join으로 전환하고, broadcast는 build-side를 executor 메모리에 고정하기 때문이다.

4. 튜닝으로 넘을 수 없는 선

이 토픽에서 가장 중요한 절제(節制)다.

슬림화와 unboxing이 헤드룸을 샀지만 근본적 데이터 모양을 바꾸지는 않았다. 가장 큰 교훈은 튜닝이 시간을 살 뿐 무한한 스케일을 사지 않는다는 것이다. 기저 데이터 모델이 무제한 행 성장을 허용하면 튜닝만으로는 구할 수 없다 — 결국 아키텍처 자체가 바뀌어야 한다.

Netflix는 4개 수정으로 파이프라인을 깨끗이 돌게 만들었지만, 세션 전체의 event bag을 단일 행으로 집계한다는 데이터 모양은 그대로 남았다. 상류 텔레메트리가 속성을 추가하면 우리 쪽 코드 한 줄 안 바꿔도 메모리 압력이 돌아온다.

같은 신호가 다른 곳에도 있다:

신호사례함의
하드웨어로 엔진 한계를 보상 중OpenSearch 벡터 워크로드 — “수용 가능한 성능을 얻으려면 지속적 튜닝과 점점 큰 클러스터가 필요했다”엔진 교체 시점
메타데이터 때문에 물리 크기를 왜곡 중큰 세그먼트가 바람직해서가 아니라 카디널리티를 줄이려고조율 단위 분리
임계 아래로 유지하려고 인위적 경계 생성스케일링 한계 때문에 테이블을 쪼갬같은 위
유지보수가 가치 창출을 압도”위에 만든 고가치 유스케이스를 가능하게 하는 것보다 인프라를 관리하는 데 더 많은 시간을 쓰고 있었다”플랫폼 결정

진단 질문: 지금 쓰는 노력이 헤드룸을 사는 것인가, 아니면 실링을 옮기는 것인가?

5. 유휴 비용 — 눈에 안 보이는 축

8코어 32GB 노드에 지불하면서 4코어 16GB만 할당하면 노드 비용의 절반이 미사용이다. 이 비용은 어떤 잡의 청구서에도 나타나지 않는다.

Lyft에서 드러난 연쇄가 교훈적이다:

  1. 오토튜닝 도입 → 앱마다 CPU:메모리 비율이 튜닝 사이클마다 달라짐
  2. → 1:4 / 1:8 power-of-two 정적 노드 풀의 bin-packing 가정이 깨짐
  3. → Karpenter로 파드가 실제 필요로 하는 것에 기반한 on-demand 프로비저닝
  4. → 부수 효과: “most-allocated” 스케줄러 + 오토스케일링 재시작이 파드를 밀집 노드로 이동시켜 저활용 노드를 떨어낼 기회를 만듦

그리고 Netflix가 별도로 지목한 세 번째 절감 요인:

균일한 컨테이너 차원 채택이 더 나은 bin-packing과 더 세밀한 스케일링 증분을 가능하게 했다.

즉 오토스케일링 도입의 이득 일부는 스케일링 자체가 아니라 그것이 강제한 형상 표준화에서 나온다. → Spot Instance Management

6. AI 워크로드가 만든 새 비용 구조

대화형 BI는 캐시가 없다

사전 렌더링된 대시보드는 캐싱을 활용한다. 대조적으로 동적 LLM 추론 단계 + 즉석 생성되는 최적화되지 않은 ad-hoc SQL은 credit 소비와 토큰 비용을 올린다.

완화책: 무한 프롬프트를 제약하는 guardrail, 공격적 타임아웃을 건 전용 warehouse로 에이전트 트래픽 격리, 빈번한 동적 요청을 verified query로 승격. → AI Self-Serve Analytics

추론 비용은 decode의 메모리 대역폭이 결정한다

페이즈연산병목
Training / PrefillGEMMcompute-bound
DecodeGEMVmemory-bandwidth-bound

토큰 하나를 만들려면 모든 가중치를 훑고 KV Cache를 완전히 읽어야 하는데 산술은 토큰 하나 분량뿐이다. → 배칭 전략(continuous batching, speculative decoding)이 프롬프트 최적화보다 큰 레버인 경우가 많다.

⚠️ 다만 긴 컨텍스트에서는 weight-bandwidth-bound가 KV-bandwidth-bound로 옮겨갈 뿐 사라지지 않는다. → AI Accelerator Architecture

전력이 배포 제약이 되다

700W(Hopper) → 1,000W(Blackwell) → 1,400W(B300) → ~1,800W(Rubin Ultra). 약 1,000W 위에서 액체 냉각이 필수가 되어 공랭은 사실상 Hopper로 끝났다. 비용이 칩 단가에서 데이터센터 설비로 번진다.

토큰 비용은 언어에 따라 다르다

같은 의미를 표현하는 데 필요한 토큰 수가 언어별로 달라 language tax가 발생한다. → Tokenization Economics

7. 측정 — 절감을 주장하기 전에

  • 비교 가능한 품질에서 재라. 벡터 DB 평가에서 모든 후보를 동일 recall(~0.99)로 정규화하지 않으면 “더 대충 찾는 시스템”이 싸 보인다 → Vector Database Selection
  • 절감의 출처를 분해하라. Netflix의 58%는 ① 일일 주기 동적 적응 ② 지속적 최적화(수동 재튜닝 기대 제거) ③ 컨테이너 형상 표준화 — 세 번째는 오토스케일링의 부수 효과다
  • 벤치마크 경계를 명시하라. DuckLake 벤치마크는 “end-to-end 벤치마크가 아니라 레이크하우스 타깃 벤치마크” 라고 스스로 한정한다
  • 실험을 격리하라. branch = 실험 하나, 단일 실험 로그에 “Change vs. Previous Run” 강제 → 여러 변경을 묶으면 근본 원인을 귀속할 수 없다

공통 교훈

  1. 비용 곡선이 워크로드 곡선보다 가파르면 아키텍처 신호다 — 튜닝을 더 하는 게 답이 아니다
  2. 튜닝은 헤드룸을 사고 실링은 못 옮긴다 — 데이터 모양이 무제한 성장을 허용하면 결국 재설계
  3. 쓰기 한 번, 읽기 매일 — 쓰기 시점 투자의 정당성은 읽기/쓰기 빈도비에 있다
  4. 스케일 다운은 비대칭적으로 위험하다 — 효율을 조금 내주고 안정성을 사라
  5. 총량 전에 단위 폭 — per-row 폭이 총 볼륨보다 자주 범인이다
  6. 유휴 비용은 청구서에 안 보인다 — bin-packing과 형상 표준화가 숨은 레버
  7. 조율 비용은 저장 비용과 다르다 — 서버는 여유로운데 운영이 느리면 컨트롤 플레인을 봐라
  8. 엔진 한계를 하드웨어로 보상하고 있는지 정기적으로 물어라
  9. 품질을 정규화하지 않은 비용 비교는 무의미하다

관련 위키

관련 토픽

관련 이슈: DEW #278, #283, #284, #285, #286 | SeattleDataGuy 시리즈

그래프 뷰

백링크