클라우드 청구서가 예상의 3배일 때 — 요청당 원가와 비용 지표

서비스는 잘 돌아가고 있어요. 응답 시간도 안정적이고 장애도 없어요.

그런데 월말 청구서를 보고 놀랐어요. 예상의 세 배가 나왔어요. 트래픽은 계획대로 늘었는데 비용은 그보다 훨씬 가파르게 올랐어요.

어디서 나온 비용인지 항목을 봐도 잘 모르겠어요. 여러 서비스에 조금씩 흩어져 있고, 각각은 그럴듯해 보여요.

기술적으로는 아무 문제가 없는데 사업적으로는 지속 불가능한 상태예요.

그리고 이 상태는 장애처럼 알림이 울리지 않아요. 월말에 청구서로 알게 되고, 그때는 이미 한 달치를 다 쓴 뒤예요. 그리고 그 돈은 되돌릴 방법이 없습니다.

왜 그런가

클라우드 비용이 트래픽에 비례하지 않는 이유가 몇 가지 있어요.

첫째, 비용 구조가 항목마다 달라요. 어떤 건 사용량에 비례하고, 어떤 건 요청 수에 비례하고, 어떤 건 그냥 켜 두는 것만으로 나가요. 계산 자원은 쓴 만큼이지만 저장소는 쌓인 만큼이고, 네트워크는 나가는 방향만 돈을 받아요.

둘째, 데이터 전송 비용이 숨어 있어요. 가용 영역을 넘는 통신, 리전을 넘는 통신, 밖으로 나가는 통신에 각각 다른 요금이 붙어요. 아키텍처를 나눌수록 내부 통신이 늘고, 그게 비용이 돼요. 앞 편에서 본 N+1 이 여기서는 전송 비용으로 나타납니다.

셋째, 관측 비용이 커요. 로그, 지표, 추적을 다 남기면 그 저장과 조회가 상당한 비용이에요. 그리고 다음 편에서 볼 라벨 폭발이 이 비용을 곱셈으로 늘려요.

넷째, 쓰지 않는 자원이 남아 있어요. 떼어 놓은 디스크, 안 쓰는 스냅샷, 정지된 인스턴스에 붙은 볼륨, 테스트하고 잊은 환경 같은 것들이요. 각각은 작은데 합치면 큽니다.

그리고 근본적인 이유가 하나 더 있어요. 비용은 아무도 안 보고 있어요. 응답 시간은 대시보드에 있고 알림도 걸려 있는데, 비용은 월말에 청구서로 알게 돼요. 지표가 아니라 사후 보고서인 셈이죠.

코드로 보면

비용도 지표로 만든다:

· 무엇이 얼마인지 나눠서 본다
✓ 태그로 자원을 서비스·팀·환경별로 분류
✓ 태그가 없으면 원인을 못 찾는다

· 요청 하나당 비용을 계산한다
✓ 월 비용 ÷ 월 요청 수 = 요청당 원가
✓ 이 값이 오르면 구조가 나빠지고 있다는 뜻

· 흔한 낭비를 정기적으로 훑는다
✓ 안 붙은 디스크 · 오래된 스냅샷 · 안 쓰는 로드 밸런서
✓ 테스트하고 잊은 환경 · 과도한 로그 보관 기간

· 전송 비용을 줄인다
✓ 가용 영역을 넘는 통신을 줄인다
✓ 밖으로 나가는 데이터에 압축·캐시

· 예산 알림을 건다
✓ 월 예산의 50%·80% 지점에서 알림

✕ 문제 지점 · ✓ 해법 · 그대로 돌려 보기 전에 자기 환경에 맞게 고쳐 주세요.

실전에서는

비용을 다루는 관점을 바꾸는 게 핵심이에요. 비용은 사후 보고가 아니라 실시간 지표여야 해요.

