넘겨받은 커머스의 클라우드 비용을 줄일 방법으로 「dev 환경을 쓸 때만 띄우고 안 쓸 때는 끄는 구조로 바꾸자」는 안이 올라왔다. 흔히 듣는 절감책이고 많은 조직에서 실제로 효과가 있지만, 이 환경에서도 그런지는 재 봐야 알 수 있었다. 리소스를 끄거나 지우지 않고, API 도 켜지 않은 채 조회만으로 쟀다.
Table of contents
Open Table of contents
측정 — dev 에 무엇이 있나
조회해 보니 dev 프로젝트에는 상시로 도는 컴퓨트가 하나도 없었다.
- GKE 클러스터는 0개였고, Compute Engine API 는 「이 프로젝트에서 한 번도 쓴 적이 없다」는 응답이 왔다. VM·영구 디스크·정적 IP 는 모두 그 API 소관이므로 존재할 수 없다
- 있는 것은 Cloud Functions 여러 개와 Cloud Run 1개, Artifact Registry 2개, GCS 버킷 8개였다. 켜진 API 는 61개로 운영(140개)의 절반에 못 미쳤다
저장량은 Cloud Monitoring 으로 쟀다. Firestore 0.81 GiB 와 Realtime Database 0.70 GiB 를 합쳐 1.51 GiB 로, 운영(167.68 GiB)의 0.9% 였다.
원인 — 왜 절감안이 성립하지 않는가
「쓸 때만 띄운다」가 아끼는 것은 상시 기동 컴퓨트의 시간이다. 그런데 이 dev 에는 그 시간을 쓰는 상시 기동 인스턴스가 0 이다. 서버리스는 호출이 없으면 컴퓨트 과금이 0 이므로, 「안 쓸 때 끈다」는 이미 기본 동작이고 지금 그 상태다. 남는 것은 저장 비용뿐인데, 저장 비용은 띄웠다 끄는 것으로 줄지 않고 데이터를 지워야 준다.
dev 의 API 주소가 522(오리진 무응답)를 돌려주던 이유도 이것으로 설명됐다. 끄고 켜는 문제가 아니라, 그 주소 뒤에 상시 기동 서버가 처음부터 없었다.
판단 — 구조를 바꾸지 않기로 한 이유
결정할 선택지는 다음 두 가지 방법이었다.
- 올라온 안대로 기동·정지 자동화를 만들어 dev 를 「쓸 때만 띄우는 구조」로 바꾼다
- 자동화를 만드는 대신 지금 서버리스 구조를 그대로 둔다
2번을 고른 이유는 1번이 줄일 비용이 없는데 새 비용을 만들기 때문이다. 끌 대상이 없는 기동·정지 스크립트는 만들고 유지하는 공수만 생긴다. 반면 2번은 아무것도 바꾸지 않으므로 운영 위험도 유지 비용도 새로 늘지 않는다. 대가는 「dev 비용을 줄였다」는 결과를 낼 수 없다는 점이다. 줄일 것이 없다는 사실을 실측으로 확인한 것 자체가 이번 결정의 결과다.
영향 범위 — 못 잰 것
프로젝트별 실제 청구액은 뽑지 못했다. BigQuery 청구 내보내기 데이터셋이 운영과 dev 어디에도 없었고, 세 프로젝트가 리셀러 경유의 같은 청구 계정을 쓰고 있었다. 프로젝트별 금액을 가르려면 콘솔 리포트나 리셀러 명세를 따로 봐야 한다. 이 숫자는 추정으로 채우지 않고 비워 두었다. 프로젝트별 비용을 판단하려면 청구 내보내기가 먼저 켜져 있어야 한다.
결과 — 하지 않기로 한 것이 막은 비용
- 비용. 줄일 것이 없는 곳에 자동화를 만들지 않아, 새 유지 공수와 오작동 위험을 만들지 않았다
- 판단의 근거. 「흔한 절감책」을 그대로 적용하지 않고 실측(컴퓨트 0 · 저장량 운영의 0.9%)으로 기각했다
- 남긴 과제. 시험할 곳 자체가 없다는 문제가 드러났다. 끌 것이 없다는 것은 곧 시험용 서버가 없다는 뜻이었다
정리
- 「꺼서 아낀다」는 끌 것이 있는지부터 잰다. 서버리스와 저장소뿐이면 구조를 바꿀 실익이 없다
- 하지 않기로 한 것도 결정이다. 근거와 함께 적어 두면 같은 안이 다시 올라왔을 때 바로 답할 수 있다
- 추정으로 채울 수 없는 숫자는 비워 두고, 그 숫자를 얻기 위한 전제(청구 내보내기)를 남긴다