미들웨어로 다른 서비스간 합동 작업을 하는 방법을 다루는 챕터입니다.
애플리케이션을 여러 개 배포하려고 할 때 커뮤니케이션을 할 수 밖에 없습니다여러분의 서비스는 정보와 데이터를 공유해야 합니다. 그리고 애플리케이션 커뮤니케이션은 두 가지 패턴으로 나뉘어집니다

어플리케이션 간의 동기화는 때때로 문제가 될 수 있습니다. 트래픽이 갑자기 급증하거나 아무것도 예측할 수 없을 때 일반적으로 애플리케이션을 분리하고 분리 계층(decouple)을 확장하는 것이 좋습니다.

Decouple 모델

SQS : 대기열 모델
SNS : pub/sub 모델
Kinesis : 실시간 스트리밍 및 대용량 데이터

---

SQS

SQS란?

• Amazon Simple Queue Service(SQS)는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 메시지 대기열입니다.
• 표준(Standard) 대기열 가장 오래됐고, 거의 10년이 넘어가는 기술이라 안정됨.
• 애플리케이션 분리하는데 사용되는 완전 관리형 서비스입니다.

속성 :

• 무제한 처리량
  • 즉 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 포함시킬 수 있습니다.
• 메시지는 수명이 짧습니다.
  • 기본값 4일, 최대 14일
• 지연 시간이 짧습니다.
  • SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다 게시 및 수신 시 10밀리초 이내로 매우 빠르게 응답을 받게 됩니다.
• SQS의 메시지는 작아야 합니다.
  • 전송된 메시지당 크기 최대 256KB
• 중복 메시지가 있을 수 있습니다.
• 최선의 오더라는 뜻으로 품절 메시지를 보낼 수도 있습니다.

SQS - 메시지 생산자

• 생산자는 SDK 소프트웨어 개발 키트를 사용하여 SQS에 메시지를 보낼 겁니다.
  • SendMessage API 사용합니다.
• 소비자가 해당 메시지를 읽고 삭제할 때까지 SQS 대기열에 유지됩니다.
  EX)

패킷과 같은 오더를 처리한 다음 센터로 배송하려고 합니다.

- Order Id
- Customer Id
- 원하는 속성등의 일부 정보가 포함된 메시지를 SQS 대기열에 보냅니다.

• 표준 SQS는 무제한 처리량을 자랑합니다.

SQS - 메시지 소비자

• 소비자는 일부 코드로 작성해야 하는 애플리케이션이고 이러한 애플리케이션은 EC2 인스턴스에서 실행될 수 있습니다.
• 온프레미스, AWS Lambda의 람다 함수에서 실행할 수도 있습니다.
• 대기열에는 소비자가가 있고 소비자는 SQS 메시지를 폴링합니다.
  • 소비자는 한 번에 최대 10개의 메세지를 받을 겁니다.
• 소비자는 이 메시지들을 폴링하고 처리할 책임이 있습니다.
• 이후 소비자가 이 메시지들을 DeleteMessage API로 대기열에서 삭제합니다.

다중 EC2 인스턴스 소비자

• SQS 대기열은 메세지를 동시에 수신하고 처리할 소비자를 여러 개 가질 수 있습니다.
• 적어도 한번은 전송이 됩니다.
• 중복으로 메시지를 받을 수 있기 때문에, 최선의 노력으로 메시지 순서 지정합니다.
• 소비자가 메시지를 처리하면 메시지를 삭제해야 합니다.
• SQS 대기열에서 더 많은 메시지가 있어서 처리량을 늘려야 하면
  소비자를 추가하고 수평 확장(ASG)을 수행해서 처리량을 개선할 수 있습니다.

SQS - ASG (Auto Scaling Group)

SQS - 애플리케이션 계층 간에 분리

SQS 보안

암호화

