180. 메시징 소개
미들웨어로 다른 서비스간 합동 작업을 하는 방법을 살펴볼 거거든요
이 섹션에서는 애플리케이션을 여러 개 배포하려고 할 때 커뮤니케이션을 할 수 밖에 없습니다. 여러분의 서비스는 정보와 데이터를 공유해야 하죠.
그리고 애플리케이션 커뮤니케이션은 두 가지 패턴으로 나뉘어집니다.
먼저 동기 커뮤니케이션이 있습니다. 애플리케이션이 또 다른 애플리케이션과 직접적으로 연결되는 거죠.
가령 온라인으로 물건을 사고 파는 서비스가 있다고 했을 때 물건이 판매가 되면 배송 서비스에 연락해서 방금 판매된 물건을 배송해야 합니다. 여기 보실 수 있는 것처럼 구매 서비스와 배송 서비스는 직접적으로 연결되어 있기 때문에 동기 커뮤니케이션이 발생하고 있습니다. 구매 서비스가 배송 서비스에게 사건이 발생했으니 배송을 하라고 얘기하는 거죠
다른 유형의 통합은 비동기 혹은 이벤트 기반 유형입니다. 대기열 등으로 불리는 미들웨어가 애플리케이션들을 연결합니다. 이런 경우에는 구매 서비스가 '누군가가 어떤 물건을 구매했으니 이를 대기열에 포함시키겠다'라고 하겠죠 그리고 끝입니다. 그러면 배송 서비스가 대기열에게 최근 구매 내역이 있는지 물어봅니다. 대기열이 해당 요소를 반환하면 배송 서비스는 자기가 원하는 것을 무엇이든지 할 수 있습니다. 여기 보시는 것처럼 구매 서비스와 배송 서비스는 직접 연결되어 있지 않죠. 그 사이에 대기열이 있습니다 서로 직접적으로 소통하지 않기 때문에 비동기적이라고 하는 겁니다.
어플리케이션 간의 동기화는 때때로 문제가 될 수 있습니다. 구매가 갑자기 너무 증가했거나 한 서비스가 다른 서비스를 압도하는 경우 큰 문제가 되겠죠?
만일 비디오 인코딩 서비스에서 평소에는 10개만 인코딩 해오고 있었다면 1,000개의 비디오를 인코딩해야 하는데 인코딩 서비스가 압도될 것이고 운용이 정지되겠죠.
그래서 트래픽이 갑자기 급증하거나 아무것도 예측할 수 없을 때 일반적으로 애플리케이션을 분리하고 분리 계층을 확장하는 것이 좋습니다.
- 대기열 모델에는 SQS를
- pub/sub 모델의 경우 SNS를
- 실시간 스트리밍을 하고 대용량 데이터를 다룬다면 Kinesis로 분리할 수 있죠
이 섹션에서 이들을 모두 살펴볼 겁니다
그리고 이 세 가지를 사용하여 SQS, SNS와 Kinesis와 독립적으로 서비스를 확장할 수 있음을 배울 겁니다. 이 세 가지는 매우 잘 확장됩니다. 이것이 전체 패러다임이고 이 세 가지 기술을 배우는 것으로 시작할 겁니다 다음 강의에서 뵙겠습니다.
181. Amazon SQS - 표준 Queues 개요
SQS에 대해 살펴보겠습니다 SQS의 핵심은 대기열입니다. SQS는 간단한 대기 서비스이기 때문입니다
SQS 대기열에는 메시지를 포함할 겁니다. 메시지를 담기 위해서는 무언가 SQS 대기열에 메시지를 전송해야 하는데 SQS 대기열에 메시지를 보내는 주체를 생산자라고 합니다. 생산자는 한 개일 수도 그 이상일 수도 있습니다. 여러 생산자가 여러 개의 메시지를 SQS 대기열에 보내게 할 수 있습니다. 메시지는 무엇이든 상관없습니다. 가령 '오더를 처리해라'일 수도 있고 '비디오를 처리해라'일 수도 있죠. 생성한 모든 메시지는 대기열에 들어갑니다.
그런 다음 대기열에서 메시지를 처리하고 수신해야 하는 대상을 소비자라고 합니다. 소비자는 대기열에서 메시지를 폴링하는데 이는 대기열에게 소비자 앞으로 온 메시지가 있는지를 물어보는 겁니다. 만일 대기열에 메시지가 있으면 소비자는 이 메시지를 폴링해서 정보를 얻습니다.
그리고 그 메시지로 처리를 하고 대기열에서 그 메시지를 삭제합니다. 여러 소비자가 SQS 대기열에서 메시지를 소비할 수 있도록 할 수도 있습니다. 대기열 서비스는 생산자와 소비자 사이를 분리하는 버퍼 역할을 합니다. SQS는 복잡한 서비스입니다 이에 대해 자세히 살펴보겠습니다.
가장 먼저 제공되는 것은 표준 대기열용 Amazon SQS입니다.
SQS는 AWS에서 제공하는 가장 오래된 서비스입니다. AWS의 첫 번째 서비스 중 하나였습니다. 10년이 넘었으므로 작동 방식이 확실하게 구축되어 있죠.
완전 관리형 서비스이며 애플리케이션을 분리하는 데 사용됩니다. 시험에서 애플리케이션 분리에 대한 문제가 보이면 Amazon SQS을 생각하시면 됩니다.
그러면 SQS의 특별한 점은 무엇일까요?
무제한 처리량을 얻을 수 있다는 겁니다. 즉 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 포함시킬 수 있습니다. 처리량에 제한이 없고 대기열에 있는 메시지 수에도 제한이 없습니다.
각 메시지는 수명이 짧습니다 그게 무슨 뜻일까요? 메시지는 기본값으로 4일 동안 대기열에 남아 있고 대기열에 있을 수 있는 최대 시간은 14일입니다. 즉 대기열에 메시지를 보내자마자 소비자가 읽고 해당 보존 기간 내에 처리한 후 대기열에서 삭제해야 합니다. 그렇지 않으면 소실됩니다.
지연 시간이 짧아서 SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다. 게시 및 수신 시 10밀리초 이내로 매우 빠르게 응답을 받게 됩니다.
그리고 SQS의 메시지는 작아야 합니다. 전송된 메시지당 256KB 미만이어야 합니다.
SQS는 대기열 서비스이므로 높은 처리량, 높은 볼륨 등이 있어서 중복 메시지가 있을 수 있습니다. 예를 들어 메시지가 두 번 전송되는 경우가 있으므로 적어도 한 번의 전송이라고 하는 겁니다. 여러분이 애플리케이션을 작성하실 때 이 점을 염두에 두셔야 합니다.
최선의 오더라는 뜻으로 품절 메시지를 보낼 수도 있습니다. 그리고 그 제한을 처리할 수 있는 SQS의 또 다른 유형의 제품이 있긴 하지만 이 섹션의 뒷부분에서 설명하겠습니다.
이제 메시지 생산자로 돌아가 보겠습니다. 최대 256KB의 메시지가 생산자에 의해 SQS로 전송됩니다. 어떻게 보낼까요? 생산자는 SDK 소프트웨어 개발 키트를 사용하여 SQS에 메시지를 보낼 겁니다. SQS에 메시지를 보내는 API를 SendMessage라고 합니다. 매우 간단합니다 메시지가 작성되면
소비자가 해당 메시지를 읽고 삭제할 때까지 SQS 대기열에 유지됩니다 메시지가 삭제됐다는 것은 메시지가 처리됐다는 뜻이죠. 저희는 보존에 대해서는 알고 있습니다.
그렇다면 메시지 생성의 어떨 때 사용할까요?
예를 들어 패킷과 같은 오더를 처리한 다음 센터로 배송하려고 합니다. 따라서 원하는 시간에 이 작업을 수행하여
오더 ID,
고객 ID와
원하는 속성 등의 일부 정보가 포함된 메시지를 SQS 대기열로 보냅니다. 주소도 원하는 속성에 들어갈 수 있겠죠. 그러면 애플리케이션 권한에 있는 소비자는 해당 메시지 자체를 처리해야 합니다.
말씀드렸듯 표준 SQS는 무제한 처리량을 자랑하죠. 생산자에 대해 살펴보았습니다. 매우 간단합니다.
이제 소비자에 대해 살펴보겠습니다. 소비자는 일부 코드로 작성해야 하는 애플리케이션이고 이러한 애플리케이션은 EC2 인스턴스 즉 AWS 상의 가상 서버에서 실행될 수 있습니다. 원하는 경우 자체 온프레미스 서버에서 실행할 수도 있고 아직 배우지는 않았지만 AWS Lambda의 람다 함수에서 실행할 수도 있습니다. 이 강의에서 배우겠지만 서버가 없는 컴퓨터 유형의 서비스입니다. 이는 람다에서 메세지를 바로 읽을 수도 있다는 것을 의미합니다. 이 내용은 이후에 배울 것이니 걱정하지 마세요.
EC2 인스턴스에 대한 간단한 사용 사례로 돌아가 보면 대기열에는 소비가가 있고 소비자는 SQS 메시지를 폴링합니다. 즉 소비자가 대기열에 자신의 앞으로 온 메시지가 있는지를 묻습니다. 그리고 소비자는 아마 한 번에 최대 10개의 메세지를 받을 겁니다. SQS 대기열에 메세지가 있으면 '여기 너를 기다리는 메세지가 있어'라는 유효한 응답을 받을 겁니다. 여러분의 코드인 소비자는이 메시지들을 처리할 책임이 있습니다. RDS 데이터베이스에 오더를 입력하는 경우를 생각해 보죠. 즉 각 오더들을 RDS 데이터베이스에 삽입하면 물론 이 작업은 코딩으로 이루어지겠죠. 그렇게 삽입하면 이 메시지들이 수신되어 처리됐기 때문에 Amazon RDS 데이터베이스로 삽입됩니다.
그러면 소비자가 이 메시지들을 DeleteMessage API로 대기열에서 삭제합니다. 그러면 다른 소비자들이 이 메세지를 볼 수 없게 되겠죠. 그러면 메시지 처리가 완료됩니다.
이를 확장해 보면 여러 소비자를 동시에 가질 수 있습니다. SQS 대기열은 메세지를 동시에 수신하고 처리할 소비자를 여러 개 가질 수 있습니다. 여기 EC2 인스턴스 세가지가 있고 각 소비자는 poll 함수를 호출하여 다른 메시지 세트를 수신하게 됩니다.
만일 메시지가 소비자에 의해 충분히 빠르게 처리되지 않으면 다른 소비자가 수신하게 됩니다. 그래서 적어도 한번은 전송이 된다고 하는 겁니다.
그리고 이것이 최선의 노력으로 메시지 순서 지정을 하는 이유입니다.
말씀드렸듯 소비자가 메시지를 처리하면 메시지를 삭제해야 합니다. 그렇지 않으면 다른 소비자가 메시지를 보게 되겠죠
SQS 대기열에서 더 많은 메시지가 있어서 처리량을 늘려야 하면 소비자를 추가하고 수평 확장을 수행해서 처리량을 개선할 수 있습니다.
--- SQS with Auto Scaling Group(ASG)
이전에 배운 것들을 기억하신다면 이건 ASG (Auto Scaling groups)와 더불어 SQS를 사용하는 완벽한 사례입니다. 그게 무슨 뜻일까요? 소비자가 ASG의 내부에서 EC2 인스턴스를 실행하고 SQS 대기열에서 메시지를 폴링할 것이라는 겁니다. ASG는 일종의 지표에 따라 확장되어야 하는데 저희가 사용할 수 있는 지표는 대기열의 길이입니다. ApproximateNumberOfMessages라고 합니다. 이는 모든 SQS 대기열에서 쓸 수 있는 CloudWatch 지표입니다. 알람을 설정할 수도 있는데 대기열의 길이가 특정 수준을 넘어가면 CloudWatch Alarm을 설정하세요. 이 알람은 오토 스케일링 그룹의 용량을 X만큼 증가시킵니다. 그러면 더 많은 메시지가 SQS 대기열에 있게 됩니다. 만일 웹사이트에 오더가 폭주했다거나 해서 오토 스케일링 그룹이 더 많은 EC2 인스턴스를 제공하면 메시지들을 더 높은 처리량으로 처리할 수 있습니다.
이는 일반적인 통합으로 시험에 흔히 출제됩니다
--- SQS to decouple between application tiers
SQS는 애플리케이션 계층 간에 분리를 위해 사용됩니다.
가령 비디오를 처리하는 애플리케이션이 있다고 해보겠습니다. 프론트엔드라는 큰 애플리케이션이 있는데, 프론트엔드가 요청을 받고 비디오가 처리되어야 할 때 프론트엔드가 처리를 한 후 S3 버킷에 삽입합니다. 하지만 문제는 처리 시간이 매우 오래 걸릴 수 있고 프론트엔드에서 이를 처리하면 웹사이트의 속도가 느려질 수 있다는 겁니다.
대신 애플리케이션을 분리하여 파일 처리 요청과 실제 파일 처리가 서로 다른 애플리케이션에서 발생할 수 있도록 할 수 있습니다. 파일 처리 요청을 받을 때마다 SQS 대기열로 메시지를 전송하는 거죠. 그러면 처리 요청을 할 때 해당 파일은 SQS 대기열에 있게 됩니다. 자체 오토 스케일링 그룹에 속할 백엔드 처리 애플리케이션이라는 두 번째 처리 계층을 생성할 수 있습니다. 이 애플리케이션이 메시지를 수신하고 비디오를 처리하고 S3 버킷에 이를 삽입할 겁니다.
여기 이 아키텍처에서 볼 수 있듯이 그에 따라 프론트엔드를 확장할 수 있고 그에 따라 백엔드도 확장할 수 있지만 독립적으로 확장할 수 있습니다. SQS 대기열은 처리량이 무제한이고 대기열 측면에서 메시지 수에 제한이 없기 때문에 정말 안전합니다. 이는 강력하고 확장 가능한 유형의 아키텍처입니다.
또한 프론트엔드의 경우 최적의 유형의 EC2 인스턴스 또는 아키텍처를 프론트엔드에 사용할 수 있습니다. 백엔드의 경우 비디오 처리를 수행할 때 그래픽 처리 장치인 GPU가 있는 일부 EC2 인스턴스를 사용할 수 있습니다. 이러한 유형의 인스턴스가 워크로드를 수행하는 데에 최적이기 때문입니다.
이것이 시험에 나올 것으로 예상되는 아키텍처 유형이며 탁월하고 효과적인 SQS 대기열 사용 사례를 살펴봤습니다.
마지막으로 SQS 보안입니다.
HTTPS API를 사용하여 메시지를 보내고 생성함으로써 비행 중 암호화를 하고
KMS 키를 사용하여 미사용 암호화를 얻고
원한다면 클라이언트 측 암호화를 할 수도 있는데 이는 클라이언트가 자체적으로 암호화 및 암호 해독을 수행해야 함을 의미합니다. SQS에서 기본적으로 지원하는 것은 아닙니다.
액세스 제어를 위해 IAM 정책은 SQS API에 대한 액세스를 규제할 수 있고
S3 버킷 정책과 유사한 SQS 액세스 정책도 있습니다.
SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우나
곧 배울 SNS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용하려는 경우에 매우 유용합니다.
181. Amazon SQS - 표준 Queues 개요
--- Amazon SQS What's a queue?
SQS에 대해 살펴보겠습니다 SQS의 핵심은 대기열입니다. SQS는 간단한 대기 서비스이기 때문입니다
SQS 대기열에는 메시지를 포함할 겁니다. 메시지를 담기 위해서는 무언가 SQS 대기열에 메시지를 전송해야 하는데 SQS 대기열에 메시지를 보내는 주체를 생산자라고 합니다. 생산자는 한 개일 수도 그 이상일 수도 있습니다. 여러 생산자가 여러 개의 메시지를 SQS 대기열에 보내게 할 수 있습니다. 메시지는 무엇이든 상관없습니다. 가령 '오더를 처리해라'일 수도 있고 '비디오를 처리해라'일 수도 있죠. 생성한 모든 메시지는 대기열에 들어갑니다.
그런 다음 대기열에서 메시지를 처리하고 수신해야 하는 대상을 소비자라고 합니다. 소비자는 대기열에서 메시지를 폴링하는데 이는 대기열에게 소비자 앞으로 온 메시지가 있는지를 물어보는 겁니다. 만일 대기열에 메시지가 있으면 소비자는 이 메시지를 폴링해서 정보를 얻습니다.
그리고 그 메시지로 처리를 하고 대기열에서 그 메시지를 삭제합니다. 여러 소비자가 SQS 대기열에서 메시지를 소비할 수 있도록 할 수도 있습니다. 대기열 서비스는 생산자와 소비자 사이를 분리하는 버퍼 역할을 합니다. SQS는 복잡한 서비스입니다 이에 대해 자세히 살펴보겠습니다.
--- Amazon SQS - Standard Queue
가장 먼저 제공되는 것은 표준 대기열용 Amazon SQS입니다.
SQS는 AWS에서 제공하는 가장 오래된 서비스입니다. AWS의 첫 번째 서비스 중 하나였습니다. 10년이 넘었으므로 작동 방식이 확실하게 구축되어 있죠.
완전 관리형 서비스이며 애플리케이션을 분리하는 데 사용됩니다. 시험에서 애플리케이션 분리에 대한 문제가 보이면 Amazon SQS을 생각하시면 됩니다.
그러면 SQS의 특별한 점은 무엇일까요?
무제한 처리량을 얻을 수 있다는 겁니다. 즉 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 포함시킬 수 있습니다. 처리량에 제한이 없고 대기열에 있는 메시지 수에도 제한이 없습니다.
각 메시지는 수명이 짧습니다 그게 무슨 뜻일까요? 메시지는 기본값으로 4일 동안 대기열에 남아 있고 대기열에 있을 수 있는 최대 시간은 14일입니다. 즉 대기열에 메시지를 보내자마자 소비자가 읽고 해당 보존 기간 내에 처리한 후 대기열에서 삭제해야 합니다. 그렇지 않으면 소실됩니다.
지연 시간이 짧아서 SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다. 게시 및 수신 시 10밀리초 이내로 매우 빠르게 응답을 받게 됩니다.
그리고 SQS의 메시지는 작아야 합니다. 전송된 메시지당 256KB 미만이어야 합니다.
SQS는 대기열 서비스이므로 높은 처리량, 높은 볼륨 등이 있어서 중복 메시지가 있을 수 있습니다. 예를 들어 메시지가 두 번 전송되는 경우가 있으므로 적어도 한 번의 전송이라고 하는 겁니다. 여러분이 애플리케이션을 작성하실 때 이 점을 염두에 두셔야 합니다.
최선의 오더라는 뜻으로 품절 메시지를 보낼 수도 있습니다. 그리고 그 제한을 처리할 수 있는 SQS의 또 다른 유형의 제품이 있긴 하지만 이 섹션의 뒷부분에서 설명하겠습니다.
--- SQS - Producing Messages
이제 메시지 생산자로 돌아가 보겠습니다. 최대 256KB의 메시지가 생산자에 의해 SQS로 전송됩니다. 어떻게 보낼까요? 생산자는 SDK 소프트웨어 개발 키트를 사용하여 SQS에 메시지를 보낼 겁니다. SQS에 메시지를 보내는 API를 SendMessage라고 합니다. 매우 간단합니다 메시지가 작성되면
소비자가 해당 메시지를 읽고 삭제할 때까지 SQS 대기열에 유지됩니다 메시지가 삭제됐다는 것은 메시지가 처리됐다는 뜻이죠. 저희는 보존에 대해서는 알고 있습니다.
그렇다면 메시지 생성의 어떨 때 사용할까요?
예를 들어 패킷과 같은 오더를 처리한 다음 센터로 배송하려고 합니다. 따라서 원하는 시간에 이 작업을 수행하여
오더 ID,
고객 ID와
원하는 속성 등의 일부 정보가 포함된 메시지를 SQS 대기열로 보냅니다. 주소도 원하는 속성에 들어갈 수 있겠죠. 그러면 애플리케이션 권한에 있는 소비자는 해당 메시지 자체를 처리해야 합니다.
말씀드렸듯 표준 SQS는 무제한 처리량을 자랑하죠. 생산자에 대해 살펴보았습니다. 매우 간단합니다.
--- SQS - Consunming Messages
이제 소비자에 대해 살펴보겠습니다. 소비자는 일부 코드로 작성해야 하는 애플리케이션이고 이러한 애플리케이션은 EC2 인스턴스 즉 AWS 상의 가상 서버에서 실행될 수 있습니다. 원하는 경우 자체 온프레미스 서버에서 실행할 수도 있고 아직 배우지는 않았지만 AWS Lambda의 람다 함수에서 실행할 수도 있습니다. 이 강의에서 배우겠지만 서버가 없는 컴퓨터 유형의 서비스입니다. 이는 람다에서 메세지를 바로 읽을 수도 있다는 것을 의미합니다. 이 내용은 이후에 배울 것이니 걱정하지 마세요.
EC2 인스턴스에 대한 간단한 사용 사례로 돌아가 보면 대기열에는 소비가가 있고 소비자는 SQS 메시지를 폴링합니다. 즉 소비자가 대기열에 자신의 앞으로 온 메시지가 있는지를 묻습니다. 그리고 소비자는 아마 한 번에 최대 10개의 메세지를 받을 겁니다. SQS 대기열에 메세지가 있으면 '여기 너를 기다리는 메세지가 있어'라는 유효한 응답을 받을 겁니다. 여러분의 코드인 소비자는이 메시지들을 처리할 책임이 있습니다. RDS 데이터베이스에 오더를 입력하는 경우를 생각해 보죠. 즉 각 오더들을 RDS 데이터베이스에 삽입하면 물론 이 작업은 코딩으로 이루어지겠죠. 그렇게 삽입하면 이 메시지들이 수신되어 처리됐기 때문에 Amazon RDS 데이터베이스로 삽입됩니다.
그러면 소비자가 이 메시지들을 DeleteMessage API로 대기열에서 삭제합니다. 그러면 다른 소비자들이 이 메세지를 볼 수 없게 되겠죠. 그러면 메시지 처리가 완료됩니다.
--- SQS - Multiple EC2 Instance Consumers
이를 확장해 보면 여러 소비자를 동시에 가질 수 있습니다. SQS 대기열은 메세지를 동시에 수신하고 처리할 소비자를 여러 개 가질 수 있습니다. 여기 EC2 인스턴스 세가지가 있고 각 소비자는 poll 함수를 호출하여 다른 메시지 세트를 수신하게 됩니다.
만일 메시지가 소비자에 의해 충분히 빠르게 처리되지 않으면 다른 소비자가 수신하게 됩니다. 그래서 적어도 한번은 전송이 된다고 하는 겁니다.
그리고 이것이 최선의 노력으로 메시지 순서 지정을 하는 이유입니다.
말씀드렸듯 소비자가 메시지를 처리하면 메시지를 삭제해야 합니다. 그렇지 않으면 다른 소비자가 메시지를 보게 되겠죠
SQS 대기열에서 더 많은 메시지가 있어서 처리량을 늘려야 하면 소비자를 추가하고 수평 확장을 수행해서 처리량을 개선할 수 있습니다.
--- SQS with Auto Scaling Group(ASG)
이전에 배운 것들을 기억하신다면 이건 ASG (Auto Scaling groups)와 더불어 SQS를 사용하는 완벽한 사례입니다. 그게 무슨 뜻일까요? 소비자가 ASG의 내부에서 EC2 인스턴스를 실행하고 SQS 대기열에서 메시지를 폴링할 것이라는 겁니다. ASG는 일종의 지표에 따라 확장되어야 하는데 저희가 사용할 수 있는 지표는 대기열의 길이입니다. ApproximateNumberOfMessages라고 합니다. 이는 모든 SQS 대기열에서 쓸 수 있는 CloudWatch 지표입니다. 알람을 설정할 수도 있는데 대기열의 길이가 특정 수준을 넘어가면 CloudWatch Alarm을 설정하세요. 이 알람은 오토 스케일링 그룹의 용량을 X만큼 증가시킵니다. 그러면 더 많은 메시지가 SQS 대기열에 있게 됩니다. 만일 웹사이트에 오더가 폭주했다거나 해서 오토 스케일링 그룹이 더 많은 EC2 인스턴스를 제공하면 메시지들을 더 높은 처리량으로 처리할 수 있습니다.
이는 일반적인 통합으로 시험에 흔히 출제됩니다
--- SQS to decouple between application tiers
SQS는 애플리케이션 계층 간에 분리를 위해 사용됩니다.
가령 비디오를 처리하는 애플리케이션이 있다고 해보겠습니다. 프론트엔드라는 큰 애플리케이션이 있는데, 프론트엔드가 요청을 받고 비디오가 처리되어야 할 때 프론트엔드가 처리를 한 후 S3 버킷에 삽입합니다. 하지만 문제는 처리 시간이 매우 오래 걸릴 수 있고 프론트엔드에서 이를 처리하면 웹사이트의 속도가 느려질 수 있다는 겁니다.
대신 애플리케이션을 분리하여 파일 처리 요청과 실제 파일 처리가 서로 다른 애플리케이션에서 발생할 수 있도록 할 수 있습니다. 파일 처리 요청을 받을 때마다 SQS 대기열로 메시지를 전송하는 거죠. 그러면 처리 요청을 할 때 해당 파일은 SQS 대기열에 있게 됩니다. 자체 오토 스케일링 그룹에 속할 백엔드 처리 애플리케이션이라는 두 번째 처리 계층을 생성할 수 있습니다. 이 애플리케이션이 메시지를 수신하고 비디오를 처리하고 S3 버킷에 이를 삽입할 겁니다.
여기 이 아키텍처에서 볼 수 있듯이 그에 따라 프론트엔드를 확장할 수 있고 그에 따라 백엔드도 확장할 수 있지만 독립적으로 확장할 수 있습니다. SQS 대기열은 처리량이 무제한이고 대기열 측면에서 메시지 수에 제한이 없기 때문에 정말 안전합니다. 이는 강력하고 확장 가능한 유형의 아키텍처입니다.
또한 프론트엔드의 경우 최적의 유형의 EC2 인스턴스 또는 아키텍처를 프론트엔드에 사용할 수 있습니다. 백엔드의 경우 비디오 처리를 수행할 때 그래픽 처리 장치인 GPU가 있는 일부 EC2 인스턴스를 사용할 수 있습니다. 이러한 유형의 인스턴스가 워크로드를 수행하는 데에 최적이기 때문입니다.
이것이 시험에 나올 것으로 예상되는 아키텍처 유형이며 탁월하고 효과적인 SQS 대기열 사용 사례를 살펴봤습니다.
--- Amazon SQS - Security
마지막으로 SQS 보안입니다.
HTTPS API를 사용하여 메시지를 보내고 생성함으로써 비행 중 암호화를 하고
KMS 키를 사용하여 미사용 암호화를 얻고
원한다면 클라이언트 측 암호화를 할 수도 있는데 이는 클라이언트가 자체적으로 암호화 및 암호 해독을 수행해야 함을 의미합니다. SQS에서 기본적으로 지원하는 것은 아닙니다.
액세스 제어를 위해 IAM 정책은 SQS API에 대한 액세스를 규제할 수 있고
S3 버킷 정책과 유사한 SQS 액세스 정책도 있습니다.
SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우나
곧 배울 SNS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용하려는 경우에 매우 유용합니다.
182. SQS - 표준 Queues 실습
183. SQS Queues 액세스 정책(+ 실습)
--- SQS Queue Access Policy
이제 SQS 대기열 액세스 정책을 살펴볼 텐데요. SQS 대기열 액세스 정책에 대한 좋은 사용 사례가 두 개 있습니다. 리소스 정책이라는 점에서 S3 버킷 정책과 유사합니다. 즉 JSON IAM 정책을 SQS 대기열에 직접 추가할 겁니다.
첫 번째 사용 사례는 교차 계정 액세스를 허용하는 겁니다. 어떤 계정에 대기열이 있고 다른 계정이 그 대기열에 액세스 해야 한다고 해봅시다. EC2 인스턴스가 하나 있다고 해봅시다. 그 EC2 인스턴스가 계정 간 메시지를 가져올 수 있으려면 다음과 같이 생긴 대기열 액세스 정책을 생성하고 이를 첫 번째 계정의 SQS 대기열에 첨부해야 합니다. 이 대기열 액세스 정책은 AWS의 보안 주체가 111122223333이 될 수 있게 허용하는데 이는 오른쪽에 있는 이 그림이 나타내는 계정이죠 sqs: ReceiveMessage의 이 리소스에서 그렇게 허용합니다. 따라서 이 대기열 액세스 정책은 EC2 인스턴스가 다른 계정의 SQS 대기열에서 가져올 수 있게 합니다.
SQS 대기열 액세스 정책의 또 다른 사용 사례는 S3 버킷이 있으면 이것이 이벤트 알림을 SQS 대기열에 게시할 겁니다. 예를 들어 S3 버킷에 객체를 업로드하면 SQS 대기열에 자동으로 메시지를 보냅니다. 보다시피 SQS 대기열은 S3 버킷에 메시지를 작성할 수 있는 권한을 부여해야 합니다. 따라서 이렇게 생긴 SQS 대기열 액세스 정책을 생성해야 합니다.
조금 더 자세하게 살펴보면 Action은 sqs:SendMessage고 Principal은 모든(*) 계정의 AWS입니다. Condition은 버킷의 ARN 소스가 'bucket1'이라는 이름의 S3 버킷이어야 됩니다. 소스 계정은 S3 버킷의 계정 소유자여야 합니다. 그러면 S3 버킷은 SQS 대기열에 작성할 수 있게 됩니다. 교차 계정 액세스 혹은 S3 이벤트 알림 게시를 위한 SQS 대기열을 쓰라는 문제가 시험에 나올 수도 있어요. 그러니깐 지금 함께 본 거고 기억하세요.
--- 실습
이제 대기열을 만들고 SQS 대기열 액세스 정책을 설정해 보겠습니다
이름을 EventFromS3라고 하겠습니다
이 SQS 대기열에 들어갈 S3 이벤트 알림을
설정할 것이기 때문입니다
나머지는 모두 기본값으로 유지하겠습니다
보시다시피 SQS 액세스 정책이 여기에 있으므로
SQS 대기열에 데이터를 보낼 수 있는
서비스 종류를 정의할 수 있습니다
종류를 Basic으로 선택하면 Only the queue owner를
선택해서 대기열 소유자만 대기열에 메시지를 보낼 수 있도록 하거나
아래 옵션인 특정 AWS 계정, IAM 사용자와 역할을
선택해서 지정할 수도 있습니다
그럼 이 중 하나가 대기열을 통해 메시지를 보낼 수 있는
교차 계정 접근 권한을 갖게 될 겁니다
누가 대기열로부터 메시지를 수신할 수 있는지에도 동일한 조건이 있습니다
이 부분은 Amazon S3에 도움이 되지 않을 겁니다 Advanced로 가서
자체 SQS 대기열 액세스 정책을 작성할 수 있습니다
지금은 그냥 Basic을 선택하겠습니다
처음에는 잘 작동하지 않는 것을 보여드리고 이를 어떻게 수정해야
이후에 작동할 수 있는지를 보여드리겠습니다
바로 여기에 대기열을 생성하고
Amazon S3로 이동하겠습니다
그리고 S3 버킷을 생성하고 S3 버킷에서
SQS 대기열로 데이터를 보낼 이벤트 알림을 설정해 줄 겁니다
버킷을 생성해 보겠습니다 demo-sqs-queue-access-policy로 이름 지어주고
Create bucket을 클릭합니다
잘 생성되었죠 그 다음 Properties로 가서
스크롤을 내려 Event notifications를 찾고
이벤트 알림을 생성하겠습니다 NewObjects라고 부르겠습니다
모든 Prefix나 Suffix 이벤트 유형에 대해
All object create events를 선택합니다
스크롤을 더 내리면 Destination이 나오는데 SQS queue를 택합니다
SQS 대기열에서 선택해야 하므로
S3에서 이벤트를 찾은 후 저장해 주겠습니다
보시다시피 '이 대상 구성을 확인할 수 없습니다'와 같은
오류 메시지가 뜹니다
이제 저희가 할 일은 Access policy로 들어가서
S3 버킷이 SQS 대기열에 작성할 수 있도록
수정하는 겁니다
이렇게 하면 문서로 직접 들어가서
이 정책이 우리에게 맞는지 확인할 수 있습니다
간단한 Google 검색을 하겠습니다
s3 event into SQS access policy를 검색하면
이를 통해 필요한 항목에 액세스할 수 있습니다
이벤트 알림이 보이고
Amazon SQS로 들어가 Granting permissions를
클릭하면 SQS와 SNS를 구성하는 항목의
여기 SQS 대기열에 대해 설정해야 할 정책 문서가 있습니다
이걸 복사하고 Edit으로 가서 붙여 넣을 거예요
대기열 ARN을 갖도록 변경할 건데
조금 복잡한 편집을 하겠습니다
리소스 대기열 ARN은 이 부분에서 복사해서
여기에 붙여 넣습니다
조건은 ArnLike 소스 버킷이
우리의 소스 버킷의 이름과 같아야 한다는 조건을 걸어야 합니다
여기에 있는 소스 버킷의 이름을 복사해서
이 정책에 붙여 넣고
소스 계정 소유자는 우리가 현재 가지고 있는 그 계정입니다
바로 여기로 가서 여기 있는 제 계정 아이디를 찾아서
복사하고 붙여 넣겠습니다
나머지 하나는 삭제해야 합니다
이 정책을 통해 S3 버킷이 SQS 대기열로
메시지를 보낼 수 있습니다
저장을 할 건데 JSON에 문법 오류가 있네요
여기에 쉼표가 빠졌습니다 이제 저장하면 끝입니다
이제 이 새로운 정책으로
이벤트 알림을 저장할 수 있는지 보겠습니다
할 수 있네요 작업이 성공적으로 완료되었습니다
실제로 Amazon SQS에 들어가면
여러분은 메시지를 주고받을 거고
수신 가능한 한 개의 메시지를 폴링해서 읽어보면 Amazon S3에 의해
메시지가 SQS 대기열에 보내졌음을 확인할 수 있습니다
여기까지가 Amazon S3에
메시지를 업로드하거나 파일을 업로드하고
SQS를 확인하는 영역이었습니다
여기서 보여드리려던 건
액세스 정책을 수정하여 S3 버킷에서
SQS 대기열로의 액세스를 제공할 수 있다는 거죠
184. SQS - 메시지 가시성 시간 초과(+ 실습)
--- SQS - Message Visibility Timeout
이제 메시지 가시성 시간 초과 (Message Visibility Timeout)이라는 중요한 개념에 대해 살펴보겠습니다.
소비자가 메시지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 됩니다.
예시를 같이 살펴보겠습니다 왼쪽에서 오른쪽으로 가는 시간이 있고 컨슈머가 ReceiveMessage 요청을 하고 있습니다. 그러면 대기열에서 메시지가 반환됩니다. 이제 가시성 시간 초과가 시작됩니다.
기본값으로 메시지 가시성 시간 초과는 30초입니다.
그 말은 이 30초 동안 메시지가 처리되어야 한다는 거죠 그렇죠? 그러면 동일한 혹은 다른 소비자가 메시지 요청 API를 호출하면 메시지가 반환되지 않습니다. 시간 초과 기간 내에 또 다른 요청이 들어와도 메시지가 반환되지 않죠. 즉 가시성 시간 초과 기간 내에서는 그 메시지는 다른 소비자들에게 보이지 않습니다.
하지만 가시성 시간 초과가 경과되고 메시지가 삭제되지 않았다면 메시지는 대기열에 다시 넣습니다. 그러면 다른 소비자 또는 동일한 소비자가 또 ReceiveMessage API 호출을 하면 이전의 그 메시지를 또 받게 됩니다. 이것을 이해하는 것이 정말 중요합니다 보시다시피 메시지를 받는 동안 가시성 시간 초과 기간 동안 보이지 않게 됩니다.
--- SQS - Message Visibility Timeout
이 도표를 보면서 가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 메시지가 두 번 처리될 수도 있다는 것을 알 수 있습니다. 두 명의 다른 소비자가 수신하거나 동일한 소비자가 두 번 수신하기 때문입니다.
만일 소비자가 메시지를 적극적으로 처리하고 있지만 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있는데 메시지를 처리하지 않아 가시성 시간 초과 기간을 벗어날 때를 위해 ChangeMessageVisibility라는 API가 있습니다. 즉 소비자가 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있고 해당 메시지를 두 번 처리하고 싶지 않다면 소비자는 ChangeMessageVisibility API를 호출하여 SQS에 알려야 합니다. 지금은 그 메시지를 보이지 않게 하도록 말이죠. 이 메시지를 처리하는 데 시간이 조금 더 필요하니까요.
이 메시지 가시성 시간 초과를 어떻게 설정할까요? 기본값으로 매우 높은 값 예를 들어 시간으로 설정하면 소비자가 충돌했을 때 이 메시지가 다시 나타날 때까지 즉 SQS 대기열에 보이기까지 몇 시간이 걸립니다. 그러면 오래 걸리겠죠.
몇 초와 같이 매우 낮은 값으로 설정하면 소비자가 어떤 이유로든 해당 메시지를 처리할 시간이 충분하지 않으면 다른 소비자가 메시지를 여러 번 읽을 것이며 중복 처리될 수 있습니다. 그래서 가시성 시간 초과는 애플리케이션에 합당한 것으로 설정되어야 하고 소비자는 시간이 조금 더 필요하다는 것을 알면 ChangeMessageVisibility API를 호출하도록 프로그래밍해야 합니다. 그러면 더 많은 시간을 확보하고 해당 가시성 시간 초과 기간을 늘릴 수 있죠. 그러나 이 개념을 이해하는 것은 이에 대한 시나리오가 있기 때문에 시험에서 매우 중요합니다.
이제 콘솔로 이동하여 실제로 어떻게 작동하는지 살펴보겠습니다
어떻게 작동하는지 보여드리기 위해 메시지 보내기와 받기를 위해
창 두 개를 열겠습니다
첫 번째 창에서 hello world를
치고 이는 대기열로 보내질 겁니다
그리고 기억하시겠지만 대기열의 기본 제한 시간은 30초입니다
그럼 소비자가 두 명일 경우 어떤 일이 생길까요?
첫 번째 창과 두 번째 창의 소비자가 있고
첫 번째 창에 있는 메시지를 읽어 보도록 하겠습니다
Poll for messages를 클릭하면 메시지가 여기에 뜹니다
수신이 된 거죠
그리고 두 번째 소비자로 가서 Poll for messages를 누르면
보시다시피 메시지는 여기에 뜨지 않습니다
그 이유는 여전히 그 메시지가 가시성 시간 초과 기간 내에
있기 때문입니다
그래서 이 30초 동안
이 메시지는 이 소비자가 처리하려고 하고 있으니
여기 있는 이 소비자는 볼 수 없습니다
이제 폴링을 멈춘다고 해봅시다
그러니까 메시지를 삭제하지 않고
언젠가 이 메시지는 시간이 초과될 겁니다
그러면 어떤 일이 일어나냐면
이 두 번째 창 즉 두 번째 소비자에게
메시지가 수신됩니다 다시 메시지가 대기열에 올라왔기 때문이죠
이제 우리가 제대로 메시지까지 삭제하고
메시지를 완전히 처리했다고 해보겠습니다
하지만 메시지는 이미 두 번 수신되었죠
수신이 2로 되어있습니다
가시성 기간이 어떻게 작동하는지 이해하는 것이 중요합니다
좋은 예시를 살펴봤습니다
권장되지는 않습니다만 만약 이 설정을 바꾸고 싶다면
Edit으로 가서
Visibility timeout에서
0초에서 12시간까지 설정할 수 있습니다
저는 30초가 적당하다고 생각하지만
만약 소비자가 메시지를 처리하는 데 더 많은 시간이 필요하다면
ChangeMessageVisibility API를 호출하여
메시지의 가시성을 편집하여 값을 늘립니다
그러면 다른 소비자에게 메시지를 보이지 않고 첫 번째 소비자가
메시지를 처리할 충분한 시간을 가질 수 있습니다
여기까지입니다, 재밌으셨길 바라며 다음 강의에서 뵙겠습니다
185. SQS - 배달 못한 편지 Queues(+ 실습)
--- Amazon SQS - Dead Letter Queue
SQS의 데드 레터 대기열(DLQ)에 대해 알아보겠습니다
소비자가 가시성 시간 초과 내에 메시지를 처리하지 못하는 시나리오를 살펴보도록 하죠. 그러면 메시지가 자동으로 대기열로 돌아갑니다. 소비자는 메시지를 읽죠 어쩌면 오류가 있을 수도 있고 시간이 충분하지 않을 수도 있죠 그러면 메시지는 대기열로 다시 돌아가죠.
이런 일이 자주 발생한다면 문제가 될 수 있습니다. 메시지를 다시 읽게 되죠 메시지에 문제가 있을 수 있죠. 소비자가 메시지를 이해하지 못했거나 처리하지 못할 수도 있습니다. 그러면 메시지가 다시 대기열에 들어가고 이 과정이 반복됩니다. SQS에서 메시지를 다시 읽고 다시 메시지가 대기열로 가는 과정이죠.
여기서 몇 번이나 반복할지 임곗값을 설정할 수 있습니다. 이 실패 루프는 큰 문제가 될 수 있지만 최대 수신 임곗값을 설정할 수 있다는 장점이 있죠. 그리고 해당 임곗값을 초과하면 SQS에 메시지에 문제가 있다고 DLQ에 전달할 수 있습니다. 많은 처리 시도가 있었지만 성공하지 못했기 때문에 메시지를 데드 레터 대기열로 보내는 거죠. 그러면 데드 레터 대기열에는 나중에 처리할 수 있게 메시지를 포함하고 그 메시지는 첫 번째 대기열에서 제거되고 두 번째 대기열로 보내집니다.
왜 데드 레터 대기열이 있는 걸까요? 디버깅 때문입니다. 가령 일부 메시지를 처리하지 못하여 DLQ, 즉 데드 레터 대기열로 보낼 수 없으면 애플리케이션을 통해 이 메시지를 분석하거나 다른 이가 이 메시지를 분석하여 애플리케이션이 멈춘 이유나 메시지를 제대로 처리하지 못한 이유를 파악하는데 유용합니다.
이 메시지는 데드 레터 대기열에 있고 SQS 대기열이기 때문에 메시지 보관 기간에 제한이 있어서 일정 시점에서 만료됩니다.
- 따라서 데드 레터 대기열에 14일 정도의 높은 보존 기간을 설정하는 것이 좋습니다. 메시지를 읽고 처리하고 실패로 인해발생한 일을 파악할 시간이 필요하니까요.
--- SQS DLQ - Redrive to Source
데드 레터 대기열 관리를 위한 다음 기능은 소스로 리드라이브(Redrive)하는 기능입니다.
데드 레터 대기열 메시지를 사용해 무엇이 잘못되었는지 이해하는 데 도움이 되는 기능이죠.
메시지가 표시되면 소스 대기열에서 메시지가 처리되지 않은 것을 알게 됩니다. 따라서 데드 레터 대기열에 메시지가 있다는 의미죠. 그럼 메시지를 수동으로 검사하고 디버깅합니다.
메시지가 처리되지 않은 이유를 파악한 후 소비자 코드를 수정하고 메시지가 올바르게 나오는 경우 데드 레터 대기열에서 소스 SQS 대기열로 해당 메시지를 리드라이브합니다. 이 기능이 멋진 이유는 소비자의 경우 메시지가 다른 대기열로 들어갔었고 메시지 처리가 발생했다는 사실조차 모른 채 해당 메시지를 다시 처리할 수 있기 때문입니다.
이제 콘솔로 이동하여 데드 레터 대기열 기능을 보여드리겠습니다
데드 레터 대기열을 실습해 보겠습니다
먼저 데드 레터 대기열을 만들어야겠죠
Standard를 선택하고
DemoQueueDLQ라고 이름을 붙여 주겠습니다
이게 바로 데드 레터 대기열입니다
메시지는 오랫동안 유지되어야 하니깐
메시지를 분석할 충분한 시간을 스스로 주고
이유 없이 잃어버리지 않도록
메시지 보존 기간을 4일에서 14일로 바꿔주겠습니다
14일은 충분히 긴 메시지 보존 기간입니다
스크롤을 내려봅니다
다 좋아보이네요 이제 이 대기열을 생성하겠습니다
DLQ가 생성됐고
이제 첫 번째 대기열을 구성하겠습니다
두 개의 대기열을 보기 위해 새로고침 합시다
이 대기열을 데드 레터 대기열로 지정하기 위해
첫 대기열을 다시 구성해야 합니다
이 대기열의 설정을 편집하겠습니다
스크롤을 내려서
먼저 가시성 시간 초과를 5초 정도로 설정해서
이 데모가 빠르게 진행되게 할게요
그리고 스크롤을 더 내려서
가장 아래에 데드 레터 대기열 구성이 있습니다
활성화시키고 Choose a dead-letter queue를 고릅니다
DemoQueueDLQ를 여기서 선택해 줍니다
이제 최대 몇 번의 메시지가 있으면 DLQ로 해당 메시지를
보낼지 설정할 수 있습니다 1에서 1,000사이로요
만약 메시지를 10번까지 재처리하고 싶다면
10을 넣으면 됩니다
하지만 지금은 예시를 보여드리는 거니 빠르게 진행하기 위해
최대 세 번 받도록 하겠습니다
여기서 세 번의 뜻은 메시지를 세 번 받고도
여전히 SQS 대기열에 올려간다면
DLQ로 보내 달라는 겁니다 나중에 문제 해결을 할 수 있도록요
이제 저장하고 만든 예시를 살펴보겠습니다
여기 왼쪽 창에 일반적인 대기열이 띄워져 있고
DLQ는 오른쪽에 띄워져 있는 창입니다
이제 DLQ로 이동해서
소비자의 메시지 폴링을 시작하겠습니다
지금은 보시다시피 수신 가능한 메시지가 없습니다
일반 대기열로 가서
Send and receive messages를 클릭합니다
그리고 여기에 hello world, poison pill이라고 쓸게요
'독약'이라고 한 이유는 이게 애플리케이션을 중단시키고
제대로 처리되지 못하게 할 예정이기 때문이죠
메시지를 보내볼게요
메시지를 보내면 수신될 준비가 되어있습니다
메시지 폴링을 시작하면
메시지가 바로 여기에 뜨고
한 번 수신되었습니다 이제는 대기열에 다시 돌아갔기 때문에
여기에 2가 뜹니다
곧 여기에 3이 뜨는데
아직도 처리가 안됐고 삭제되지도 않았습니다
곧 메시지가 네 번째로
수신되지 못한다는 것을 보게 될 겁니다
옆에 탭으로 이동하여 메시지를 다시 폴링하면
메시지가 DLQ로 전송된 게 보이네요
즉 해당 메시지를 처리할 수가 없었고 계속 대기열로 돌아가서
자동으로 최대 수신 횟수 임곗값을 초과했습니다
그러면 DLQ로 그 메시지가 보내지고
DLQ에서 이 메시지를 보고
이 메시지가 애플리케이션을
충돌시키는 이유를 이해해 볼 수 있습니다
여기까지입니다, 유용하셨길 바라며 DLQ의 좋은 예시였기를 바랍니다
다음 강의에서 뵙겠습니다.
186. SQS - Queues 지연(+ 실습)
--- Amazon SQS - Delay Queue
대기열 지연(Delay Queue)에 대해 얘기해 봅시다.
대기열 지연은 소비자들이 즉각적으로 보지 못하도록 메시지를 지연시키는 것입니다. 15분까지 지연시킬 수 있죠.
지연 파라미터의 기본값은 0초입니다. 원래는 SQS 대기열로 메시지를 보낸 직후부터 그 메시지를 읽을 수 있지만
모든 메시지를 몇 초만큼 지연시킬 것인지 대기열 레벨에서 기본값을 지정하거나
또는 매번 메시지를 보낼 때마다 DelaySeconds 파라미터를 사용하여 메시지별 지연 시간을 지정할 수도 있습니다.
즉 대기열이 있고, 생산자가 그 대기열로 메시지를 보냈는데 그 대기열이 얼마나 메시지를 지연시킬지에 대한 기본값을 가지고 있는 겁니다. 여기서는 30초라고 합시다. 따라서 30초 후에 소비자가 메시지를 불러오면 메시지를 성공적으로 수신하게 되죠.
이제 콘솔로 가서 실제로 어떻게 작동하는지 봅시다.
SQS로 돌아와서 대기열을 만들고
이름을 DelayQueue라고 정하겠습니다
그리고 여기에 Delivery delay라는 새로운 설정이 있습니다
기본값은 0초지만
최대 15분까지 설정할 수 있죠
저는 그냥 10초로 두겠습니다
그러면 메시지는 10초를 기다린 후에
소비자가 읽을 수 있도록 전달됩니다
그 다음은 일반적으로 진행됩니다
일단 Create queue를 클릭하죠
이제 DelayQueue가 생성됐습니다 다음으로 메시지를 발신하고 수신해 보죠
아무 메시지나 입력하겠습니다
보시는 것처럼 Delivery delay의
기본값은 콘솔에서 이미 10초로 설정됐지만
여기에서 수정할 수 있습니다
예를 들면, 30초로 정하거나 0초로 정하거나
또는 더 길게 정할 수도 있지만 여기서는 기본값인 10초로 두겠습니다
이제 메시지를 불러오죠
보시는 것처럼 수신된 메시지가 없습니다
이제 메시지를 발신합니다
그리고 10초를 기다려야 하죠 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
지금쯤이면 소비자에게 메시지가 도착했을 텐데요
여기 도착했습니다 10초 걸렸죠
보시는 것처럼 메시지 발신 시점과
실제 도착 시점 사이에 지연이 존재합니다
상황에 따라
이와 같은 기능이 필요할 수 있습니다
AWS 인증을 받은 사람으로서 이러한 기능이 있다는 것 정도는 알아야죠
아주 짧을 시연을 보여드렸습니다 도움이 됐기를 바랍니다
다음 강의에서 만나요
187. SQS - 롱 폴링
--- Amazon SQS - Long Polling
이번에는 Amazon SQS 롱 폴링(Long Polling)을 다뤄보겠습니다
예를 들어 소비자가 대기열에 메시지를 요청하는데 대기열에 아무것도 없다면 메시지 도착을 기다리면 됩니다. 이것을 롱 폴링이라고 합니다.
이렇게 하는 이유는 두 가지인데요
1. 첫 번째는 지연 시간을 줄이기 위해서고
2. 두 번째 이유는 SQS로 보내는 API 호출 숫자를 줄이기 위해서입니다.
그럼 작동 방식을 살펴봅시다 비어 있는 SQS 대기열이 있습니다. 그러면 소비자가 대기열에 폴링합니다. 최대 20초 동안 폴링 할 겁니다. 이렇게 하는 이유는요 만약 대기열이 비어 있다면 그냥 기다리겠다는 거예요 대기열이 비었으면 좀 기다려도 좋단 거죠. 그러다 메시지가 발생할 때 즉 메시지가 대기열에 막 도착할 때 소비자가 여전히 롱 폴링 중이라면 자동적으로 그 메시지가 소비자에게 전송됩니다. 이때의 지연 시간은 짧아서 자동으로 최대한 빨리 받게 됩니다.
롱 폴링은 SQS로의 API 호출 숫자를 줄입니다. 그러면서 애플리케이션의 효율성과 대기 시간을 증가시키죠.
그래서 1초부터 20초 사이로 구성이 가능하고요. 물론 더 길어질수록 더 좋겠죠.
그리고 제 생각엔 분명히 숏 폴링보다는 롱 폴링을 선호할 겁니다. 꼭 한번 구성해보세요.
롱 폴링을 구성하는 방법엔 두 가지가 있습니다. 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링을 활성화하는 방법도 있고요. WaitTimeSeconds를 지정함으로 소비자가 스스로 롱 폴링을 하도록 선택할 수도 있습니다. 그러니 만약 시험에서 SQS 대기열에 대한 API 호출 수를 최적화하고 지연 시간을 줄이는 법을 묻는다면 롱 폴링을 떠올리세요. 이번 강의는 여기까지입니다 그럼 다음 강의에서 뵙겠습니다.
188. SQS - 요청 응답
--- SQS - Request-Response Systems
이 주제는 시험에 나올 수 있는 내용이라 시간을 좀 들여서 설명하고 싶은데요. 만약 많이는 이해하지 못한다고 해도 답은 이해하려고 노력해 봅시다. 이게 그렇게 복잡한 건 아닌데 지금 제 설명은 좀 복잡해 보일거예요. 그래도 답을 제대로 이해하실 수 있도록 작동 원리를 꼭 설명해 드리고 싶어요. 그럼 SQS를 통해 요청-응답 시스템을 시행하는 방법을 보여드리겠습니다.
먼저 요청자가 있습니다. 여러 생산자가 될 수도 있고요 이들이 모든 요청을 요청 대기열로 보냅니다. 이렇게 해서 요청자와 응답을 분리하는 것입니다. 그리고 중간에서 SQS를 이용하는 방식으로 요청 및 응답의 양을 스케일링할 수 있습니다. 이제 응답자가 있는 곳은 오토 스케일링 그룹입니다. SQS 대기열에서 실행 중인 애플리케이션이 됩니다. 그리고 생산자에 응답하는데 또 다른 대기열에 응답을 넣는 방법을 사용합니다. 여기서 핵심은 생산자가 메시지를 SQS 대기열에 보낼 때 상호 관련 ID를 함께 보내는데 그 ID는 요청 번호와 요청의 내용 및 응답할 대기열을 나타냅니다. 그러니까 '이 메시지를 받으면 응답 대기열 1로 응답하세요'라는 뜻인 거죠.
그럼 이제 응답자는 요청 대기열을 읽고 해당 요청을 처리해서 응답을 생성할 겁니다. 응답을 생성하려는데 대기열이 존재하지 않으면 응답 대기열 1이라는 대기열을 만듭니다. 그리고 그 대기열로 응답을 보내면서 이전의 상호 관련 ID를 함께 전송합니다. 이렇게 하면 생산자는 각각 어떤 응답이 어떤 요청에 대응하는지 알 수 있고 응답 페이로드도 이해할 수 있게 됩니다. 그래서 생산자가 응답 대기열 1을 읽고 해당 응답을 수신하는 거죠. 이 아키텍처에서 중요한 것은 중간에 확장 가능한 백엔드가 있어서 수많은 다양한 요청과 수많은 다양한 응답을 전송할 수 있게 해주면서도 대상 시스템에 과부하를 주지 않는다는 점입니다.
이번에는 여기에 두 번째 생산자가 생겼습니다. 이전과 여전히 같은 요청 대기열을 통해서 요청을 생산하겠지만 응답은 달라질 것입니다. 즉 응답 대기열 2는 다를 것이고 거기에 따라 응답자는 응답 대기열 2로 응답을 하겠죠. 그럼 생산자 2는 필요한 응답을 얻기 위해서 해당 대기열을 읽을 겁니다. 이러한 아키텍처를 요청-응답 시스템이라고 합니다. SQS를 사용해서 시행할 수 있는 유형이고요.
바로 이런 패턴을 시행하는 게 시험 문제가 될 수 있습니다. 시험에서 요청 응답 시스템을 어떻게 시행하는지 물으면 SQS Temporary Queue Client 즉 SQS 임시 대기열 클라이언트가 답이 됩니다. 이는 AWS에서 직접 생성한 사용 가능 클라이언트이고 또 Java 클라이언트입니다. 이 클라이언트를 사용함으로써 이 패턴의 시행 세부 사항을 걱정할 필요가 없게 됩니다. 이 클라이언트 사용으로는 이 패턴의 결과만 얻는 겁니다, 아셨죠?
또한 실제 SQS 대기열을 만들고 없애는 대신 가상의 대기열을 활용하니까 비용 면에서도 더 효율적이죠. 시행 세부 사항에 대해 걱정하실 필요는 없습니다. 다시 말하지만 신경 써야 하는 건 이 패턴 구현에 SQS 임시 대기열 클라이언트가 필요하다는 것뿐이에요.
189. SQS - FIFO Queue(+ 실습)
--- Amazon SQS - FIFO Queue
SQS에서 사용 가능한 다른 종류의 대기열 즉 Amazon SQS FIFO 대기열에 대해 얘기해 봅시다.
FIFO는 선입선출이라는 뜻입니다. 이는 대기열에 첫 번째로 도착한 메시지가 대기열을 떠날 때도 첫 번째가 되도록 대기열 내의 순서가 정렬된다는 의미죠.
즉 표준 대기열 보다 더 확실히 순서가 보장되는 것입니다. 제작자가 SQS 대기열로 메시지를 보내는 예시를 살펴봅시다. 첫 번째, 두 번째, 세 번째 그리고 네 번째 메시지를 보내는 거죠. 그리고 SQS FIFO 대기열은 소비자가 SQS FIFO 대기열로부터 메시지를 불러올 때 정확히 동일한 순서로 메시지를 받게 해 줍니다. 이처럼 순서에 대한 강제적인 보장이 존재하기 때문에 이 SQS 대기열은 제한된 처리량을 가집니다.
묶음이 아닐 경우에는 초당 300개의 메시지를 처리하고 메시지를 묶음으로 보낼 경우의 처리량은 초당 3000개가 됩니다. 그러나 FIFO 대기열 덕분에 강제적인 보장을 얻을 수 있죠.
또한 중복을 제거하도록 해주는 SQS FIFO 대기열의 기능으로 인해 정확히 한번만 보낼 수 있게 해 줍니다.
또한 우리는 메시지가 소비자에 의해 순서대로 처리된다는 것을 알고 있죠. 따라서 분리가 발생하거나 메시지의 순서를 유지할 필요가 있을 때 FIFO 대기열을 확인해야 합니다. 또한 SQS로 너무 많은 메시지를 보내지 않도록 처리량에 대한 제약이 있다는 것을 잊지 마세요.
이제 우리의 첫 FIFO 대기열을 생성합시다. FIFO 대기열을 만들겠습니다
보시는 것처럼 선입선출 방식이기 때문에
메시지의 순서가 유지됩니다
이름을 DemoQueue.fifo로 정하겠습니다
이름이 .fifo로 끝나야 하죠
그렇지 않으면 이와 같은 대기열을 만들 수 없습니다
.fifo로 끝나야 합니다
이제 구성을 보시면 이전과 매우 비슷하지만
Content-based deduplication라는 이름의 설정이 추가되었습니다
이는 5분 이내의 짧은 시간 동안 동일한 메시지가 두 번 발송됐을 경우
중복을 방지하기 위한 것입니다
Access policy는 그대로 둡니다
Encryption 및 기타 부분도 그대로 두죠
이제 이 대기열을 만들 겁니다 Send and receive messages로 가서
메시지 본문을 볼 수 있죠 Hello World 1이라고 적겠습니다
아제 Message group ID를 demo로 정하겠습니다
예시 전반에 걸쳐 같은 메시지 그룹 ID를 사용할 겁니다
이제 demo를 발송합니다 Message deduplication ID를 잊었군요
첫 번째 메시지이므로 ID를 1로 정할게요
메시지를 보냅니다 Hello World 2를 적고
같은 메시지 그룹 ID에 중복방지 ID는 2입니다
그리고 세 번째 메시지는
여기에 3을 적고
마지막 네 번째 메시지에는 4를 적습니다
이제 메시지들이 전송됐고 수신될 준비가 됐습니다
네 개의 메시지를 수신 가능한 상태입니다
이제 네 개의 메시지를 불러오면 모든 메시지를 볼 수 있습니다
이제 이 메시지를 보면 순서를 잘못 봤군요
첫 메시지에 해당하는 가장 아래쪽 메시지를 보면 Hello World 1이라고 나오죠
두 번째 메시지를 보면 Hello World 2라고 나옵니다
세 번째 메시지는 Hello World 3이고
네 번째 메시지는 Hello World 4죠
FIFO 대기열은 이와 같은 순서를 보장합니다
가서 메시지들을 지우면 이제 끝났습니다
도움이 됐기를 바랍니다
다음 강의에서 만나요
190. SQS + 오토 스케일링 그룹
--- SQS with Auto Scaling Group(ASG)
전에 SQS를 오토 스케일링 그룹과 통합할 수 있다고 말씀드렸었죠. 이제 그 작동 원리의 아키텍처를 이론적으로 살펴보겠습니다.
오토 스케일링 그룹이 있고 많은 EC2 인스턴스가 보입니다. 그리고 이 인스턴스는 SQS 대기열에서 메시지를 폴링하고 있습니다. 이제부터 EC2 인스턴스의 숫자를 대기열의 메시지 양에 따라 스케일링해 보겠습니다. 대기열에 더 많은 부하가 걸려있다면 이 EC2 인스턴스에 더 많은 용량을 할당할 거고요. 부하가 적으면 당연히 오토 스케일링 그룹을 통해서 EC2 인스턴스 일부를 종료하겠죠. 그러니까 작동 원리상 우리는 지표를 사용해서 알람에 따라 오토 스케일링 그룹을 스케일링해야 합니다. 따라서 EC2 인스턴스는 CloudWatch 사용자 지정 지표를 푸시합니다. 바로 대기열의 길이를 나타냅니다. 처리를 기다리는 메시지의 수를 오토 스케일링 그룹의 인스턴스 개수로 나눈 값이죠. 그리고 이 지표가 특정 임계값을 초과하면 메시지가 너무 많다거나 인스턴스가 부족하다는 뜻이 됩니다.
따라서 애플리케이션에 필요한 모든 임계값을 설정할 때 지표가 위반되는 경우에 대해 CloudWatch 경보를 생성할 건데요. 그럼 CloudWatch 경보가 자동으로 오토 스케일링 그룹의 스케일링 정책에 할당되고 오토 스케일링 그룹을 그에 따라 적절하게 스케일링할 겁니다. 그러면 경보를 두 개 만들어 볼게요. 하나는 지표의 특정 임계값을 넘을 경우의 경보이고 또 하나는 지표의 또 다른 임계값 아래로 내려갈 경우의 경보입니다. 이것이 단계 스케일링 정책입니다. 예를 들면 하나는 올라가고 다른 하나는 내려가지요. 이렇게 SQS를 오토 스케일링 그룹에 통합하는 데 필요한 기본적인 것들을 봤는데요. 이런 스케일링을 하기 위해서 SQS나 EC2에서 사용 가능한 특별한 지표가 없습니다. 대기열 길이를 인스턴스 수로 나눈 값을 나타내는 사용자 지정 지표를 여러분이 만들어야만 합니다.
--- SQS to decouple between application tiers
이 아키텍처가 있으면 정말 유용합니다. 왜냐하면 애플리케이션 티어에서 분리를 만들어 볼 수 있고 매우 자주 쓰이는 기능입니다. EC2 인스턴스에 다량의 요청이 들어오면 오토 스케일링 그룹이 관리하는데 로드 밸런서 뒤에 있기도 합니다. 그래서 파일을 처리하라는 요청을 많이 받는다고 합시다.
그러면 이런 요청들을 SQS 대기열에 넣습니다. 대기열은 SQS 덕분에 무한대로 스케일링됩니다. 그리고 EC2 인스턴스의 또 다른 오토 스케일링 그룹이 대기열 뒤에서 그 대기열로부터 폴링을 합니다. 이 경우의 장점은 해당 SQS 대기열에 이전 슬라이드에서 설명했던 방식으로 오토 스케일링을 할 수 있다는 것입니다. 이런 방식으로 매우 큰 확장성이 있고 완전히 분리된 아키텍처를 얻을 수 있습니다. 중간에 SQS가 있는 솔루션의 이론적인 아키텍처를 지금까지 살펴보았습니다 부디 이해가 되었기를 바랍니다. AWS의 모든 부분들이 어떻게 서로 연결되는지 점점 보이시죠.
191. Amazon Simple Notification Service(AWS SNS)
--- Amazon SNS
이제 Amazon SNS를 살펴보죠.
메시지 하나를 여러 수신자에게 보낸다고 가정해 봅시다.
이런 경우 직접 통합을 (Direct integration) 쓸 수 있는데요. 구매 서비스 애플리케이션을 예로 들자면 이메일 알림을 보내고 사기 탐지 서비스와 배송 서비스 그리고 SQS 대기열에도 메시지를 보낼 수 있습니다. 하지만 수신 서비스를 새로 추가할 때마다 통합을 생성하고 작성해야 하므로 번거로울 수 있죠.
대신 Pub/Sub 즉, 게시/구독이라는 것을 사용할 수 있는데요. 이를 통해 구매 서비스가 메시지를 SNS 주제로 전송할 수 있습니다. 메시지를 주제로 게시하는 것이죠. 해당 주제에는 많은 구독자가 있으며 각 구독자는 SNS 주제에서 해당 메시지를 수신하고 이를 보관할 수 있습니다. 이것이 Pub/Sub이라고 하는 패턴이죠.
--- Amazon SNS
Amazon SNS에서 "이벤트 생산자"는 한 SNS 주제에만 메시지를 보냅니다.
"이벤트 수신자" 또는 구독자는 해당 주제와 관련한 SNS 알림을 받으려는 사람이죠.
따라서 SNS 주제 구독자는 해당 주제로 전송된 메시지를 모두 받게 됩니다. 그리고 메시지를 필터링하는 기능을 사용하는 경우에도 메시지를 받을 수 있죠.
주제별 최대 구독자 수는 몇 명일까요? 주제별로 최대 1,200만 이상의 구독자까지 가능합니다. 꽤 많은 편이죠. 이 숫자는 추후 변경될 수 있기 때문에 대략적인 구독자 수만 알려드리도록 하겠습니다.
계정당 가질 수 있는 주제 수는 최대 10만 개이고 더 늘릴 수도 있어요 하지만 이것도 변경될 수 있으니 대략적인 숫자만 알아두시면 돼요. 이런 SNS 주제 수 같은 건 시험에 나오지 않을 거예요.
SNS에서 구독자에게 게시할 수 있는 것에는 뭐가 있을까요? SNS에서 직접 이메일을 보낼 수도 있고 SMS 및 모바일 알림을 보낼 수도 있죠. 또한 지정된 HTTP 또는 HTTPS 엔드 포인트로 직접 데이터를 보낼 수도 있습니다. SNS는 SQS와 같은 특정 AWS 서비스와 통합하여 메시지를 대기열로 직접 보낼 수도 있고 메시지를 수신한 후 함수가 코드를 수행하도록 Lambda에 보내거나 Firehose를 통해 데이터를 Amazon S3나 Redshift로 보낼 수도 있죠.
--- SNS integrates with a lot of AWS services
SNS는 다양한 AWS 서비스에서 데이터를 수신하기도 합니다.
SNS로 직접 데이터를 보내는데요. CloudWatch 경보 Auto Scaling 그룹 알림 CloudFormation State Changes Budgets, S3 버킷 DMS, Lambda, DynamoDB RDS 이벤트 등이 있죠. 서비스명은 기억하지 않아도 돼요. AWS에서 알림이 발생하면 이러한 서비스가 지정된 SNS 주제로 알림을 보낸다는 것만 기억하시면 됩니다.
--- AWS SNS - Hot to publish
SNS 게시 방법을 알아보죠
SDK 주제 게시를 사용해 SNS에 메시지를 게시할 수 있는데요.
- 먼저 주제를 만든 다음
- 하나 또는 여러 개의 구독을 만들고
- SNS 주제에 게시하면 됩니다.
그럼 모든 구독자가 자동으로 해당 메시지를 받게 되죠.
혹은 모바일 앱 SDK 전용 직접 게시 방법이 있는데요.
- 플랫폼 애플리케이션을 만든 다음
- 플랫폼 엔드 포인트를 만들고
- 플랫폼 엔드 포인트에 게시하면 됩니다
- 수신 가능 대상은 Google, GCM, Apple APNS 또는 Amazon ADM 구독자입니다. 모두 모바일 애플리케이션으로 알림을 수신하게 되죠.
--- Amazon SNS - Security
보안 측면에서 Amazon SNS는 SQS와 동일합니다.
- 기본적으로 전송 중 암호화와
- KMS 키를 사용한 저장 데이터 암호화가 있고
- 클라이언트가 SNS에 암호화된 메시지를 보내려는 경우를 위한 클라이언트 측 암호화가 있는데요. 다시 말하지만 암호화 및 암호 해독은 클라이언트 몫입니다.
액세스 제어는 IAM 정책 중심입니다. 모든 SNS API가 IAM 정책으로 규제되기 때문이죠.
그리고 S3 버킷 정책과 매우 유사한 SNS 액세스 정책을 정의할 수 있는데요.
- SNS 주제에 교차 계정 액세스 권한을 갖거나
- S3 이벤트와 같은 서비스가 SNS 주제에 작성할 수 있도록 허용하려는 경우 매우 유용합니다.
192. SNS 및 SQS - 팬아웃 패턴
--- SNS + SQS: Fan Out
SNS와 SQS에 적용할 수 있는 팬아웃(Fan Out) 패턴을 설명해 드리겠습니다. 여러 SQS 대기열에 메시지를 전송하려 할 때 모든 SQS 대기열에 메시지를 개별적으로 보내면 문제가 발생할 수 있습니다. 예를 들어 앱이 중도에 갑자기 종료되거나, 전송이 실패하거나 또는 나중에 SQS 대기열을 추가할 수 있습니다.
그럴 때 팬아웃 패턴을 사용하면 SNS 주제에 한 번만 푸시해도 원하는 만큼의 SNS 주제의 여러 SQS 대기열을 구독할 수 있습니다. 이때 대기열은 구독자(Subscriber)가 되며 그들 모두 SNS에 전송된 메시지를 받게 됩니다.
예를 들어, 구매 서비스에서 2개의 SQS 대기열로 메시지를 보낼 때 하나의 SNS 주제로 한 번만 메시지를 전송하면 SNS 주제의 구독자인 대기열에서 연결된 사기 서비스와 운송 서비스로 메시지를 전달할 수 있습니다.
팬아웃은 완전히 분리된 모델이므로 데이터 손실이 발생하지 않습니다.
SQS를 통해 데이터 지속성, 지연 처리 작업 재시도가 가능하며
팬아웃 패턴으로 더 많은 SQS 대기열을 SNS 주제에 구독시킬 수 있습니다.
이를 위해서는 SQS 대기열 접근 정책을 통해 SNS 주제를 SQS 대기열에 메시지를 전송하도록 허용해야 합니다. 이렇게 대기열 접근 정책의 또 다른 사용 사례를 살펴보았습니다.
--- Application: S3 Events to multiple queues
다음으로 팬아웃 패턴의 적용 방법을 살펴보겠습니다. 예를 들면 S3 이벤트를 여러 대기열로 보내고 싶다고 합니다.
S3 이벤트 규칙에는 제약 조건이 있는데 같은 이벤트 유형 예를 들면 객체 생성과 같은 이벤트 유형이나 images/ 등 같은 접두어의 조합에서는 하나의 S3 이벤트 규칙만을 적용할 수 있습니다.
그렇다면 어떻게 여러 SQS 대기열로 동일한 S3 이벤트 알림을 보낼 수 있을까요? 이럴 때 팬아웃 패턴을 사용하면 됩니다.
예를 들어, S3 버킷에 이벤트인 S3 객체가 있다고 가정하고 이 이벤트를 SNS 주제로 전송하기 위해 여러 SQS 대기열을 SNS 주제에 구독시키면 됩니다. 앱, 이메일, 람다 함수 등도 SNS 주제에 구독시킬 수 있죠. 팬아웃 패턴을 사용해서 Amazon S3에서 발생한 이벤트를 여러 목적지로 보낼 수 있습니다.
--- Application: SNS to Amazon S3 through Kinesis Data Firehose
데이터 전송을 위한 또 다른 아키텍처로는 Kinesis Data Firehose(KDF)를 통해 SNS를 Amazon S3로 보내는 방식이 있습니다.
SNS는 KDF와 통합되어 있어 구매 서비스에서 SNS 주제로 데이터를 전송하면 Kinesis Data Firehouse에서 그 정보를 수신하고 KDF에서는 데이터를 다시 Amazon S3 버킷으로 전송하거나 KDF에서 지원하는 다른 목적지로 데이터를 전송함으로써 더 넓은 범위까지 메시지를 지속하고 SNS 주제로 전송할 수 있게 됩니다.
--- Amazon SNS - FIFO Topic
팬아웃 패턴은 FIFO 주제에도 적용이 가능합니다. Amazon SNS에는 FIFO 기능, 즉 선입선출(First In First Out) 기능이 있어 주제 내의 메시지에 순서를 지정하여
생산자가 1, 2, 3, 4의 순서로 메시지를 전송합니다. 이때 구독은 SQS FIFO만 할 수 있고 순서대로 1, 2, 3, 4라는 메시지를 수신하게 됩니다.
즉, SQS FIFO와 마찬가지로 SNS FIFO에서는
- 메시지 그룹 ID에 따라 메시지를 정렬하거나
- 중복된 ID나 콘텐츠에 대해 중복제거를 할 수 있습니다.
그리고 SQS FIFO 대기열만 구독할 수 있습니다.
처리량은 SNS FIFO 대기열과 같이 제한된 처리량을 갖습니다. 이는 SQS FIFO 대기열만이 SNS FIFO 주제를 읽을 수 있기 때문입니다.
--- SNS FIFO + SQS FIFO : Fan Out
왜 FIFO를 사용할까요? SQS FIFO에 팬아웃 할 때는 팬아웃 패턴, 순서, 중복제거가 필요합니다.
구매 서비스에서 데이터를 SNS FIFO 주제로 전송하면 두 개의 SQS FIFO 대기열로 데이터를 전달하여 사기 서비스와 배송 서비스에서도 FIFO 대기열을 조회할 수 있게 됩니다.
--- SNS - Message Filtering
팬아웃 패턴과 관련된 SNS의 또 다른 기능으로는 SNS 메시지 필터링입니다.
메시지 필터링이란 SNS 주제 구독자들에게 전송할 메시지를 필터링하는 JSON 정책입니다. 구독에 필터링 정책이 없으면 기본적으로 모든 메시지를 수신하게 됩니다.
메시지 필터링 정책을 적용하면 어떻게 되는지 알려드리겠습니다. 아래 예시에서는 구매 서비스가 SNS 주제에 거래 내용을 전송합니다. 거래 내용에는 주문 번호와 제품명인 연필이 있고 수량은 4개이고 발주된(Placed) 상태 입니다.
여기서 SQS 대기열을 생성하여 모든 주문이 아닌 발주된 주문만을 처리하도록 하기 위해 SQS 대기열을 SNS 주제에 구독시키고 JSON에서 필터링 정책을 적용해 보겠습니다. 그리고 정책에서 조건을 발주 상태로 제한하면 이 정책에 맞는 메시지만이 SQS 대기열에 전달됩니다. 취소된(Cancelled) 주문에 대한 SQS 대기열도 필요하겠죠. 여기서는 취소된 주문만 통과시키는 필터링 정책을 생성하여 해당하는 주문만을 SNS 주제에서 SQS 대기열로 보낼 수 있습니다. 그러면 발주와 취소 주문 SQS 대기열은 서로 다른 메시지를 받게 됩니다.
여기에 취소 주문에 적용한 필터링 정책을 그대로 가져와 이메일 구독을 생성하여 정책을 적용하거나
또는 거절된(Declined) 주문에 대한 필터를 적용한 SQS 대기열이나 필터링 없이 모든 SNS 주제 메시지를 받는 SQS 대기열을 만들 수도 있습니다. 이처럼 팬아웃 패턴, 메시지 필터링, FIFO 대기열, FIFO 주제를 활용해 다양한 기능을 구현할 수 있고 시험에서도 나올 거예요.
193. SNS - 실습
194. Amazon Kinesis
