대기열 소비자를 위한 주문 이벤트 변환

소개

생산자는 전체 주문 이벤트를 보내지만 소비자에게는 주문 ID와 수량만 필요합니다. 라우팅 필터를 유지하면서 두 이벤트를 간결한 대기열 메시지로 변환합니다.

EventBridge는 들어오는 이벤트를 조건과 비교하고 메시지를 보관하는 큐인 SQS로 라우팅합니다. CLI 액세스는 이미 구성되어 있으며 개인 AWS 계정이나 액세스 키는 필요하지 않습니다.

EventBridge로 주문 이벤트 라우팅을 먼저 완료하세요. 독립적인 VM에서 이 파이프라인을 구축하세요. 이전 버스, 규칙이나 대기열은 재사용하지 않습니다.

인증 시험 관련 주제

실습 개요

독립적인 라우팅 리소스 준비

이 단계에서는 주문 이행 작업을 위한 사용자 지정 버스와 빈 대기열을 만듭니다.

위쪽 AWS View를 사용하여 CLI 쿼리를 이 실습의 실제 리소스 및 결과와 비교하세요. 제공된 참조 데이터를 유지하세요.

생산자 이벤트에는 라우팅 메타데이터, 고객 정보와 중첩된 주문이 포함됩니다. 대기열 소비자에게는 주문 ID와 수량만 필요합니다. 입력 변환은 이벤트에서 필드를 선택하여 대상 본문을 구성하고 소비자가 생산자의 봉투에 의존하는 정도를 줄입니다.

이 새 작업 공간에는 설정된 CLI 접근과 관련 없는 참조 데이터가 있습니다. EV01 리소스는 재사용하지 않습니다. 프로젝트 디렉터리에서 시작하세요. 셸 할당은 반환된 식별자를 저장하고 --query는 응답 필드를 선택하며 --output text는 다음 명령에서 해당 필드를 재사용할 수 있게 합니다.

cd /home/labex/project
BUS_NAME=labex-ev02-bus

다음 작업에 사용할 RULE_NAME을 설정하세요:

RULE_NAME=labex-ev02-orders

실습 이벤트 버스을(를) 생성하세요:

aws events create-event-bus --name "$BUS_NAME"

반환된 값을 QUEUE_URL에 저장하세요:

QUEUE_URL=$(aws sqs create-queue \
  --queue-name labex-ev02-jobs \
  --query QueueUrl \
  --output text)
echo "$QUEUE_URL"

반환된 값을 QUEUE_ARN에 저장하세요:

QUEUE_ARN=$(aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names QueueArn \
  --query Attributes.QueueArn \
  --output text)
echo "$QUEUE_ARN"

버스 ARN은 이벤트 대상을 식별합니다. 대기열 URL은 메시지 작업에 사용하며 ARN은 규칙 대상을 식별합니다. 초기 상태를 확인하세요.

aws events list-rules --event-bus-name "$BUS_NAME"

큐 $QUEUE_URL의 속성을 확인하세요:

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

규칙이나 메시지가 없습니다. 위쪽 AWS View에서 동일한 사용자 지정 버스와 빈 대기열을 확인하세요. 준비 검사를 실행하세요.

입력 변환기가 있는 대상 연결

이 단계에서는 접수된 주문을 일치시키고 규칙에 권한을 부여하며 간결한 소비자 페이로드를 정의합니다.

규칙의 패턴은 생산자와 이벤트 범주를 일치시킵니다. 따옴표가 있는 here-document는 셸 확장 없이 리터럴 JSON을 씁니다. file://는 해당 파일을 CLI 요청으로 읽습니다.

EV01의 라우팅과 소스 규칙 권한을 재사용해 독립적인 파이프라인을 구성합니다. 이번에 새로 설계하는 것은 소비자 계약입니다. 대상은 일치하는 이벤트를 대기열 소비자에게 필요한 필드로 변환합니다. 필터는 여전히 어떤 이벤트가 대상에 도달하는지 결정합니다.

cat > order-pattern.json <<'JSON'
{"source":["labex.orders"],"detail-type":["OrderPlaced"]}
JSON

