Amazon Simple Queue Service(SQS), 속도와 규모 조정을 위한 최적화 개선 사항

Amazon Simple Queue Service(Amazon SQS)는 몇 번의 공개 베타를 거쳐 2006년에 출시되었습니다. 거의 20년이 지난 지금도 이 완전 관리형 서비스는 마이크로서비스, 분산 시스템, 서버리스 애플리케이션의 기본 구성 요소로서 피크 타임에 초당 1억 개 이상의 메시지를 처리하고 있습니다.

항상 더 나은 방법이 있기 때문에 성능, 보안, 내부 효율성 등을 개선할 수 있는 방법을 지속적으로 모색하고 있습니다. 상황을 개선할 수 있는 잠재적인 방법을 찾으면 기존 동작을 유지하도록 주의하고, 결과를 비교할 수 있도록 새 시스템과 기존 시스템을 병행하여 실행하는 경우가 많습니다.

오늘은 지연 시간을 줄이고 플릿 용량을 늘리며 다가오는 확장성 절벽을 완화하고, 전력 소비를 줄이기 위해 최근에 Amazon SQS를 어떻게 개선했는지 말씀드리겠습니다.

Amazon SQS 개선 사항
많은 AWS 서비스와 마찬가지로 Amazon SQS는 내부 마이크로서비스 컬렉션을 사용하여 구현됩니다. 오늘은 그중 두 가지에 초점을 맞추겠습니다.

고객 프론트엔드 – 고객 대면 프론트엔드는 CreateQueue나 SendMessage 같은 API 직접 호출을 수락, 인증, 승인합니다. 그런 다음 각 요청을 스토리지 백엔드로 라우팅합니다.

스토리지 백엔드 – 이 내부 마이크로서비스는 표준(비FIFO) 대기열로 전송된 메시지를 유지하는 역할을 합니다. 셀 기반 모델을 사용하여 셀의 각 클러스터에는 여러 호스트가 포함되고 각 고객 대기열은 하나 이상의 클러스터에 할당되며, 각 클러스터가 다수의 대기열을 담당합니다.

연결 – 기존 및 신규
원래 구현에서는 이 두 서비스 사이의 요청마다 연결을 사용했습니다. 각 프론트엔드는 여러 호스트에 연결해야 했기 때문에 연결 풀을 사용해야 했고, 개방 연결 수에 있어 생래적인 한도에 결국 도달할 위험도 있었습니다. 이와 같은 문제를 해결하기 위해 단순히 하드웨어를 투입해 스케일 아웃하는 경우도 많지만, 이것이 항상 최선의 방법은 아닙니다. 결국 언젠가는 마주치게 될 순간(‘확장성 절벽’)을 미래로 미루는 것에 불과하며 리소스를 효율적으로 사용하지 못합니다.

Amazon SQS 팀은 몇 가지 장기적 솔루션을 신중하게 고려한 끝에 고객 프론트엔드와 스토리지 백엔드 사이의 새로운 독점 바이너리 프레이밍 프로토콜을 개발했습니다. 이 프로토콜은 혼선 방지를 위해 128비트 ID와 체크섬을 사용하여 단일 연결에서 여러 요청과 응답을 멀티플렉싱합니다. 서버 측 암호화는 대기열 데이터에 대한 무단 액세스를 방지하는 추가 보호 계층을 제공합니다.

효과 확인!
새 프로토콜은 올해 초에 프로덕션 단계에 들어섰고 이 글을 쓰는 시점에 744조 9천억 건의 요청을 처리했습니다. 확장성 절벽이 제거되었고, 우리는 벌써 이 새로운 프로토콜을 다른 방식으로 활용할 방법을 찾고 있습니다.

성능 측면에서 보면 새 프로토콜은 데이터 영역 지연 시간을 평균 11%, P90 수준에서는 17.4% 줄였습니다. 이러한 변화는 SQS 자체의 성능을 높이는 것 외에도 SQS를 기반으로 하는 서비스에도 도움이 됩니다. 예를 들어 이제 Amazon Simple Notification Service(SNS)를 통해 전송되는 메시지가 전송되기 전에 ‘내부’에서 소비하는 시간이 10% 줄었습니다. 마지막으로, 프로토콜 변경으로 인해 기존 SQS 호스트 플릿(X86 기반 인스턴스와 Graviton 기반 인스턴스의 혼합)이 이제는 전보다 17.8% 더 많은 요청을 처리할 수 있습니다.

다음 이야기
Amazon SQS 구현에 대해 조금이나마 도움이 되셨기를 바랍니다. 댓글로 알려주시면 공유할 만한 이야기를 더 찾아보겠습니다.

— Jeff