분산 시스템을 처음 설계할 때 가장 빨리 부딪히는 벽은 "두 컴포넌트가 같은 속도로 일하지 않는다"는 사실이다. 주문을 받는 웹 서버는 초당 수천 건을 받아낼 수 있지만, 그 주문으로 결제를 거는 처리기는 초당 수십 건밖에 못 한다. 둘을 직접 연결하면 빠른 쪽이 느린 쪽을 압사시킨다. 메시지 큐(message queue)는 이 둘 사이에 완충재를 끼워 넣어 "보내는 쪽"과 "받는 쪽"을 시간적으로 떼어놓는다(decoupling). Amazon SQS는 이 오래된 아이디어를 "큐를 직접 운영하지 않아도 되는 완전 관리형 서비스"로 만든 것이고, AWS의 첫 공개 서비스라는 역사적 무게까지 지고 있다.
DVA-C02에서 SQS는 메시징 섹션의 출발점이자 가장 자주 나오는 주제다. 단독 출제(가시성 타임아웃, FIFO 처리량 같은 숫자)도 많지만, 그보다 "Lambda가 메시지를 중복 처리하는 이유", "처리 실패 메시지를 어디로 보내나", "큐가 비었을 때 비용이 새는 이유" 같은 동작 원리 시나리오로 더 자주 나온다. 이번 글은 SQS가 왜 "최소 1회 전달"이라는 불편한 보장을 택했는지, 가시성 타임아웃이라는 임시 잠금이 어떻게 분산 합의 없이 중복을 줄이는지, 그리고 표준 큐와 FIFO 큐가 갈라지는 근본 이유를 깊이 파고든다.
SQS는 2006년에 정식 출시됐다 — S3(2006년 3월)와 함께 AWS의 가장 오래된 서비스 중 하나이고, 사실 베타는 2004년부터 돌고 있었다