반환된 값을 RULE_ARN에 저장하세요:

RULE_ARN=$(aws events put-rule \
  --name "$RULE_NAME" \
  --event-bus-name "$BUS_NAME" \
  --event-pattern file://order-pattern.json \
  --state ENABLED \
  --query RuleArn \
  --output text)
echo "$RULE_ARN"

대기열에는 정확한 소스 규칙 권한이 필요합니다. 대기열과 규칙 ARN을 사용하여 일반 정책 JSON을 작성하세요. 이후 --rawfile은 이를 문자열 값인 SQS Policy 속성으로 인코딩합니다.

cat > queue-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sqs:SendMessage",
      "Resource": "$QUEUE_ARN",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "$RULE_ARN"
        }
      }
    }
  ]
}
EOF

구성을 queue-attributes.json에 작성하세요:

jq -n --rawfile policy queue-policy.json '{Policy:$policy}' > queue-attributes.json

큐 $QUEUE_URL에 속성을 적용하세요:

aws sqs set-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attributes file://queue-attributes.json

InputPathsMap은 JSONPath로 선택한 필드에 이름을 부여합니다. $는 이벤트의 루트를 의미하고 $.detail.order.id는 중첩된 주문 ID를 선택합니다. InputTemplate은 꺾쇠괄호 자리 표시자로 메시지를 구성합니다. ID 자리 표시자는 JSON 문자열 따옴표 안에 있습니다. 수량은 JSON 숫자이므로 따옴표가 없습니다. 예시는 간단한 ID와 양의 정수 수량을 사용합니다.

cat > targets.json <<EOF
[
  {
    "Id": "order-queue",
    "Arn": "$QUEUE_ARN",
    "InputTransformer": {
      "InputPathsMap": {
        "id": "\$.detail.order.id",
        "quantity": "\$.detail.order.quantity"
      },
      "InputTemplate": "{\"id\":\"<id>\",\"quantity\":<quantity>}"
    }
  }
]
EOF

이벤트 규칙의 전달 대상을(를) 적용하세요:

aws events put-targets \
  --rule "$RULE_NAME" \
  --event-bus-name "$BUS_NAME" \
  --targets file://targets.json

이벤트 규칙의 전달 대상을(를) 확인하세요:

aws events list-targets-by-rule --rule "$RULE_NAME" --event-bus-name "$BUS_NAME"

FailedEntryCount는 0입니다. 나열된 대상에는 본인의 대기열 ARN과 두 매핑 경로/템플릿이 포함됩니다. 설정이 성공해도 실제 전달 테스트가 필요합니다. AWS View는 활성화된 규칙과 변환기를 보여 주며 대기열은 여전히 비어 있습니다. 연결 검사를 실행하세요.

두 실제 소비자 페이로드 비교

이 단계에서는 서로 다른 접수 주문 두 개를 게시하고 생성된 대기열 메시지를 확인합니다.

이벤트 세부 정보를 일반 JSON 객체로 작성하세요. PutEvents는 각 Detail이 JSON으로 인코딩된 문자열이어야 합니다. 아래의 짧은 jq 명령은 해당 필드만 변환합니다. 각 이벤트에는 주문 이행 소비자에게 필요하지 않은 테스트용 고객 정보도 포함됩니다. 세 번째 취소 이벤트는 라우팅 필터가 여전히 적용되는지 테스트합니다.

cat > event-inputs.json <<EOF
[
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderPlaced",
    "Detail": {
      "order": {
        "id": "transform-order-a",
        "quantity": 2
      },
      "customer": {
        "email": "synthetic-a@example.test"
      }
    }
  },
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderPlaced",
    "Detail": {
      "order": {
        "id": "transform-order-b",
        "quantity": 4
      },
      "customer": {
        "email": "synthetic-b@example.test"
      }
    }
  },
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderCancelled",
    "Detail": {
      "order": {
        "id": "cancelled-order",
        "quantity": 9
      }
    }
  }
]
EOF

구성을 events.json에 작성하세요:

jq 'map(.Detail |= tojson)' event-inputs.json > events.json

제공된 이벤트 배치를 게시하세요:

aws events put-events --entries file://events.json

