공용 대역에 두는 것이 싸 보였는데 요금을 실제로 계산해 보니 반대였다. 주소를 적게 쓰니 그쪽이 쌀 것이라고 짐작한 것이 전부였다.
Table of contents
Open Table of contents
요금표가 뒤집은 판단
요금표를 보니 주소 단가와 데이터 전송 단가가 있었고 같은 대역 안의 통신은 무료로 돼 있었다. 그중 세 번째 항목이 이 판단에서 결정적이었다.
전용 대역은 주소를 여러 개 받는 대신 장비 간 통신이 무료가 되고 공용 대역은 주소를 적게 쓰는 대신 장비끼리 통신할 때 밖으로 나간다. 주소 값보다 전송료가 훨씬 컸으므로 싸 보이던 쪽이 실제로는 비쌌다.
실측한 전송량
계산에 쓸 숫자를 짐작하지 않고 실제로 쟀다. 월간 전송량을 보고 그중 얼마가 우리 다른 장비로 가는지를 대상 주소별로 확인하니 70퍼센트가 내부 통신이었다.
같은 대역에 두면 그 70퍼센트가 통째로 무료가 된다. 두 안을 실측값으로 계산하니 전용 대역이 쌌고 처음 짐작과 정확히 반대였다.
과금 단위의 확인
계산하면서 요금이 매겨지는 단위가 무엇인지도 확인해야 했다. 전송은 나갈 때만 과금되고 저장은 용량과 기간의 곱이며 요청은 1,000건 단위로 센다.
세 번째가 걸렸는데 작은 요청을 자주 보내면 그 건수만큼 과금되기 때문이다. 한 건씩 8천 번 보내던 것을 100건씩 묶으니 요청 수가 100분의 1이 됐고 단위를 알아야 무엇을 줄일지가 정해진다.
비중으로 정한 대상
어디에 얼마를 쓰는지를 항목별로 나눠 보니 저장이 가장 컸고 전송이 그다음이었다. 전송을 줄이는 데 시간을 쓰고 있다가 그 표를 보고 방향을 바꿨다.
무엇이 저장 용량을 차지하는지 목록을 뽑아 보니 옛 백업이 대부분이었다. 보관 기간을 정하고 오래된 것을 싼 저장 등급으로 옮기니 저장 비용이 3분의 1로 줄었다.
태그와 사전 계산
이렇게 항목별로 나눠 보려면 자원마다 태그가 붙어 있어야 했다. 프로젝트와 환경과 소유 팀을 붙이고 태그가 없는 자원을 찾아 하나씩 채웠다.
청구 도구가 제한적일 때는 태그가 나눠 보는 유일한 수단이다. 새 자원을 만들 때 얼마인지 모르고 만들고 있어서 인스턴스와 볼륨과 예상 전송량으로 월 비용을 미리 계산하는 표도 만들었다. 만들고 나서 청구서로 아는 것과 만들기 전에 아는 것은 정할 수 있는 것이 다르고 실제로 한 번은 그 계산을 보고 더 작은 것으로 바꿨다.
정리
- 싸 보이는 쪽이 요금 구조에 따라 반대일 수 있다
- 요금표를 보고 실제 사용량을 재서 계산한다
- 요금이 매겨지는 단위를 확인한다
- 건수 단위면 묶어서 보낸다
- 어디에 얼마 쓰는지 나눠 보고 큰 것부터 줄인다
- 태그를 붙여야 나눠 볼 수 있다
- 태그 없는 자원은 어디 것인지 알 수 없다
- 만들기 전에 예상 비용을 계산하면 선택이 달라진다