Amazon SQS는 많은 AWS 서비스와 마찬가지로 내부 마이크로서비스 컬렉션을 사용하여 구현된다.
- 고객 프론트엔드:고객 대면 프론트엔드는 CreateQueue, SendMessage와 같은 api 직접 호출을 수락, 인증, 승인한다. 그런다음 각 요청을 스토리지 백엔드로 라우팅한다
- 스토리지 백엔드: 이 내부 마이크로서비스는 표준(비FIFO) 대기열로 전송된 메시지를 유지하는 역할을 한다. 셀 기반 모델을 사용해 각 클러스터에는 여러 호스트가 포함되고 각 고객 대기열은 하나 이상의 클러스터에 할당되어 각 클러스터가 다수의 대기열을 담당한다.
원래 구현에서는 이 두서비스 사이의 요청마다 연결을 사용했다. 각 프론트엔드는 여러 호스트에 연결해야했기 떄문에 연결 풀을 사용해야 했고, 개방 연결 수에 있어 생래적인 한도에 결국 도달할 위험이 존재한다. 이와 같은 문제를 해결하기 ㅜ이해 단순히 하드웨얼르 투입해 스케일 아웃할수도 있지만, 항상 최선의 방법은 아니다.
결국 고객 프론트엔드와 스토리지 백엔드 사이의 새로운 독점적 바이너리 프레이밍 프로토콜을 개발해 사용하기로 결정했다. 이 프로토콜은 혼선 방지를 위해 128비트 id와 체크섬을 통해 단일 연결에서 여러 요청과 응답을 멀티 플렉싱할 수 있다. 서버 측 암호화는 대기열 데이터의 대한 무한 엑세스를 방지하는 추가 보호 계층도 제공한다.
새 프로토콜은 올해 초에 프로덕션 단계에 들어섰고 글 시점 744조 9천억건의 요청을 처리했다.
확장성 절벽(스케일 아웃의 한계)이 제거되었고, 이 프로토콜을 다른 방식으로 활용할 방법도 모색중이다
성능 측면에서 보면 새 프로토콜은 데이터 영역 지연시간을 평균 11퍼센트 p90수준에서는 17.4퍼센트 줄어냈고 이러한 변환느 sqs자체의 성능을 높이는 것 외에도 sqs를 기반으로 하는 서비스에도 도움이 된다.
예를 들어서 sns를 통해 전송되는 메시지가 전송되기 전 내부에서 소비하는 시간이 10% 줄었고 마지막으로 프로토콜 변경으로 인해 기존 sqs 호스트 플릿(x86 기반 인스턴스와 gravition 기반 인스턴스 혼합)이 이제는 전보다 17.8 퍼센트 더 많은 요청을 처리할 수 있다.
결론적으로 독자적인 바이너리 프레이밍 프로토콜을 통해 전반적인 sqs의 성능을 높혀볼 수 있었다는 것이다.