Google Cloud Pub/Sub 비용: 처리량, 보관, 리전 전송 계산

Pub/Sub은 topic에 발행한 byte와 각 subscription에서 전달한 byte를 과금합니다. 인코딩된 message 크기, attribute, 월 message 수, 각 message를 받는 subscription 수부터 정리하세요. 하나의 발행 stream을 subscription 3개에 전달하면 발행 경로 1개와 전달 경로 3개가 생기므로 topic 수보다 subscriber fan-out이 비용에 더 큰 영향을 줄 수 있습니다.

Pub/Sub은 message가 더 작아도 publish, push, pull 요청마다 최소 1,000 byte를 산정합니다. 지연 시간 요구가 허용하면 작은 message를 요청 하나로 batch하고 payload뿐 아니라 attribute도 포함하세요. 바뀔 수 있는 단가를 본문에 고정하지 말고 공식 최신 가격표에서 요율과 무료 제공량을 확인합니다.

Subscriber가 평소 message를 acknowledge하는 시간과 장애 중 backlog 최대 크기를 추정하세요. Topic retention, acknowledge된 message 보관, snapshot, 기본 포함 기간을 넘긴 미확인 message에 storage 요금이 생길 수 있습니다. Retention 설정 기간 전체가 평균 저장량은 아니므로 backlog와 보관 패턴으로 byte-hour를 계산해야 합니다.

Topic retention은 연결된 모든 subscription의 replay를 지원할 수 있지만, subscription마다 acknowledge된 message를 보관하면 저장 데이터가 중복될 수 있습니다. 제품에 필요한 복구 시점만 선택하고 오래된 snapshot을 삭제하며 가장 오래된 미확인 message의 age를 관찰하세요. Redelivery는 subscriber 작업도 반복하므로 consumer를 idempotent하게 만들고 exactly-once delivery가 모든 중복을 해결한다고 가정하기 전에 acknowledgement 처리를 조정합니다.

Publisher, message 저장 위치, subscriber의 region을 기록하세요. Message가 region 경계를 지날 때마다 data transfer 비용이 생길 수 있고 여러 원격 subscriber로 전달하면 각 경로가 과금됩니다. 안정성과 데이터 위치 요건이 허용하면 밀접한 producer와 consumer를 호환되는 위치에 두고, 트래픽이 한 region에 머문다고 가정하지 말고 message storage policy를 확인하세요.

Filter로 제외된 message도 throughput 요금이 발생하므로 넓은 stream을 filter가 많은 subscription에 모두 보내기보다 upstream에서 route를 나누는 편이 저렴할 수 있습니다. Subscriber compute, logging, retry, dead-letter 처리, BigQuery·Cloud Storage 같은 목적지 비용도 전체 구조에 더하세요. 출시 전 일반 트래픽, fan-out 증가, consumer 지연 시나리오를 비교합니다.

Workflow 비용에 Secret Manager 로테이션 알림 포함하기