주문이 들어오면 이메일 발송이나 이미지 처리 같은 작업을 비동기로 빼야 해서 큐가 필요해졌다. AWS SQS 같은 관리형 서비스를 쓸지, DB 테이블 기반 큐를 직접 만들지 정해야 하는 상황.
언제: 거의 항상. 큐, 캐시, 인증, 메일 발송처럼 우리 제품만의 강점이 아닌 부분은 그냥 관리형을 쓴다. 운영, 백업, 장애 대응을 남이 대신해 주는 게 가장 큰 가치다.
비용: 트래픽이 늘면 월 비용도 같이 늘고, 재시도 정책이나 메시지 크기 같은 세부 동작은 서비스가 정해 둔 한도 안에서만 바꿀 수 있다. 한 번 깊게 쓰면 다른 데로 갈아타기도 어렵다.
언제: 그 부분이 우리 제품의 핵심 경쟁력이거나, 관리형의 한계가 실제 숫자로 확인됐을 때만. 예를 들어 메시지 크기 제한 때문에 우회 코드가 계속 늘거나, 월 청구액이 직접 운영했을 때 비용의 몇 배가 됐을 때.
비용: 만드는 시간보다 그 뒤의 운영이 진짜 비용이다. 모니터링, 장애 대응, 업그레이드가 끝없이 따라오고, 처음 견적의 두세 배는 각오해야 한다. 만든 사람이 나가면 그대로 빚이 된다.
기본은 관리형이다. 우리 제품의 차별점이 아닌 부분에 엔지니어 시간을 쓰는 게 제일 비싼 비용이기 때문이다. 직접 만드는 건 관리형의 하드 리밋에 실측으로 부딪혔거나, 그 컴포넌트 자체가 우리 경쟁력일 때만이다.
- 관리형 서비스 월 청구액이 계속 올라서 엔지니어 한 명 인건비에 가까워짐
- SQS 메시지 256KB 제한 같은 하드 리밋에 걸려서 우회 코드(본문을 S3에 따로 저장하는 식)가 늘어남
- 관리형 쪽에서 나오는 p99 지연이 500ms를 넘는데 우리가 조절할 수 있는 설정이 없음
- 벤더 장애가 분기에 두 번 이상 우리 서비스 장애로 그대로 이어짐
🔧AWS SQSElastiCache (Redis)StripeAWS Cost Explorerk6
“I default to the managed service, and only build it myself when we hit a hard limit or it's our actual differentiator.”
checking microphone…