• HTTPS API를 사용하여 전송 중 암호화를 합니다.
• KMS 키를 사용하여 미사용 암호화를 얻습니다.
• 클라이언트가 자체적으로 암호화 및 암호 해독을 수행하는 클라이언트 측 암호화를 합니다.

액세스 제어

• SQS API에 대한 액세스를 규제할 수 있습니다.

SQS 액세스 정책

• S3 버킷 정책과 유사합니다.
• SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우
• SNS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용

SQS 대기열 액세스 정책

• 교차 계정 액세스
• S3 버킷이 있으면 이것이 이벤트 알림을 SQS 대기열에 게시

SQS - 메시지 가시성 시간 초과

• 소비자가 메시지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 됩니다.
• 기본값으로 메시지 가시성 시간 초과는 30초입니다.
• 가시성 시간 초과 기간 내에서는 그 메시지는 다른 소비자들에게 보이지 않습니다.
• 가시성 시간 초과가 되고 메시지가 삭제되지 않았다면 메시지는 대기열에 다시 넣습니다. (큐에 재삽입)

• 가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 메시지가 두 번 처리될 수도 있다는 것을 알 수 있습니다.

• 소비자가 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있고
  해당 메시지를 두 번 처리하고 싶지 않다면 소비자는ChangeMessageVisibility API를 호출하여 SQS에 알려야 합니다.

  • ChangeMessageVisibility
    메시지를 처리하지 않아 가시성 시간 초과 기간을 벗어날 때 사용합니다.

• 기본값으로 매우 높은 값 예를 들어 시간으로 설정하면
  소비자가 충돌했을 때 이 메시지가 다시 나타날 때까지
  즉 SQS 대기열에 보이기까지 몇 시간이 걸립니다.

• 몇 초와 같이 매우 낮은 값으로 설정하면
  소비자가 어떤 이유로든 해당 메시지를
  처리할 시간이 충분하지 않으면 다른 소비자가 메시지를 여러 번 읽을 것이며
  중복 처리될 수 있습니다.

Long Polling

예를 들어 소비자가 대기열에 메시지를 요청하는데
대기열에 아무것도 없다면 메시지 도착을 기다리면 됩니다
이것을 롱 폴링이라고 합니다.

롱폴링의 이점 :

- 첫 번째는 지연 시간을 줄일 수 있습니다.
- 두 번째는 SQS로 보내는 API 호출 숫자를 줄일 수 있습니다.

• 롱 폴링은 애플리케이션의 효율성과 대기 시간을 증가시키면서 SQS로의 API 호출 수를 감소시킵니다.

• 1초부터 20초 사이로 구성이 가능합니다.

구성 방법 :

• 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링을 활성화하는 방법
• WaitTimeSeconds를 지정함으로 소비자가 스스로 롱 폴링을 하도록 선택하는 방법

SQS FIFO 옵션

• First-In First-Out
  • 표준 대기열 보다 더 확실히 순서가 보장되는 것입니다.
• 소비자가 SQS FIFO 대기열로부터 메시지를 불러올 때 정확히 동일한 순서로 메시지를 받게 해 줍니다.
• 제한된 처리량
  • 묶음이 아닐 경우에는 초당 300개의 메시지
  • 메시지를 묶음으로 보낼 경우의 처리량은 초당 3000개
• SQS FIFO 대기열의 기능으로 인해 중복을 제거하여 정확히 한번만 보낼 수 있게 해 줍니다.
• 분리가 발생하거나 메시지의 순서를 유지할 필요가 있을 때 FIFO 대기열을 확인해야 합니다.

SQS with Auto Scaling Group

SQS 대기열과 오토 스케일링 그룹이 있을 때 ASG 내의 EC2 인스턴스에 메시지를 SQS 대기열에서 폴링합니다 이는 오토 스케일링 그룹을 자동으로 대기열 크기에 따라 확장시키기 위함으로 CloudWatch 지표인 대기열 길이를 보고 결정할 수 있습니다.

