Amazon SQS 메시지 작업

다음 지침을 통해 Amazon SQS를 사용하여 메시지를 효율적으로 처리할 수 있습니다.

적시에 메시지 처리

제한 시간 초과 설정은 애플리케이션에서 메시지를 처리하고 삭제하는 데 얼마나 걸리느냐에 따라 다릅니다. 예를 들어 애플리케이션에서 메시지를 처리하려면 10초가 필요한데 제한 시간 초과 값을 15분으로 설정한다면, 이전의 메시지 처리 시도가 실패할 경우 다시 메시지 처리를 시도하기 위해 비교적 오랜 시간을 기다려야 합니다. 또한 애플리케이션에서 메시지를 처리하려면 10초가 필요한데 제한 시간 초과 값을 불과 2초로 설정한다면, 원래 소비자가 아직 메시지를 처리하는 동안 다른 소비자로부터 중복 메시지를 받을 수 있습니다.

메시지 처리 시간을 충분히 확보하려면 다음 전략 중 하나를 사용하세요.

• 메시지 처리 소요 시간을 알고 있거나 합리적으로 추정할 수 있는 경우, 메시지의 제한 시간 초과를 메시지 처리와 삭제에 소요되는 최대 시간으로 연장합니다. 자세한 내용은 표시 제한 시간 구성을 참조하세요.

• 메시지를 처리하는 데 걸리는 시간을 모르는 경우 소비자 프로세스에 대한 하트비트를 생성합니다. 초기 표시 제한 시간(예: 2분)을 지정한 다음 소비자가 메시지에서 계속 작업하는 경우 표시 제한 시간을 1분마다 2분씩 연장합니다.

  중요

  최대 표시 제한 시간은 Amazon SQS가 ReceiveMessage 요청을 수신한 시간으로부터 12시간입니다. 표시 제한 시간을 연장해도 최대 12시간이 재설정되지는 않습니다.

  또한 ReceiveMessage 요청으로 타이머가 시작되기 때문에 개별 메시지의 제한 시간을 전체 12시간(예: 43,200초)으로 설정하지 못할 수도 있습니다. 예를 들어 메시지를 수신한 후 VisibilityTimeout이 43,200초인 ChangeMessageVisibility 호출을 전송하여 즉시 최대 12시간을 설정하면 실패할 가능성이 높습니다. 하지만 43,195초 값을 사용하면 ReceiveMessage를 통해 메시지를 요청하는 것과 표시 제한 시간을 업데이트하는 것 사이에 상당한 지연이 있는 경우가 아니면 작동합니다. 소비자에게 12시간 이상 필요한 경우 Step Functions 사용을 고려하세요.

요청 오류 처리

요청 오류를 처리하려면 다음 전략 중 하나를 사용하십시오.

• AWS SDK를 사용하는 경우, 이미 자동 재시도 및 백오프 로직을 사용할 수 있습니다. 자세한 내용은 Amazon Web Services 일반 참조의 AWS의 오류 재시도 및 지수 백오프 단원을 참조하세요.

• 재시도 및 백오프에 AWS SDK 기능을 사용하지 않는 경우 Amazon SQS로부터 메시지가 수신되지 않거나, 시간 초과 또는 오류 메시지가 수신되면 ReceiveMessage 작업을 재시도하기 전에 일시 중지(예: 200ms)를 허용하세요. 그 다음에 동일한 결과를 반환하는 ReceiveMessage를 사용하려면, 더 긴 일시 중지 시간(예: 400ms)을 둡니다.

긴 폴링 설정

ReceiveMessage API 작업에 대한 대기 시간이 0보다 큰 경우 긴 폴링이 유효합니다. 긴 폴링 대기 시간의 최대값은 20초입니다. 긴 폴링은 빈 응답 수를 줄이고(ReceiveMessage 요청에 사용 가능한 메시지가 없는 경우) 거짓의 빈 응답을 제거하여(메시지를 사용할 수 있지만 응답에 포함되지 않은 경우) Amazon SQS 사용 비용을 줄여 줍니다. 자세한 내용은 Amazon SQS 짧은 폴링 및 긴 폴링 섹션을 참조하세요.

메시지 처리를 최적화하려면 다음 전략을 사용하세요.

• 대부분의 경우 ReceiveMessage 대기 시간을 20초로 설정할 수 있습니다. 애플리케이션에 20초가 너무 긴 경우 ReceiveMessage 대기 시간을 더 짧게 설정할 수 있습니다(최소값은 1초). Amazon SQS에 액세스하는 데 AWS SDK를 사용하지 않거나 더 짧은 대기 시간을 갖도록 AWS SDK를 구성하는 경우, 더 긴 요청을 허용하거나 긴 폴링에 더 짧은 대기 시간을 사용하도록 Amazon SQS 클라이언트를 수정해야 할 수도 있습니다.

