미들웨어로 다른 서비스간 합동 작업을 하는 방법을 다루는 챕터입니다.
애플리케이션을 여러 개 배포하려고 할 때 커뮤니케이션을 할 수 밖에 없습니다여러분의 서비스는 정보와 데이터를 공유해야 합니다. 그리고 애플리케이션 커뮤니케이션은 두 가지 패턴으로 나뉘어집니다
어플리케이션 간의 동기화는 때때로 문제가 될 수 있습니다. 트래픽이 갑자기 급증하거나 아무것도 예측할 수 없을 때 일반적으로 애플리케이션을 분리하고 분리 계층(decouple)을 확장하는 것이 좋습니다.
Decouple 모델
SQS : 대기열 모델
SNS : pub/sub 모델
Kinesis : 실시간 스트리밍 및 대용량 데이터
패킷과 같은 오더를 처리한 다음 센터로 배송하려고 합니다.
- Order Id
- Customer Id
- 원하는 속성등의 일부 정보가 포함된 메시지를 SQS 대기열에 보냅니다.
30초
입니다.가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 메시지가 두 번 처리될 수도 있다는 것을 알 수 있습니다.
소비자가 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있고
해당 메시지를 두 번 처리하고 싶지 않다면 소비자는ChangeMessageVisibility API
를 호출하여 SQS에 알려야 합니다.
기본값으로 매우 높은 값 예를 들어 시간으로 설정하면
소비자가 충돌했을 때 이 메시지가 다시 나타날 때까지
즉 SQS 대기열에 보이기까지 몇 시간이 걸립니다.
몇 초와 같이 매우 낮은 값으로 설정하면
소비자가 어떤 이유로든 해당 메시지를
처리할 시간이 충분하지 않으면 다른 소비자가 메시지를 여러 번 읽을 것이며
중복 처리될 수 있습니다.
예를 들어 소비자가 대기열에 메시지를 요청하는데
대기열에 아무것도 없다면 메시지 도착을 기다리면 됩니다
이것을 롱 폴링이라고 합니다.
- 첫 번째는 지연 시간을 줄일 수 있습니다.
- 두 번째는 SQS로 보내는 API 호출 숫자를 줄일 수 있습니다.
롱 폴링은 애플리케이션의 효율성과 대기 시간을 증가시키면서 SQS로의 API 호출 수를 감소시킵니다.
1초부터 20초 사이로 구성이 가능합니다.
SQS 대기열과 오토 스케일링 그룹이 있을 때 ASG 내의 EC2 인스턴스에 메시지를 SQS 대기열에서 폴링합니다 이는 오토 스케일링 그룹을 자동으로 대기열 크기에 따라 확장시키기 위함으로 CloudWatch 지표인 대기열 길이를 보고 결정할 수 있습니다.
ApproximateNumberOfMessages
라고 하는 이 지표는 대기열에 몇 개의 메시지가 남아 있는지를 표시합니다. 예를 들어 대기열에 쌓여있는 메시지가 1000개가 넘는다면 인스턴스를 확장하는 트리거를 발동 시킬 수 있습니다.
데이터베이스에 바로 요청을 쓰는 대신 애플리케이션이 요청, 즉 트랜잭션을 일명 무한히 확장 가능한 SQS 대기열에 먼저 쓰는 방법을 사용하면 처리량 문제와 데이터 유실을 해결할 수 있습니다.
애플리케이션에 요청이 전송되고 이 요청은 메시지로 대기열에 안착하는데 이는 곧 모든 트랜잭션, 즉 모든 요청이 SQS 대기열에 메시지로서 전달되기 때문에,
유실되는 요청없이 모든 요청은 지속적으로 SQS 대기열에 저장될 수 있습니다.
메시지가 데이터베이스에 삽입되고 나면 기존 SQS 대기열에서 해당 메시지를 삭제합니다 이렇게 SQS를 버퍼로 사용하여 모든 트랜잭션이 데이터베이스에 쓰이도록 확인할 수 있습니다
이 패턴은 클라이언트에게 따로 데이터베이스에 쓰였다는 확인을 전송할 필요가 없을 때만 사용 가능합니다 하지만 SQS 대기열에 쓰기 작업이 일어났다는 것만으로도 어느 정도 작업 완료에 대한 체크가 가능합니다.
Amazon Simple Notification Service(Amazon SNS)는 게시자에서 구독자( 생산자 및 소비자 라고도 함 )에게 메시지 전달을 제공하는 관리형 서비스입니다.
예를 들어, 만약 특정 서비스를 구매했을 때 다양한 채널로 알림을 보내고 싶을 때 직접 통합해 보내는 방법도 있지만 번거로운 방법입니다. 이를 대체할 방법으로 Pub/ Sub 방식이 있습니다.
이는 구매 서비스가 SNS topic으로 메시지를 전송해서 메시지를 게시하도록 만들 수 있도록 만들어주는데, 만약 해당 topic에 많은 구독자가 존재한다면 각 구독자들은 SNS 주제로부터 메시지를 수신해 자신이 보관할 수 있습니다.
"이벤트 생산자"는 한 SNS 주제에만 메시지를 보냅니다.
"이벤트 수신자" 또는 구독자는 해당 주제와 관련한 SNS 알림을 받으려는 사람입니다.
SNS 주제 구독자는 해당 주제로 전송된 메시지를 모두 받게 됩니다.
주제별로 최대 1,200만 이상의 구독자까지 가능합니다.
계정당 가질 수 있는 주제 수는 최대 10만 개이고 늘릴 수도 있습니다.
Amazon SNS는 SQS와 동일합니다
암호화
액세스 제어
SQS 액세스 정책
S3 버킷 정책과 유사합니다.
SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우
SNS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용
Fan out은 SNS 주제로 한 번 메시지를 전송하면 원하는 숫자 만큼의 SQS 대기열들이 SNS 주제를 구독하도록 해서 SNS로 전송된 모든 메시지를 수신할 수 있도록 하는 것입니다.
예를 들어, 아래와 같이 구매 서비스가 두 개의 SQS 대기열로 메시지를 보내고 싶은경우 직접 보내는 대신에 하나의 메시지를 SNS 주제로 전송하고, 그러면 대기열들은 SNS 주제의 구독자가 됩니다. 이를 통해, 사기 탐지 서비스와 선적 서비스 등의 서비스가 각각의 SQS 대기열로부터 모든 메시지를 읽을 수 있게 됩니다.
이 방법으로 데이터 지속성, 지연 처리, 작업 재시도 등의 효과를 얻을 수 있습니다. 또한, 장시간에 걸쳐 더 많은 SQS 대기열을 SNS 주제의 구독자로 추가할 수도 있습니다.
이를 위해서는 SQS 대기열 접근 정책이 SNS에 쓰기 작업 하는 것을 허용해야 합니다.
위와 같이 새로운 트랜잭션이 발생했다고 가정해 보면, 해당 트랜잭션은 발주 완료 상태입니다.
그런데 이 때, 전체 주문이 아니라 발주 완료된 주문에 대해서만 SQS 대기열을 만들려 한다 가정해 보자.
그러면 이를 위해 SQS 대기열이 SNS 주제를 구독하도록 하고 JSON으로 필터링 정책을 적용하게 됩니다.. 이 때, 정책 내에는 발주 완료 상태인 주문만 찾도록 명시합니다. 그러면 정책에 부합하는 메시지만 SQS 대기열로 전달됩니다. 마찬가지로, 취소한 주문에 대한 대기열을 생성하도록 할 수도 있습니다.