비싼 것이 아니라 놀고 있는 것

한 줄 요약

클라우드 비용은 비싼 것이 아니라 아무 일도 안 하는데 켜져 있는 것에 붙는다.

왜 청구서를 읽어야 하나

클라우드 비용은 쓴 만큼 나오는 구조라 중간에 결재가 없다. 인스턴스를 켜는 데 승인이 필요 없고, 끄는 데도 필요 없다. 그래서 켜는 일은 계속 일어나고 끄는 일은 거의 일어나지 않는다.

몇 달이 지나면 청구서가 커지는데, 정작 무엇 때문에 커졌는지 아는 사람이 없다. 만든 사람은 다른 팀으로 갔고 재무팀은 총액만 본다. 이 상태에서 "비용을 줄이자" 고 하면 눈에 띄는 것부터 손대게 되고, 눈에 띄는 것은 대개 작다.

그래서 순서가 정해져 있다 — 먼저 항목으로 나누고, 그다음에 그 돈이 무엇을 사고 있는지 구별한다. 나누지 않고 시작한 절감은 대개 금액이 작거나, 아껴서는 안 될 것을 아낀다.

항목으로 나누기 전에는 아무것도 못 한다

"클라우드 비용이 너무 많이 나온다" 로 시작하면 대개 이렇게 끝난다 — 눈에 띄는 것부터 손대고, 눈에 띄는 것은 대개 작다.

먼저 항목별 비중을 본다. 실습의 청구서를 나누면 이렇게 나온다.

batch        compute          1,401.60$   43.9%db           managed_db         747.52$   23.4%web          compute            525.60$   16.5%snapshots    snapshot           210.00$    6.6%...합계                          3,191.17$

1위 하나가 44% 다. 나머지를 다 합쳐도 이것만 못하다.

그리고 1위는 대개 놀고 있다

batch 의 메모를 읽으면 이렇다.

> 하루 2시간짜리 배치를 도는데 인스턴스는 계속 켜져 있다.

하루 2시간 × 30일 = 60시간 일하는데 730시간이 청구된다. 비용의 92%가 아무 일도 안 하는 시간에 붙는다.

CPU 사용률만 봐서는 잘 안 보인다. 평균 11%를 보고 "배치라 원래 그렇다" 고 넘기기 때문이다. 언제 일하는지를 봐야 한다.

무엇을 사는 돈인지 구별한다

모든 비용이 낭비는 아니다.

cross-az 3000GB 는 웹과 DB 가 다른 AZ 에 있어서 생긴다. 같은 AZ 로 몰면 없어진다. 그런데 그 AZ 가 죽으면 같이 죽는다.

이건 낭비가 아니라 가용성에 지불하는 값이다. 줄이려면 "AZ 하나가 죽어도 되는가" 에 먼저 답해야 한다. 그 답 없이 줄이면 비용을 아낀 게 아니라 위험을 산 것이다.

대기 DB(db 2대 중 1대)도 마찬가지다. 평소에는 아무 일도 안 하지만, 그게 그 돈의 용도다.

경로를 바꿔 없어지는 비용

가장 기분 좋은 종류다. 트래픽은 그대로인데 비용만 사라진다.

NAT 게이트웨이는 시간당 요금과 처리량당 요금이 따로 붙는다. 오브젝트 스토리지로 가는 트래픽이 NAT 를 지나고 있다면, 게이트웨이 엔드포인트를 쓰면 그 경로는 NAT 를 안 지난다.

시간당 요금은 남는다 — NAT 자체는 여전히 필요하다. 하지만 처리량 요금은 0이 된다.

아무도 안 지우지 않는 것들

스냅샷 4200GB 는 7개월치 일 스냅샷이다. 왜 아무도 안 지웠나?

보관 기간을 정한 사람이 없기 때문이다. 지우려면 "얼마나 오래된 시점으로 되돌아갈 수 있어야 하는가" 에 답해야 하는데, 그 답이 없으면 아무도 책임지고 못 지운다.

보관 기간은 비용이 아니라 복구 요구사항이 정한다. 30일이면 30일이라고 적어 두면, 그 뒤로는 자동으로 지워진다.

어디부터 손대나

비중 순이 정답 같지만, 실제로는 안 쓰는 것부터 시작하는 편이 낫다.

| 순서 | 무엇 | 왜 |
|---|---|---|
| 1 | 안 쓰는 자원 | 찾기 쉽고 위험이 없다 |
| 2 | 놀고 있는 시간 | 금액이 크고 되돌리기 쉽다 |
| 3 | 보관 정책 | 정하기만 하면 자동으로 준다 |
| 4 | 경로 바꾸기 | 설계 변경이 필요하다 |
| 5 | 구조 바꾸기 | 논쟁이 필요하다 |

1번은 아무도 반대하지 않는다. 팀이 방법을 익히면서 성과가 나고, 그다음 것을 할 신뢰가 생긴다. 5번부터 시작하면 대개 논쟁으로 끝난다.

현장에서 만나는 모습

• 청구서 1위가 배치용 인스턴스였고 그 배치는 하루 두 시간만 돌았다. 가동 시간을 60시간으로 바꾸는 한 줄로 끝났다.
• CPU 평균 11% 를 보고 "배치라 원래 그렇다" 며 3년을 그대로 두었다. 봐야 할 것은 사용률이 아니라 언제 일하는가였다.
• AZ 간 트래픽을 낭비로 보고 웹과 DB 를 한 AZ 로 몰았다가, 그 AZ 장애 때 서비스 전체가 멈췄다. 아낀 금액보다 손실이 컸다.
• 스냅샷이 7개월치 쌓여 있는데 아무도 못 지운다. 지워도 되는지 답할 문서가 없기 때문이다.
• 가장 큰 항목부터 손대려다 팀 간 논쟁으로 두 달이 지나갔다. 안 쓰는 자원부터 정리한 팀은 같은 기간에 성과를 냈다.

정리

• 항목으로 나눠 비중을 본다
• 1위가 얼마나 일하는지 본다
• 낭비와 가용성 비용을 구별한다
• 경로를 바꿔 없어지는 것을 찾는다
• 안 쓰는 것부터 시작한다