[Datadog] 불필요한 비용 줄이기 – Container 편

Log는 많이 넣으면 비싸지고, Host는 켜놓기만 해도 비싸다.

그렇다면 Container는 어떨까?

 

컨테이너는 “잠깐 살아있어도” 과금된다.

이게 제일 무섭다.

 

Datadog Container 과금 구조 이해하기

https://docs.datadoghq.com/account_management/billing/containers/

https://www.datadoghq.com/blog/cloud-cost-management-container-support/

Datadog의 컨테이너 과금은 단순히 “노드 몇 개냐”가 아니다.

Infrastructure Monitoring에서 컨테이너 기반 과금은 다음 기준으로 계산된다.

• 평균 실행 중 컨테이너 수 (Hourly average)
• 월 단위 집계
• 특정 퍼센타일 기준 적용 (상위 피크 일부 제외)

컨테이너 수 × 시간 × 플랜 단가

이것이 아니다.

 

월간 평균 활성 컨테이너 수

기준으로 청구된다.

 

컨테이너 비용은 예측하기가 어렵다.

호스트와 달리 빠르게 살았다 죽는 경우가 많기 때문에 인지하기가 쉽지 않다.

 

1) 짧게 살아도 과금된다

Kubernetes 환경에서는 이런 일이 흔하다.

• CronJob Pod
• HPA로 갑자기 증가한 Replica
• 배포 중 롤링 업데이트로 잠깐 늘어난 Pod
• CrashLoop로 재생성되는 Pod

잠깐 생성된 것 뿐이어도, Datadog은 실행된 시간 단위 기준으로 카운트한다.

아주 짧은 생명주기라도 집계에 포함된다.

 

2) Host 과금과 다르게 스케일링 민감도가 높다

Host는 보통 노드 수 기준이다.

하지만 Container는?

 

노드 5개인데 Pod가 300개면?

→ 300개가 기준이다.

 

Autoscaling이 활발한 조직일수록 Datadog 비용 변동폭도 커진다.

AWS 비용 줄였는데 Datadog은 늘어나는 역전 현상이 여기서 발생한다.

 

3) Sidecar가 비용을 키운다

Istio, Envoy, Datadog Agent, Service Mesh,

Log forwarder, Metrics exporter…

Pod 하나에 컨테이너가 3~4개 들어가면?

Replica 100개면 실제 과금 대상은 300~400개다.

 

서비스 수는 안 늘었는데 관측 도구가 비용을 키우는 구조가 된다.

 

그럼 어떻게 줄일수 있을까?

1) “실제 필요한 컨테이너 수”를 구분하라

• 앱 컨테이너
• 사이드카
• Job / CronJob
• 테스트 네임스페이스

모두 동일하게 과금되는데, 모두 필요한가?

 

2) Datadog Agent 설정 점검

다음 설정을 점검해야 한다.

• 컨테이너 제외 설정
• 특정 네임스페이스 제외
• 테스트 환경 제외
• 단기 Job 수집 제외

DD_CONTAINER_EXCLUDE=image:busybox
DD_CONTAINER_EXCLUDE=kube_namespace:dev-test

 

Host vs Container 차이 정리

항목	Host	Container
과금 기준	실행 호스트 수	실행 컨테이너 수
스케일 민감도	낮음	매우 높음
Autoscaling 영향	제한적	매우 큼
Sidecar 영향	없음	매우 큼
예측 난이도	중간	높음