SNS, SQS 생성하기
1. SNS 생성하기
1. AWS SNS 페이지로 이동하자.
- AWS 콘솔창에서 'SNS'를 검색해서 이동하자.
2. SNS 페이지에서 "주제 생성" 영역에서 '주제 이름'을 작성하고 [다음 단계]를 클릭한다.
- 나는 테스트 용도로 'sns-test'로 작성했다.
3. 그럼 "주제 생성" 페이지로 이동한다.
- "세부 정보"에서 "유형"을 선택한다.
- FIFO 선택 경우
- 중복 메시지 없음: FIFO 주제는 메시지의 중복 전달을 허용하지 않는다.
- 순서 보장: 메시지는 정확히 한 번씩, 전송된 순서대로 처리된다.
- 제한된 처리량: 표준 주제에 비해 처리량이 낮으며, 특정 제한이 있다.
- 보다 엄격한 메시지 필터링: 메시지 필터링이 표준 주제보다 더 엄격하다.
- 사용 사례: 금융 거래 처리, 주문 시스템, 순차적 이벤트 처리 등 메시지의 순서와 중복 여부가 중요한 상황에서 적합하다.
- 표준 선택 경우
- 중복 메시지 허용: 표준 주제는 때때로 메시지를 중복으로 전달할 수 있다. 즉, 가끔 같은 메시지가 두 번 이상 전달될 수 있다.
- 높은 처리량: 표준 주제는 무제한의 처리량을 지원한다.
- 순서 보장 없음: 메시지는 전송된 순서와 다를 수 있으며, 이는 메시지가 순서대로 처리될 필요가 없는 경우에 적합하다.
- 유연성: 다양한 시나리오에 적용 가능하며, 대부분의 애플리케이션에서 사용된다.
- 사용 사례: 데이터 트랙킹, 알람, 비동기 처리 등 순서에 민감하지 않고, 중복 메시지가 크게 문제가 되지 않는 상황에서 적합하다.
- 지금 테스트 같은 경우 순서가 중요하지 않기 때문에 "표준"을 선택했다.
4. 주제 이름은 아까 첫 페이지에서 입력된 값이 미리 작성되어 있다. 물론 수정 가능하다.
- 표시 이름을 작성할 경우 SMS 구독과 함께 사용되기 때문에 나는 작성하지 않았다.
5. 나머지 값들은 건들지 않고 전부 default값으로 두었다. 그리고 하단에 [주제 생성]을 클릭한다.
6. SNS 주제가 생성되었다고 알림이 뜨면서 해당 주제 상세 화면으로 이동된다.
7. SNS 구독은 엔드 포인트를 지정해줘야 하기 때문에 SQS를 먼저 생성해야 한다.
2. SQS 생성하기
1. SQS 화면으로 이동하고 "시작하기" 영역에 있는 "대기열 생성"을 클릭한다.
2. 대기열 생성 페이지에서 "유형"을 선택한다.
- "세부 정보"에서 "유형"을 선택한다.
- 표준 선택 경우
- 높은 처리량: 표준 큐는 무제한의 처리량을 지원한다.
- 최소한 한 번의 전달: 메시지는 최소 한 번 이상 전달됩니다. 때때로 메시지가 중복으로 전달될 수 있다.
- 순서 보장 없음: 메시지는 대체로 전송된 순서대로 도착하지만, 이 순서는 보장되지 않는다.
- 사용 사례: 순서가 중요하지 않은 대량의 메시지를 처리할 때, 예를 들어 웹 트래픽 분석이나 로깅과 같은 상황에서 효과적이다.
- FIFO 선택 경우
- 순서 보장: 메시지는 정확히 한 번씩, 전송된 순서대로 전달된다.
- 중복 없음: 메시지는 큐에 한 번만 추가된다. FIFO 큐는 메시지의 중복을 허용하지 않는다.
- 제한된 처리량: FIFO 큐는 표준 큐에 비해 상대적으로 낮은 처리량을 가지며, 이는 특정 TPS(초당 트랜잭션 수)로 제한된다.
- 사용 사례: 순서와 중복이 중요한 작업에 적합하다. 예를 들어, 은행 거래나 주문 시퀀스 처리와 같은 상황에서 사용된다.
- 나는 순서 보장이 필요 없기 때문에 표준을 선택했다.
3. 그리고 이름을 입력해 준다.
- 나는 sqs-test로 입력했다.
4. 구성에서 왼쪽 박스는 그대로 두고 오른쪽 박스는 설정할 수 있다.
- 표시 제한 시간
- 한 컨슈머가 대기열에서 수신한 메시지가 다른 메시지 컨슈머에게 보이지 않게 되는 시간이다.
- 컨슈머가 메시지를 가져가고, 처리 및 삭제하지 못하면 다른 컨슈머에게 메시지가 보이게 된다. (즉, 1번만 메시지 보여야 하는 경우라면 시간 내 삭제 필요)
- 기본값은 30초 (컨슈머가 처리하는 시간에 따라 조정 필요)
- 한번 설정하면 큐 내부의 모든 메시지에 대해서 적용이 된다.
- 최적의 성능을 위해서 표시 제한 시간 초과는 AWS SDK 읽기 제한 시간보다 길게 설정해야 한다.
- 전송 지연
- 이 대기열에 추가된 각 메시지의 첫 번째 전송에 대한 지연 시간이다.
- 지정된 시간 동안 메시지는 컨슈머에게 소비되지 않고 지연된다.
- 0초 ~ 15분까지 설정 가능하고
- Standard는 한번 설정된 시간은 계속 흘러 지연되었다가 진행된다.
- FIFO는 설정을 변경하면 이후 메시지부터 적용된다.
- 메시지 수신 대기 시간
- 폴링이 메시지를 사용할 수 있을 때까지 기다리는 최대 시간이다.
- 0초 ~ 20초까지 가능하고
- 긴 폴링은 빈 응답수 (ReceiveMessage 요청에 사용할 수 메시지가 없는 경우)와 잘못된 빈 응답(메시지를 사용할 수 있지만 응답에 포함되지 않은 경우)을 제거하여 Amazon SQS 사용 비용을 줄일 수 있다.
- 수신 요청이 최대 메시지 수를 수집하면 즉시 반환되고
- 0으로 설정하면 짧은 폴링이 된다.
- 메시지 보존 기간
- Amazon SQS 가 삭제 되지 않은 메시지를 보관하는 시간이다.
- 보존기간 범위 60초(1분) ~ 1,209,600초(14일)까지 가능하고
- 대기열, 배달하지 못한 메시지 대기열 통합 시간이다. (그러므로 배달 못한 메시지 대기열의 보존 기간을 원래 대기열의 보존 기간보다 길제 잡아야 한다.)
- 최대 메시지 크기
- 이 대기열에 최대 메시지 크기이다.
- 1바이트 ~ 256KB까지 크기 가능하고
- 256KB보다 큰 메시지 전송 시에는 Amazon SQS Extended Client Library를 이용 전송 가능하다.
- Amazon S3에 메시지 로드에 대한 참조가 포함된 메시지 전송
- 최대 크기는 2GB까지 가능하다.
5. 암호화는 기본이 "활성화됨"에 체크되어 있어서 "비활성화됨"으로 선택해 줬다.
6. 액세스 정책 설정이다. 이것도 기본으로 선택했다.
- 기본적으로 대기열 소유자만 큐에 액세스 할 수 있지만
- 아래 커스텀 역할을 눌러서 다른 계정, 역할 또는 대기열에 메시지를 보낼 수 있는 IAM 사용자를 설정할 수 있다.
- S3 나 SNS와 통합할 때 유용하다고 한다.
7. 리드라이브 허용 정책을 설정한다.
- 리드라이브 허용 정책은 메인 대기열에 있는 메시지가 처리되지 못할 때 그 메시지를 어떻게 처리할지 정의한다.
- 이 정책은 실패한 메시지를 얼마나 많은 횟수까지 처리를 시도할 것인지(최대 수신 횟수), 그리고 실패한 메시지를 어떤 DLQ로 보낼 것인지를 설정한다.
- 이 정책을 활성화하면, 메시지가 최대 시도 횟수만큼 처리를 시도한 후에도 여전히 처리되지 않으면, 해당 메시지는 데드레터 대기열(Dead-Letter Queue, DLQ)로 전송된다.
- 이 정책을 비활성화하면, 처리에 실패한 메시지를 다루는 자동화된 방법이 없어, 실패한 메시지가 계속해서 메인 대기열에 남아 있게 되고, 이는 다른 메시지의 처리를 지연시킬 수 있다. 그리고 실패한 메시지를 수동으로 관리해야 하는 부담이 생기며, 시스템의 복잡성이 증가한다.
- 나는 추후 Application Code 단계에서 실패된 메시지를 처리하는 로직을 구현할 것이기 때문에 "비활성화됨"을 선택했다.
8. 배달 못한 편지 대기열을 설정한다.
- DLQ는 처리에 실패한 메시지를 분리하여 저장하는 대기열이다.
- 리드라이브 허용 정책에 의해 메시지가 DLQ로 전송되면, 개발자는 이 대기열에서 메시지를 검토하고 문제를 해결할 수 있다.
- 리드라이브 허용 정책이 활성화되어 있고 DLQ가 지정되어 있으면, 메시지가 메인 대기열에서 설정된 최대 수신 횟수를 초과하여 실패하면 DLQ로 이동한다.
- 리드라이브 허용 정책이 비활성화되어 있거나 DLQ가 지정되지 않은 경우, 메시지는 실패 후에도 메인 대기열에 남아 있게 되고, 이는 다른 메시지의 처리에 영향을 줄 수 있다.
- 나는 추후 Application Code 단계에서 실패된 메시지를 처리하는 로직을 구현할것이기 때문에 "비활성화됨"을 선택했다.
- 만약 "활성화됨"을 선택했다면 미리 DLQ 담당 SQS를 생성하고 "대기열 선택"에서 DLQ를 담당할 SQS ARN을 선택하면 된다.
9. 태그는 입력하지 않고 [대기열 생성]을 클릭한다.
10. 그럼 생성한 대기열 상세 페이지로 이동된다.
3. SQS 대기열에서 SNS 주제 구독하기
1. 방금 생성한 SQS 대기열 하단에 "SNS 구독" 탭에서 [Amazon SNS 주제 구독] 버튼을 클릭한다.
2. Amazon SNS 주제 구독 페이지로 이동된다. 여기서 방금 생성한 SNS를 선택한다. 그리고 [저장]을 클릭한다.
3. 구독에 성공하면 SQS 대기열 상세 페이지 "SNS 구독"탭에서 구독 정보가 추가된 모습을 확인할 수 있다.
4. SNS 주제 상세 페이지에서 확인해도 "구독"탭에 SQS가 추가된 모습을 확인할 수 있다.
4. SNS에서 메시지 게시 후 SQS 대기열에서 메시지 확인
1. SNS 주제에서 [메시지 게시]를 클릭한다.
2. 메시지 게시 화면에서 "제목"은 선택 사항이지만 일단 입력해 줬다.
- 입력하지 않아도 아무 문제없다.
3. 메시지 본문에 데이터를 입력한다.
3. 메시지 속성은 건들지 않고 [메시지 게시]를 클릭한다.
4. 그럼 메시지 게시에 성공했다는 알림이 뜬다.
5. 이제 SQS 페이지로 이동하면 대기열 목록에서 "사용 가능한 메시지"가 1로 늘어난 걸 확인할 수 있다.
6. 이름을 클릭해 대기열 상세 페이지로 이동해서 상단에 "메시지 전송 및 수신"을 클릭한다.
7. 이동된 페이지에서 스크롤을 내리면 "메시지 수신" 항목이 있다. 여기서 [메시지 풀링]을 클릭한다.
8. 그럼 풀링 진행 상황이 업데이트되면서 메시지 목록에 메시지가 보이게 된다.
9. 메시지 ID를 클릭하면 팝업이 뜬다.
- 내가 작성한 제목과 본문이 잘 보인다.
10. 이렇게 SNS와 SQS를 AWS 콘솔을 이용해서 연동에 성공했다.
5. 마무리
이번 포스팅에서 SNS와 SQS를 AWS 콘솔을 통해 성공적으로 연동하는 과정을 살펴보았다.
다음 포스팅에서는 이 연동을 바탕으로 Spring Boot 애플리케이션에서 이벤트를 발행하고 처리하는 전체 흐름을 구현해 볼 예정이다.
실제 마이크로서비스 아키텍처에서 이벤트 기반 통신이 어떻게 이루어지는지, 그리고 이를 통해 어떻게 시스템의 결합도를 낮추고 확장성을 높일 수 있는지에 대해 같이 알아보자.
[AWS] ECS 생성1 - ECR 생성하기 (M1 Mac 제외)
[AWS] ECS 생성1 - ECR 생성하기 (M1 Mac 제외)
내가 진행하고 싶은 프로젝트의 CI/CD는 AWS CodePipeline을 통해 프로젝트 배포를 trigger 하고, Amazon ECR에 도커 이미지를 push 하고, Amazon ECS에서 이미지를 pull 받아 태스크를 실행하는 프로세스를 구상
yijoon009.tistory.com
'AWS' 카테고리의 다른 글
| [AWS] ECS에서 Zipkin을 통한 스프링 부트 서비스 트레이싱 구축하기 (0) | 2023.11.19 |
|---|---|
| [AWS] SNS, SQS 연동하기 (2) - Spring Boot 3.X.X 버전과 SNS, SQS 연동하기 (2) | 2023.11.06 |
| [AWS] IAM MFA 설정하기 (1) | 2023.11.05 |
| [AWS] ECS, ALB - 동적 포트 매핑 활성화와 DNS 접속 (1) | 2023.11.05 |
| [AWS] ECS 배포 실패해도 서버가 다운 안되는 이유 - ECS 서비스 롤링 업데이트 방식 (1) | 2023.11.04 |