큐 $QUEUE_URL의 속성을 확인하세요:

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

세 이벤트는 모두 접수되지만 접수 주문 두 개만 일치합니다. 대기열에는 사용 가능한 메시지 두 개가 있습니다. 표시 제한 시간을 0으로 하여 수신하면 확인 직후 메시지를 다시 사용할 수 있습니다. 쿼리는 메시지 ID와 본문만 표시하여 수신 핸들을 비공개로 유지합니다.

fromjson은 SQS 메시지 ID를 유지하면서 각 JSON 본문을 읽기 쉽게 만듭니다. 표시되는 출력만 변경합니다.

aws sqs receive-message \
  --queue-url "$QUEUE_URL" \
  --max-number-of-messages 10 \
  --visibility-timeout 0 \
  --output json | jq '[.Messages[] | {MessageId, Body: (.Body | fromjson)}]'

본문은 {"id":"transform-order-a","quantity":2}와 {"id":"transform-order-b","quantity":4}입니다. 순서는 평가하지 않습니다. 각각 서로 다른 메시지 ID와 해당 이벤트에서 나온 값을 갖습니다. 둘 다 고객 이메일, 라우팅 메타데이터나 중첩된 order 객체를 포함하지 않습니다. 취소된 주문은 없습니다. 이는 변환과 전달을 증명하며 주문 이행 완료나 메시지 확인 처리를 증명하지는 않습니다.

AWS View는 대상 매핑을 실제 간결한 대기열 본문 옆에 보여 줍니다.

페이로드 검사를 실행하세요.

일회용 파이프라인 제거

이 단계에서는 라우팅 리소스를 제거하고 관련 없는 상태를 유지합니다.

규칙보다 먼저 대상을 제거한 다음 사용자 지정 버스와 대기열을 삭제하세요. 대기열에는 확인용 테스트 메시지만 들어 있습니다. 삭제하면 비즈니스 처리를 주장하지 않고 이를 버립니다.

aws events remove-targets \
  --rule "$RULE_NAME" \
  --event-bus-name "$BUS_NAME" \
  --ids order-queue

실습 이벤트 규칙만 삭제하세요:

aws events delete-rule --name "$RULE_NAME" --event-bus-name "$BUS_NAME"

실습 이벤트 버스만 삭제하세요:

aws events delete-event-bus --name "$BUS_NAME"

실습 큐 $QUEUE_URL을 삭제하세요:

aws sqs delete-queue --queue-url "$QUEUE_URL"

성공한 네이티브 인벤토리 쿼리가 삭제를 증명합니다.

aws events list-event-buses

남아 있는 이벤트 규칙을(를) 확인하세요:

aws events list-rules --event-bus-name default

남아 있는 SQS 큐을(를) 확인하세요:

aws sqs list-queues

실습과 관련 없는 참조 레코드을(를) 확인하세요:

aws dynamodb scan --table-name labex-ev02-reference --query Items

규칙이 없는 기본 버스만 남고 대기열 URL은 없습니다. 참조 항목에는 여전히 keep unchanged가 있습니다. 네트워크 오류나 인증 오류는 삭제를 증명하지 않습니다. AWS View는 빈 사용자 지정 리소스와 유지된 참조를 보여 줍니다.

이 실습에서 만든 일반 파일을 제거하세요.

rm -f event-inputs.json order-pattern.json queue-policy.json queue-attributes.json targets.json events.json

VM을 종료하기 전에 정리 검사를 실행하세요.

요약

중첩된 주문 필드를 간결한 SQS 소비자 데이터 형식에 매핑하고 두 실제 이벤트의 서로 다른 값을 검증했으며 이벤트 필터링과 소스 규칙 권한을 유지했습니다. 참조 데이터를 유지하면서 일회용 파이프라인을 제거했습니다.

다음 단원은 Lambda–DynamoDB 선수 지식을 갖춘 뒤 시작하는 독립적인 워크플로 분기이며, 이 이벤트 라우팅 파이프라인에 의존하지 않습니다.

자세한 내용은 AWS 공식 문서를 참고하세요: 입력 경로 및 대상 페이로드 템플릿.