Amazon Web Services 한국 블로그

Amazon Simple Queue Service(SQS) – 15주년, 큐는 계속 진행 중~

시간이 정말 빨리 갑니다! 제가 Amazon Simple Queue Service(SQS) 제품 출시에 관해 글을 쓴 것이 지난 2006년의 일입니다. 15년이 흐른 뒤에도 여전히 블로그에 글을 올리고 있을지, 이 서비스가 급속히 성장하면서 동시에 수많은 다양한 유형의 웹 규모 애플리케이션 아키텍처라는 기본을 그대로 고수하고 있을지 그때는 몰랐습니다.

SQS의 첫 베타 버전은 별다른 요란한 알림 없이 2004년 말에 처음 발표됐습니다. 당시의 베타 이후로 참 많은 기능을 추가했지만, 원래의 설명(“신뢰할 수 있고 확장성이 뛰어난 호스팅된 대기열로, 분산된 애플리케이션 구성 요소 사이에서 메시지를 버퍼링함”)은 아직도 맞는 말입니다. 우리 고객은 SQS를 클라우드의 무한 버퍼로 여기고 SQS 대기열을 사용해 애플리케이션 아키텍처를 이루는 여러 기능적인 부분 사이의 연결을 구현합니다.

몇 년의 시간이 흐르는 동안 우리는 내부에는 복잡한 요소가 많지만, SQS 인터페이스를 단순하고 사용하기 쉬운 형태로 유지하고자 열심히 애썼습니다. SQS의 확장 가능성과 신뢰성을 확보하려면 메시지를 각 AWS 리전의 서버 수천 개로 구성된 플릿 안에 보관합니다. 한 리전 안에 각 메시지 사본을 세 부씩 저장하고, 메시지를 스토리지 노드와 가용 영역에 배포하는 데 주의를 기울입니다. SQS는 이와 같은 기본 내장형 중복 스토리지 외에도 자체 복구 기능이 있으며 호스트 오류나 네트워크 중단이 발생해도 회복력이 뛰어납니다. SQS는 이제 15살이 됐지만, 우리는 지금도 계속해서 크기 조정과 로드 관리 애플리케이션을 개선해 나가며 사용자가 중요 업무용 워크로드를 처리할 때 SQS를 항상 믿고 맡길 수 있도록 노력하고 있습니다.

SQS는 엄청난 규모로 실행됩니다. 예를 들면 다음과 같습니다.

Amazon Product Fulfillment – 2021년 Prime Day에는 SQS로 이동하는 트래픽이 초당 무려 4,770만 건의 메시지에 달하며 신기록을 세웠습니다.

Rapid7 – Amazon 고객인 Rapid7에서 SQS를 폭넓게 활용합니다. Jeff Myers(플랫폼 소프트웨어 아키텍트)는 이렇게 전했습니다.

Amazon SQS는 관리 때문에 골치 썩을 일이 없고, 사용하기 간편하고 성능이 뛰어난 데다 확장성까지 우수한 메시징 서비스입니다. 저희 아키텍처의 중대한 구성 요소로서, 덕분에 매일 수백억 건에 달하는 메시지 규모에 맞춰 확장할 수 있었습니다.

Amazon SQS 홈페이지에서 NASA, BMW Group, Capital One 및 여타 AWS 고객의 다른 대규모 사용 사례를 확인하실 수 있습니다.

Serverless Office Hours
오늘(6월 13일) 정오(PT) Twitch.tv에서 하는 Serverless Office Hours를 놓치지 마세요. 소문으로는 케이크가 준비됐다고 합니다!

시간을 거슬러
SQS의 주요 마일스톤을 몇 가지만 간략하게 되짚어보겠습니다.

2006년 – 제품 출시. 계정당 대기열, 대기열당 항목 수에 제한이 없고, 항목마다 최대 길이 8KB까지 허용됩니다. 보낸 메시지와 전송한 데이터에 따른 종량제 요금입니다.

2007년 – 가시성 시간제한 및 큐잉된 메시지의 대략적인 수에 대한 액세스 등 추가 기능을 출시했습니다.

2009년 – SQS in Europe을 선보이고 AddPermission 및 RemovePermission을 통해 추가로 대기열 액세스 제어를 제공했습니다. 이때의 출시로 당시 액세스 정책 언어라 불렸고 지금의 IAM Policy로 발전한 언어가 처음 세상에 출현하기도 했습니다.

2010년 – 새 프리 티어(당시에는 매달 요청 100,000건, 이후 매달 요청 1백만 건으로 확대됨), 구성 가능한 메시지 최대 길이(최대 64KB) 및 구성 가능한 메시지 보존 시간 등을 도입했습니다.

