[AWS][SAA][EXAMTOPICS] Question 97 (확인)

A business is re-architecting a tightly connected application in order to make it loosely coupled. Previously, the program communicated across layers through a request/response pattern. The organization intends to do this via the usage of Amazon Simple Queue Service (Amazon SQS). The first architecture includes a request queue and a response queue. However, when the program grows, this strategy will not handle all messages.

What is the best course of action for a solutions architect to take in order to tackle this issue?

• A. Configure a dead-letter queue on the ReceiveMessage API action of the SQS queue.
• B. Configure a FIFO queue, and use the message deduplication ID and message group ID.
• C. Create a temporary queue, with the Temporary Queue Client to receive each response message.
• D. Create a queue for each request and response on startup for each producer, and use a correlation ID message attribute.

 

한글번역

기업은 느슨하게 결합되도록 밀접하게 연결된 애플리케이션을 재설계하고 있습니다. 이전에는 프로그램이 요청/응답 패턴을 통해 계층 간에 통신했습니다. 조직은 Amazon Simple Queue Service(Amazon SQS)를 사용하여 이를 수행하려고 합니다. 첫 번째 아키텍처는 요청 큐와 응답 큐를 포함합니다. 그러나 프로그램이 커질 때 이 전략은 모든 메시지를 처리하지 않습니다.

솔루션 아키텍트가 이 문제를 해결하기 위해 취해야 할 가장 좋은 조치는 무엇입니까?

• A. SQS 대기열의 ReceiveMessage API 작업에서 배달 못한 편지 대기열을 구성합니다.
• B. FIFO 대기열을 구성하고 메시지 중복 제거 ID 및 메시지 그룹 ID를 사용합니다.
• C. 각 응답 메시지를 수신할 임시 대기열 클라이언트를 사용하여 임시 대기열을 만듭니다.
• D. 각 생산자에 대한 시작 시 각 요청 및 응답에 대한 대기열을 만들고 상관 ID 메시지 속성을 사용합니다.

 

 

 

정답

• C. Create a temporary queue, with the Temporary Queue Client to receive each response message.

 

해설

임시 대기열은 request-response 와 같은 일반적인 메시지 패턴을 사용할 때 개발 시간과 배포 비용을 절약하는 데 도움이 됩니다 . 임시 대기열 클라이언트 를 사용할 수 있습니다.처리량이 높고 비용 효율적인 애플리케이션 관리 임시 대기열을 생성합니다.

클라이언트는 여러 임시 대기열 (특정 프로세스에 대한 요청 시 생성되는 애플리케이션 관리 대기열)을 단일 Amazon SQS 대기열에 자동으로 매핑합니다. 이를 통해 애플리케이션은 각 임시 대기열에 대한 트래픽이 적을 때 더 적은 수의 API 호출을 수행하고 더 높은 처리량을 얻을 수 있습니다. 임시 대기열이 더 이상 사용되지 않으면 클라이언트를 사용하는 일부 프로세스가 완전히 종료되지 않더라도 클라이언트는 임시 대기열을 자동으로 정리합니다.

다음은 임시 대기열의 이점입니다.

• 특정 스레드 또는 프로세스에 대한 경량 통신 채널 역할을 합니다.
• 추가 비용 없이 생성 및 삭제할 수 있습니다.
• 정적(일반) Amazon SQS 대기열과 API 호환됩니다. 즉, 메시지를 보내고 받는 기존 코드는 가상 대기열과 메시지를 주고받을 수 있습니다.

 

참조 문서

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-temporary-queues.html

Amazon SQS temporary queues - Amazon Simple Queue Service

 

20221117

기업은 느슨하게 결합되도록 밀접하게 연결된 애플리케이션을 재설계하고 있습니다. 이전에는 프로그램이 요청/응답 패턴을 통해 계층 간에 통신했습니다. 조직은 Amazon Simple Queue Service(Amazon SQS)를 사용하여 이를 수행하려고 합니다. 첫 번째 아키텍처는 요청 큐와 응답 큐를 포함합니다. 그러나 프로그램이 커질 때 이 전략은 모든 메시지를 처리하지 않습니다.

솔루션 아키텍트가 이 문제를 해결하기 위해 취해야 할 가장 좋은 조치는 무엇입니까?

지문에서 타이트하게 연결된 애플리케이션을 느슨하게 결합되도록 재설계한다고 한다.
SQS를 사용하여 프로그램이 요청/응답 패턴을 통해 계층 간에 통신을 하려고 한다. 하지만 프로그램이 커질 때 모든 메시지를 처리하지 않는다고 한다.

선택지를 먼저 보면 A "SQS 대기열의 ReceiveMessage API 작업에서 배달 못한 편지 대기열을 구성합니다." SQS 대기열의 API를 구축하여 응답을 받지 못한 메시지의 대기열을 구성하는게 좋은 솔루션 같지만, 해당 API 구축과 함께 공수가 많이 들기 때문에 우선은 보류한다.
선택지 B "FIFO 대기열을 구성하고 메시지 중복 제거 ID 및 메시지 그룹 ID를 사용합니다." 마찬가지로 대기열을 구성한다 자체가 공수가 많이 들며, 메시지 중복 제거 ID 및 메시지 그룹 ID를 사용하는것이 모든 메시지를 처리하도록 하는 솔루션인지는 의구심이 든다.
선택지 C "각 응답 메시지를 수신할 임시 대기열 클라이언트를 사용하여 임시 대기열을 만듭니다." 모든 메시지가 처리되지 않았을때 임시로 대기열을 사용하는것이 어쩌면 대기열을 만들어서 사용하는것보다는 더 효율적이라 판단된다.