Read the Bill and Cut It

목표

클라우드 비용은 어디에 붙는지 모르면 못 줄입니다. 그리고 대개 "비싼 것" 이 아니라 "아무 일도 안 하는데 켜져 있는 것" 에 붙습니다.

어느 팀의 한 달치 청구서가 항목으로 풀려 있습니다. 읽고, 고치고, 얼마가 줄었는지 확인합니다.

시작

cp -r /opt/lab/cost/* . && python3 cost.py

합계가 대략 $3,191 나옵니다.

파일

파일	하는 일
architecture.json	요율과 자원. 이걸 고쳐 나갑니다
cost.py	항목별로 계산. 고치지 않습니다

각 자원의 메모 를 꼭 읽으세요. 낭비는 숫자가 아니라 메모에 적혀 있습니다.

채점

3단계부터는 채점기가 당신의 architecture.json 으로 직접 계산합니다. 숫자만 적어 내면 통과하지 못합니다.

단계

1. 항목별 비중 → 01-breakdown.txt
2. 놀고 있는 시간 → 02-idle.md
3. 고쳐서 얼마가 주나 → 03-fix-idle.txt
4. 스냅샷 보관 → 04-snapshot.txt
5. 경로 바꾸기 → 05-path.txt
6. AZ 간 트래픽 → 06-az.md
7. 안 쓰는 것 → 07-unused.txt
8. 정리 → 08-notes.md

참고

요율은 사업자·리전마다 다릅니다. 중요한 것은 자릿수와 "무엇이 무엇에 비례하는가" 입니다.

청구서를 항목으로 나눈다

/opt/lab/cost/ 를 복사해 python3 cost.py 를 돌리고, 가장 큰 항목 세 개와 각각의 비중을 01-breakdown.txt 에 남기세요.

cp -r /opt/lab/cost/* . && python3 cost.py

비용을 줄일 때 가장 먼저 하는 일이 이것입니다. 항목으로 나누기 전에는 어디를 손대야 할지 알 수 없고, 대개 눈에 띄는 것(=작은 것)부터 손댑니다.

합계는 대략 $3,191 이 나올 겁니다.

가장 큰 항목이 실제로 얼마나 일하나

1위 항목의 메모 를 읽고, 실제로 일하는 시간과 청구되는 시간을 비교해 02-idle.md 에 적으세요.

architecture.json 의 메모 를 보세요. 하루 2시간짜리 배치인데 인스턴스는 730시간 켜져 있습니다.

비용의 90% 이상이 아무 일도 안 하는 시간에 붙고 있습니다. 클라우드 비용에서 가장 흔한 낭비이고, CPU 사용률만 봐서는 잘 안 보입니다 — 평균이 낮아도 '원래 그런 워크로드' 라고 넘기기 때문입니다.

고쳐서 얼마가 줄어드나

architecture.json 을 architecture.json 그대로 두고 복사본을 만들어 배치를 실제 필요한 시간만 돌게 고치세요. 파일 이름은 architecture.json 을 덮어써도 됩니다. 고친 뒤 python3 cost.py 결과를 03-fix-idle.txt 에 남깁니다.

하루 2시간 × 30일 = 60시간입니다. 가동시간 을 730 에서 60 으로 바꾸세요.

채점기는 당신의 architecture.json 으로 직접 계산해서 확인합니다. 숫자만 적어 내면 통과하지 못합니다.

한 줄 고쳐서 얼마가 줄었는지 보세요. 이게 '어디부터 손대야 하나' 의 답입니다.

지우지 않은 것들

스냅샷 항목의 메모를 보고 보관 정책을 정한 뒤 그만큼 줄여 04-snapshot.txt 에 적으세요. 왜 그 기간인지도 적습니다.

7개월치 일 스냅샷이 쌓여 있습니다. 30일 보관이면 대략 1/7 로 줄어듭니다.

보관 기간은 비용이 아니라 복구 요구사항이 정합니다. "얼마나 오래된 시점으로 되돌아갈 수 있어야 하는가" 에 답이 있고, 그 답이 없으면 아무도 못 지웁니다 — 그래서 7개월이 쌓입니다.

경로를 바꿔 없애는 비용

NAT 항목의 메모를 보고, 처리량 요금이 사라지는 구조로 바꿔 05-path.txt 에 남기세요.

NAT 는 시간당 요금과 처리량당 요금이 따로 붙습니다. 처리량의 대부분이 오브젝트 스토리지로 가는 트래픽이라면, 게이트웨이 엔드포인트를 쓰면 그 경로는 NAT 를 안 지납니다.

처리GB 를 줄여 보세요. 트래픽은 그대로인데 경로만 바꿔서 비용이 사라집니다. 시간당 요금은 남습니다 — NAT 자체는 여전히 필요하니까요.

AZ 를 넘는 트래픽

cross-az 항목이 왜 3000GB 인지 메모에서 찾고, 줄이는 방법을 06-az.md 에 적으세요.

웹과 DB 가 다른 AZ 에 있어서 요청마다 AZ 를 넘습니다. GB 당 요금은 작지만 양이 많아서 쌓입니다.

다만 여기에는 함정이 있습니다 — 같은 AZ 로 몰면 그 AZ 가 죽을 때 같이 죽습니다. 이 항목은 '줄여야 할 낭비' 가 아니라 가용성에 지불하는 값일 수 있습니다. 무엇을 사는 돈인지 구별해서 적으세요.

아무도 안 쓰는 것

메모를 훑어 지금 아무도 안 쓰는 자원을 찾아 지우고, 최종 합계를 07-unused.txt 에 남기세요.

3개월 전에 쓰던 로드밸런서가 아직 떠 있습니다.

금액은 작습니다. 그런데 이런 것이 찾기는 가장 쉽고 위험도 가장 낮습니다. 비용 절감을 시작할 때 여기서부터 하면 팀이 방법을 익히면서 성과가 납니다. 큰 것부터 손대면 대개 논쟁으로 끝납니다.

정리한다

08-notes.md 에 세 줄 이상. 어디부터 손대야 하는지, 낭비와 가용성 비용을 어떻게 구별하는지, 경로를 바꿔 없어지는 비용의 예.

본문에 비중, 가용성, 경로 가 들어가야 합니다.