2011년 – 각 SQS 대기열마다 CloudWatch 지표를 추가했습니다. 이후 같은 해에 배치 작업(SendMessageBatch 및 DeleteMessageBatch), 지연 대기열과 메시지 타이머 등도 추가했습니다.

2012년 – 롱폴링을 지원하기 시작했으며, 요청 배치 처리 및 클라이언트 측 버퍼링에 대한 SDK 지원도 제공했습니다.

2013년 – 전보다 더 큰 규모의 페이로드를 지원(256KB)하고 요금을 50% 인하했습니다.

2014년 – 배달하지 못한 편지 대기열(DLQ)을 지원해 제한 시간 초과로 인해, 또는 코드 내부의 오류 처리로 전달되지 못한 메시지를 수락했습니다.

2015년 – Extended Client Library를 사용해 확장 페이로드(최대 2GB)도 지원했습니다.

2016년 – 딱 한 번만 처리(exactly-once processing)하고 복제해 FIFO 대기열도 지원하고 가격을 재차 인하했습니다.

2017년 – 메시지의 서버 측 암호화, 비용 할당 태그를 지원했습니다.

2018년 – AWS PrivateLink를 사용한 Amazon VPC Endpoint 및 Lambda 함수 호출 기능을 지원했습니다.

2019년 – Tag-on-Create와 X-Ray 트레이싱을 지원했습니다.

2020년 – 더욱 세분화된 대기열 모니터링을 위한 1분 지표, 새로운 콘솔 환경, ListQueues와 ListDeadLetterSourceQueues 함수의 결과 페이지 매김을 지원했습니다.

2021년 – 계층화된 요금제를 실시해 사용량이 늘어남에 따라 비용을 절약할 수 있게 조처하였으며, FIFO 대기열의 고처리량 모드가 생겼습니다.

지금까지도 SQS는 단순하고 확장 가능하며 비용 효율적이고 매우 신뢰할 수 있는 형태를 고수하고 있습니다.

AWS Hero의 메시지 소개
AWS 히어로 몇몇 분에게 SQS의 성공을 돌아보고 각자의 성공담을 함께 나눠주시기를 부탁드렸습니다. 도착한 메시지를 소개합니다.

Eric Hammond(서버리스 히어로) 씨는 AWS Lambda Dead Letter Queues를 사용합니다. 대기열에 경보를 설정해 문제를 조사해야 하는 경우 사내에 알림 이메일을 보냅니다.

Tom McLaughlin(서버리스 히어로) 씨는 2015년부터 쭉 SQS를 이용해 왔습니다. 이런 메시지를 전했습니다. “제가 제일 좋아하는 사용 사례라면, 누가 대기열을 원하는 데 제가 직접 큐잉 플랫폼을 관리할 마음은 없을 때입니다. 사실 늘 그러니까, ‘항상’이 답입니다.”

Ken Collins(서버리스 히어로)는 SQS를 쓴지 얼마나 됐는지 정확히는 모르겠지만 한 2~8년 된다고 했습니다! Ken 씨는 SQS를 Lambdakiq gem을 구동하는 데 쓰는데, 이것은 SQS와 Lambda에서 ActiveJob을 구현하는 역할을 합니다.

변규현(서버리스 히어로)는 대량의 트래픽을 유지해야 하는 푸시 시스템을 구동하는 데 SQS를 이용해 왔으며, “SQS 덕분에 큐잉 시스템을 빌드할 걱정은 이제 완전히 덜었어요.”라고 전했습니다.

Prashanth HN(서버리스 히어로)는 2017년부터 SQS를 이용해 온 사용자이며, 자칭 “지각생”이라고 생각합니다. Prashanth 씨는 SQS를 첫 서버리스 애플리케이션 일부분으로 사용했는데, 그 결과 처리량이 서로 다른 여러 서비스를 연결하는 데 SQS가 가장 좋은 방식이라고 느꼈다고 합니다.

Ben Kehoe(서버리스 히어로)는 이렇게 전했습니다. “제가 SQS가 가진 힘을 처음 실감한 건 어느 동료가 실례를 보여주었을 때입니다. 인스턴스가 종료될 때 상태를 SQS에 저장해두었다가 시작할 때 새 인스턴스가 대기열에서 상태를 검사하도록 함으로써 EC2 Spot 인스턴스 플릿에서 상태를 보존하는 방법을 보여줬습니다.”