가장 유용한 지표가 요청당 원가예요. 월 비용을 월 요청 수로 나눈 값이요. 이 값이 일정하면 비용이 트래픽에 비례하는 건강한 상태예요. 이 값이 오르면 구조가 나빠지고 있다는 뜻이고, 트래픽이 늘수록 손해가 커지는 상태입니다.

그리고 자원에 태그를 붙이는 게 전제 조건이에요. 태그가 없으면 청구서를 봐도 어느 기능이 얼마를 쓰는지 알 수 없어요. 나중에 붙이려면 아주 번거로우니 처음부터 규칙을 정해 두는 게 좋아요.

절감 항목 중에 효과가 큰 것들이 있어요.

로그와 지표의 보관 기간. 전부 1년 보관할 필요가 없어요. 최근 것만 상세히 두고 오래된 건 요약하거나 싼 저장소로 옮겨요.

데이터 전송. 가용 영역을 넘는 통신을 줄이면 눈에 띄게 줄어요. 그리고 밖으로 나가는 데이터는 캐시와 압축으로 크게 줄일 수 있어요.

쓰지 않는 자원. 정기적으로 훑으면 놀랄 만큼 나와요. 자동으로 찾아 알리는 장치를 두면 좋습니다.

인스턴스 유형과 약정. 사용 패턴이 안정적이면 약정 할인이 크게 유효해요. 다만 묶이는 기간을 감안해야 합니다.

여기서 균형을 잡아야 해요. 비용을 극단적으로 줄이면 안정성이 떨어져요. 앞 편에서 본 여유 용량이 대표적이에요 — 그건 낭비가 아니라 보험료예요. 무엇이 낭비이고 무엇이 보험인지 구분하는 게 이 일의 핵심입니다.

처방

1. 비용을 실시간 지표로 만드세요. 월말 청구서는 사후 보고이지 지표가 아닙니다.
2. 요청당 원가를 계산하고 추적하세요. 이 값이 오르면 구조 문제입니다.
3. 모든 자원에 태그를 붙이세요. 태그가 없으면 원인을 못 찾습니다.
4. 예산 알림을 거세요. 절반 지점에서 알면 대응할 시간이 있습니다.
5. 로그·지표의 보관 기간을 재검토하세요. 대개 과도하게 길게 잡혀 있습니다.
6. 데이터 전송 비용을 확인하세요. 가용 영역을 넘는 통신과 밖으로 나가는 데이터요.
7. 쓰지 않는 자원을 정기적으로 훑으세요. 자동으로 찾아 알리는 장치가 좋습니다.
8. 무엇이 낭비이고 무엇이 보험인지 구분하세요. 여유 용량·복제본·백업은 낭비가 아니라 보험입니다.
9. 관측 비용을 줄일 때는 무엇을 잃는지 알고 줄이세요. 장애 때 원인을 못 찾게 되면 절감액보다 손실이 큽니다.
10. 사람의 시간도 비용입니다. 월 10만 원을 아끼려고 며칠을 쓰면 손해예요. 효과가 크고 자동화할 수 있는 것부터 하세요.

지금 확인해 보세요

비용이 트래픽에 비례하는가:

· 요청당 원가 — 가장 중요한 한 줄
✓ 월 비용 ÷ 월 요청 수
✓ 일정하면 건강, 오르면 구조 문제

· 항목별 비중 상위 다섯
✓ 대개 소수가 대부분을 차지한다
✓ 거기부터 보면 된다

· 태그가 붙어 있는가
✕ 태그 없는 자원의 비중이 크면 원인 추적이 불가능하다

· 쓰지 않는 자원
✓ 안 붙은 디스크 · 오래된 스냅샷 · 유휴 로드 밸런서
✓ 정지 인스턴스에 붙은 볼륨 · 잊은 테스트 환경

· 데이터 전송 비중
✕ 예상보다 크면 가용 영역을 넘는 통신을 의심한다

· 예산 알림이 걸려 있는가
✕ 월말에 아는 건 지표가 아니라 사후 보고다

핵심 한 줄비용은 월말에 아는 게 아니라 매일 보는 지표여야 한다.