ApproximateNumberOfMessages라고 하는 이 지표는 대기열에 몇 개의 메시지가 남아 있는지를 표시합니다. 예를 들어 대기열에 쌓여있는 메시지가 1000개가 넘는다면 인스턴스를 확장하는 트리거를 발동 시킬 수 있습니다.

SQS와 ASG의 패턴

데이터베이스에 바로 요청을 쓰는 대신 애플리케이션이 요청, 즉 트랜잭션을 일명 무한히 확장 가능한 SQS 대기열에 먼저 쓰는 방법을 사용하면 처리량 문제와 데이터 유실을 해결할 수 있습니다.

애플리케이션에 요청이 전송되고 이 요청은 메시지로 대기열에 안착하는데 이는 곧 모든 트랜잭션, 즉 모든 요청이 SQS 대기열에 메시지로서 전달되기 때문에,
유실되는 요청없이 모든 요청은 지속적으로 SQS 대기열에 저장될 수 있습니다.

메시지가 데이터베이스에 삽입되고 나면 기존 SQS 대기열에서 해당 메시지를 삭제합니다 이렇게 SQS를 버퍼로 사용하여 모든 트랜잭션이 데이터베이스에 쓰이도록 확인할 수 있습니다

이 패턴은 클라이언트에게 따로 데이터베이스에 쓰였다는 확인을 전송할 필요가 없을 때만 사용 가능합니다 하지만 SQS 대기열에 쓰기 작업이 일어났다는 것만으로도 어느 정도 작업 완료에 대한 체크가 가능합니다.

---

SNS

SNS란?

Amazon Simple Notification Service(Amazon SNS)는 게시자에서 구독자( 생산자 및 소비자 라고도 함 )에게 메시지 전달을 제공하는 관리형 서비스입니다.
예를 들어, 만약 특정 서비스를 구매했을 때 다양한 채널로 알림을 보내고 싶을 때 직접 통합해 보내는 방법도 있지만 번거로운 방법입니다. 이를 대체할 방법으로 Pub/ Sub 방식이 있습니다.
이는 구매 서비스가 SNS topic으로 메시지를 전송해서 메시지를 게시하도록 만들 수 있도록 만들어주는데, 만약 해당 topic에 많은 구독자가 존재한다면 각 구독자들은 SNS 주제로부터 메시지를 수신해 자신이 보관할 수 있습니다.

Amazon SNS

• "이벤트 생산자"는 한 SNS 주제에만 메시지를 보냅니다.
  

• "이벤트 수신자" 또는 구독자는 해당 주제와 관련한 SNS 알림을 받으려는 사람입니다.

• SNS 주제 구독자는 해당 주제로 전송된 메시지를 모두 받게 됩니다.
  

• 주제별로 최대 1,200만 이상의 구독자까지 가능합니다.

• 계정당 가질 수 있는 주제 수는 최대 10만 개이고 늘릴 수도 있습니다.

SNS 게시 방법

• SDK 주제 게시를 통해(Topic publish)
  • 주제를 만듭니다.
  • 여러 개의 구독을 만듭니다.
  • 주제를 게시합니다.
• 모바일 앱 SDK 전용 직접 게시 방법 (Direct publish)
  • 플랫폼 애플리케이션을 만든 다음
  • 플랫폼 엔드 포인트를 만들고
  • 플랫폼 엔드 포인트에 게시하면 됩니다.
  • Google, GCM, Apple APNS 또는 Amazon ADM 구독자

SNS - 보안

Amazon SNS는 SQS와 동일합니다

• 암호화

  • HTTPS API를 사용하여 전송 중 암호화를 합니다.
  • KMS 키를 사용하여 미사용 암호화를 얻습니다.
  • 클라이언트가 자체적으로 암호화 및 암호 해독을 수행하는 클라이언트 측 암호화를 합니다.

• 액세스 제어

  • SQS API에 대한 액세스를 규제할 수 있습니다.