Jeremy Daly(서버리스 히어로)는 2010년부터 SQS를 사용자가 제공한 이미지에 얼굴 인식 프로세스를 제공하는 역할을 하는 일종의 경량 대기열로 사용했습니다. 지금은 아직 서버리스가 아닌 다운스트림 서비스에 대한 요청을 조절하는 버퍼로도 자주 쓴다고 합니다.

Casey Lee(컨테이너 히어로)도 2010년부터 SQS를 사용해 왔습니다. 느슨하게 결합된 Java 서비스 사이의 ActiveMQ를 대체할 용도였습니다. Casey 씨는 대기열 깊이를 바탕으로 자동 크기 조정을 구현해본 결과 이 방식이 로드를 처리하는 데 올바른 방법임을 깨달았습니다.

Vlad Ionecsu(컨테이너 히어로)는 지난 2014년에 SQS를 접한 것을 계기로 AWS와의 여정을 시작했습니다. Vlad 씨는 API가 매우 이해하기 쉽다고 생각했고, 논문 프로젝트를 지원하는 데 SQS를 동원했다고 합니다.

Sheen Brisals(서버리스 히어로)는 지난 2018년, Lambda와 S3도 사용하는 개념 증명을 빌드하던 중 SQS를 사용하기 시작했습니다. Sheen 씨는 각 대기열의 특징을 조정해 메시지 처리 함수에 적합한 일치 항목을 생성하는 기능이 특히 마음에 든다고 하며, 우선순위가 높고 낮은 대기열을 모두 활용한다고 합니다.

Gojko Adzic(서버리스 히어로)는 2013년 MindMup에서 내보내기 주체를 위한 태스크 디스패치용으로 SQS를 사용하기 시작했습니다. MindMup은 온라인 마인드 매핑 애플리케이션의 일종으로, 수많은 사용자 집단이 공동 작업할 수 있게 해주고, 각 문서의 업데이트에 엄격한 순서를 지정하도록 합니다. Gojko 씨는 FIFO 대기열을 사용해 다양한 문서의 메시지를 동시에 처리할 수 있게 하였으며, 각 문서 내에서는 순차적인 순서를 부여했습니다.

Sebastian Müller(서버리스 히어로)는 2016년에 웹사이트 빌더인 jimdo.com에서 사용할 알림 센터를 빌드하다 SQS를 사용하게 됐습니다. 이 센터는 고객이 이벤트(주문, 지원 메시지 및 연락처 요청 등)를 제때 알 수 있게 해주는 역할을 합니다.

Luca Bianchi(서버리스 히어로)는 2012년에 처음 SQS를 사용했습니다. AWS Elastic Beanstalk에서 실행되는 마이크로서비스 한 쌍을 분리하고, 게이미피케이션 플랫폼용으로 팬아웃 처리 시스템도 하나 만들었습니다. 요즘 가장 좋아하는 SQS 사용 사례는 추론 작업을 보관해 Amazon SageMaker에서 실행 중인 작업자 프로세스에서 이용할 수 있게 하는 것이라고 합니다.

Peter Hanssens(서버리스 히어로)는 SQS를 사용해 당장 처리하지 않아도 되는 작업의 부담을 덥니다. 몇 년 전 데이터 사이언티스트를 보조하는 일을 하다 이벤트 중심적 배치 처리 시스템을 만들었는데, 여기에서는 Lambda 함수를 사용해 5분에 한 번씩 대기열을 검사하고 EC2 인스턴스를 실행해 모델을 구축하면서, 실행 인스턴스의 최대 수에는 엄격한 통제권을 유지했다고 합니다.

Serkan Ozal(서버리스 히어로)는 2013년 무렵부터 SQS를 사용했습니다. 주로 비동기 메시지 처리에 중점을 두고 대량의 이벤트 처리는 SQS의 능력을 믿고 맡긴다고 합니다. 또한 메시지 가시성 기능도 사용해 필요한 경우 메시지를 재처리하기도 한다고 합니다.

Matthieu Napoli(서버리스 히어로)는 SQS를 사용한 지 약 5년이 됐고, 처음에는 EC2부터 시작했으며 다른 대기열을 대신해서 사용했습니다. Matthieu 씨는 “Lambda와 함께 사용하면 크게 고민하지 않아도 곧바로 대량의 병렬 처리가 가능하거든요. 게다가 기본 내장 오류 처리 기능 덕분에 아주 강력합니다.”라고 합니다.

보시는 바와 같이 SQS의 사용 사례는 아주 다양합니다.

SQS 리소스
아직 SQS를 사용하지 않는다면, 이제 대기열에 합류해 시작할 때가 됐습니다. 옳은 길을 찾는 데 도움이 되도록 몇 가지 리소스를 준비했습니다.

즐거운 큐잉을 기원합니다!

— Jeff;