• 여러 대기열에 대해 긴 폴링을 구현할 경우에는 모든 대기열에 단일 스레드를 사용하지 말고 각 대기열마다 하나의 스레드를 사용하는 것이 좋습니다. 각 대기열마다 하나의 스레드를 사용하면 애플리케이션이 각 대기열에서 메시지를 사용 가능한 즉시 처리할 수 있지만, 하나의 스레드를 사용하여 여러 대기열을 폴링하면 애플리케이션이 사용 가능한 메시지가 없는 대기열을 대기하느라(최대 20초) 다른 대기열에서 사용 가능한 메시지를 처리하지 못하게 될 수 있습니다.

중요

HTTP 오류를 방지하려면 ReceiveMessage 요청에 대한 HTTP 응답 제한 시간이 WaitTimeSeconds 파라미터보다 긴지 확인합니다. 자세한 내용은 ReceiveMessage를 참조하십시오.

문제가 있는 메시지 캡처

처리할 수 없는 모든 메시지를 캡처하고 정확한 CloudWatch 지표를 수집하려면 배달 못한 편지 대기열을 구성합니다.

• 소스 대기열이 지정된 횟수까지 메시지를 처리하지 못하고 나면 리드라이브 정책에 따라 메시지를 배달 못한 편지 대기열로 리디렉션합니다.

• 배달 못한 편지 대기열을 사용하면 메시지 개수가 감소하고 사용자가 독약 메시지(수신하지만 처리 불가능한 메시지)를 받을 가능성이 낮아집니다.

• 대기열에 독약 메시지가 포함되면 독약 메시지의 잘못된 수명 지정으로 인해 ApproximateAgeOfOldestMessage CloudWatch 지표가 왜곡될 수 있습니다. 배달 못한 편지 대기열을 구성하면 이 측정치를 사용할 때 거짓 경보를 방지할 수 있습니다.

배달 못한 편지 대기열 보존 설정

표준 대기열의 경우, 메시지 만료는 항상 메시지가 원래 대기열에 추가된 타임스탬프를 기준으로 합니다. 메시지가 배달 못한 편지 대기열로 이동하면 대기열에 추가 타임스탬프는 변경되지 않습니다. ApproximateAgeOfOldestMessage 지표는 메시지가 원래 전송된 시간이 아니라 메시지가 배달 못한 편지 대기열로 이동한 시간을 나타냅니다. 예를 들어, 메시지가 배달 못한 편지 대기열로 이동하기 전에 원래 대기열에서 1일을 보낸다고 가정합니다. 배달 못한 편지 대기열의 보존 기간이 4일인 경우 메시지는 3일 후에 배달 못한 편지 대기열에서 삭제되며 ApproximateAgeOfOldestMessage는 3일입니다. 따라서 배달 못한 편지 대기열의 보존 기간을 항상 원래 대기열의 보존 기간보다 더 길게 설정하는 것이 좋습니다.

FIFO 대기열의 경우 메시지가 배달 못한 편지 대기열로 이동하면 대기열에 추가 타임스탬프가 재설정됩니다. ApproximateAgeOfOldestMessage 지표는 메시지가 배달 못한 편지 대기열로 이동한 시간을 나타냅니다. 위의 동일한 예에서 메시지는 4일 후에 배달 못한 편지 대기열에서 삭제되며 ApproximateAgeOfOldestMessage는 4일입니다.

일관되지 않은 메시지 처리 방지

Amazon SQS는 분산 시스템이므로 메시지가 ReceiveMessage API 메서드 호출에서 성공적으로 반환되고 Amazon SQS에서 배달된 것으로 표시되더라도 소비자가 해당 메시지를 받지 못할 수 있습니다. 이 경우 Amazon SQS는 소비자가 수신한 적이 없는 메시지를 한 번 이상 배달된 것으로 기록합니다. 이 상태에서는 메시지 배달이 추가로 시도되지 않으므로 배달 못한 편지 대기열의 최대 수신 수를 1로 설정하지 않는 것이 좋습니다.

요청-응답 시스템 구현

요청 응답 또는 RPC(원격 프로시저 호출) 시스템을 구현할 경우에는 다음 모범 사례에 유의하십시오.

• 메시지별로 응답 대기열을 생성하지 마십시오. 그 대신 시작할 때 생산자별로 응답 대기열을 생성하고 상관 ID 메시지 속성을 사용하여 응답을 요청에 매핑합니다.

• 생산자가 응답 대기열을 공유할 수 없도록 하십시오. 이로 인해 생산자는 다른 생산자를 위한 응답 메시지를 수신할 수 있습니다.

임시 대기열 클라이언트를 사용하여 요청-응답 패턴을 구현하는 방법에 대한 자세한 내용은 요청-응답 메시징 패턴(가상 대기열) 단원을 참조하십시오.