• SQS 액세스 정책

  • S3 버킷 정책과 유사합니다.

  • SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우

  • SNS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용

    
    

SNS & SQS Fan Out

Fan out은 SNS 주제로 한 번 메시지를 전송하면 원하는 숫자 만큼의 SQS 대기열들이 SNS 주제를 구독하도록 해서 SNS로 전송된 모든 메시지를 수신할 수 있도록 하는 것입니다.

예를 들어, 아래와 같이 구매 서비스가 두 개의 SQS 대기열로 메시지를 보내고 싶은경우 직접 보내는 대신에 하나의 메시지를 SNS 주제로 전송하고, 그러면 대기열들은 SNS 주제의 구독자가 됩니다. 이를 통해, 사기 탐지 서비스와 선적 서비스 등의 서비스가 각각의 SQS 대기열로부터 모든 메시지를 읽을 수 있게 됩니다.

이 방법으로 데이터 지속성, 지연 처리, 작업 재시도 등의 효과를 얻을 수 있습니다. 또한, 장시간에 걸쳐 더 많은 SQS 대기열을 SNS 주제의 구독자로 추가할 수도 있습니다.
이를 위해서는 SQS 대기열 접근 정책이 SNS에 쓰기 작업 하는 것을 허용해야 합니다.

Fan out 적용: S3 events to multiple queues

• 만약 S3에 객체가 추가되었을 때 알림을 보내고 싶다면 event type과 prefix (ex. images/)를 지정해 해당 이벤트 형식에 대해서는 하나의 S3 event rule만 갖도록 할 수 있습니다.
• 그런데 만약 동일한 S3 이벤트 알림을 여러 SQS queues로 보내고 싶다면 어 때는 fan-out 패턴을 이용해야 합니다.
  • 즉, SNS 주제를 생성해 S3 버킷 객체 생성 이벤트를 해당 주제로 전송하고 다수의 SQS 대기열이 SNS 주제에 팬 아웃 패턴의 일종으로 구독하도록 만드는 것입니다.
  • SQS 대기열 외에도 람다, 이메일 등 다른 형식의 애플리케이션을 구독하는 것도 물론 가능합니다.

Fan out 적용: SNS - FIFO Topic

• SQS에서의 FIFO와 유사합니다.
  • 메시지 그룹 id를 통해 정렬합니다. (같은 그룹에 있는 메시지는 정렬 되어 있습니다).
  • 중복 방지 id 또는 내용 기반으로 중복을 제거하도록 할 수 있습니다.
• SQS FIFO queues만 FIFO SNS 주제의 구독자가 될 수 있습니다.
  • 따라서, SQS FIFO 대기열과 동일한 처리량을 갖게 됩니다.
• SNS FIFO 역시 SQS FIFO queues와 결합해 Fan out 적용이 가능합니다.

Fan out 적용: Message filtering in SNS

• SNS 주제 구독자에게 JSON 정책을 이용해 필터링된 메시지만 보낼 수 있습니다.
• 만약 구독이 필터링 정책을 가지고 있지 않다면 해당 구독자는 모든 메시지를 받게 됩니다.

위와 같이 새로운 트랜잭션이 발생했다고 가정해 보면, 해당 트랜잭션은 발주 완료 상태입니다.
그런데 이 때, 전체 주문이 아니라 발주 완료된 주문에 대해서만 SQS 대기열을 만들려 한다 가정해 보자.
그러면 이를 위해 SQS 대기열이 SNS 주제를 구독하도록 하고 JSON으로 필터링 정책을 적용하게 됩니다.. 이 때, 정책 내에는 발주 완료 상태인 주문만 찾도록 명시합니다. 그러면 정책에 부합하는 메시지만 SQS 대기열로 전달됩니다. 마찬가지로, 취소한 주문에 대한 대기열을 생성하도록 할 수도 있습니다.

AWS Certified Solutions Architect Associate 시험합격!