회사에 들어오는 메시지를 수집하는 응용 프로그램이 있습니다. 그러면 수십 개의 다른 애플리케이션과 마이크로서비스가 이러한 메시지를 빠르게 소비합니다. 메시지 수는 매우 다양하며 때로는 초당 100,000개로 갑자기 증가하기도 합니다. 이 회사는 솔루션을 분리하고 확장성을 높이려고 합니다.
이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
A. 아니요. Amazon Kinesis Data Analytics에 메시지를 유지합니다. 메시지를 읽고 처리하도록 소비자 응용 프로그램을 구성합니다.
B. 오토 스케일링의 Amazon EC2 인스턴스에 수집 애플리케이션을 배포하여 CPU 지표에 따라 EC2 인스턴스 수를 조정합니다.
C. 단일 샤드로 Amazon Kinesis Data Streams에 메시지를 씁니다. AWS Lambda 함수를 사용하여 메시지를 사전 처리하고 Amazon DynamoDB에 저장합니다. DynamoDB에서 메시지를 읽도록 소비자 애플리케이션을 구성합니다.
D. 여러 Amazon Simple Queue Service(Amazon SOS) 구독이 있는 Amazon Simple Notification Service(Amazon SNS) 주제에 메시지를 게시합니다. 큐의 메시지를 처리하도록 소비자 응용 프로그램을 구성합니다
동기식과 비동기식의 차이
동기식은 서비스 A와 서비스 B가 직접적으로 연결되어있는 방식이다.
비동기식은 서비스 A와 서비스 B 사이에 queue(대기줄)이 존재한다.
출처 : https://poiemaweb.com/js-async
위 사진을 보면 이해가 편하다. 비동기식의 quece를 흔히 진동벨로 생각할 수 있다.
이런 예시를 들었을 때 동기식의 단점이 부각된다. 서비스 A의 수가 늘어나면 지연이 생긴다. 커피가 나올 때까지 기다려야하기 때문이다.
그러나 비동기식이라면 주문만 쭈욱 받고, 대기열에 올려놓은 후 순서대로 커피를 제공할 수 있다.
따라서 비동기식 방식은 서비스 A의 요청이 급격하게 늘어날 때 이를 수월하게 대처할 수 있다.
SNS(Amazon Simple Notification Service)
결제 정보라는 동일한 이벤트로 운영되지만, 서로 다른 서비스들이 동일한 하나의 이벤트에 관해 각각의 동작을 진행하는 아키텍처이다. 이런 경우 SNS가 필요하다.
SQS(Amazon Simple Queue Service)
메시지를 대기열에 안전하게 저장하여 다른 서비스나 애플리케이션이 이를 처리할 수 있게 하는 분산 메시지 대기열 서비스이다. 즉 위 예시의 진동벨을 제공하는 서비스이다. 진동이란 매개체를 메시지로 변경하였다고 보면될듯.
