[AWS]메시징SNS 및 대기열SQS

<예시>

커피숍에서 계산원은 고객의 주문을 받고 바리스타는 음료를 만듭니다. 현재는 계산원이 주문을 받고 종이에 기록한 다음 주문을 바리스타에게 전달하죠. 그러면 바리스타는 주문서를 참고해 음료를 만듭니다. 다음 주문이 들어오면 이 프로세스가 반복됩니다. 이 작업은 계산원과 바리스타가 손발이 잘 맞을 때는 효과가 탁월하죠. 하지만 계산원이 주문을 받고 주문서를 바리스타에게 전달했는데 바리스타가 쉬고 있거나 다른 주문을 처리하느라 바쁘다면 어떨까요? 계산원은 바리스타가 주문을 처리할 준비가 되기 전까지는 아무것도 할 수 없습니다. 그리고 특정 시점이 되면 주문이 취소되고 계산원은 다음 고객을 응대하게 될 것입니다.

 

이 프로세스에는 결함이 있습니다. 계산원이나 바리스타의 손발이 맞지 않으면 프로세스가 저하되어 주문을 받는 속도가 느려지고 주문을 완료할 수 없게 되니까요. 시스템에 일종의 완충 기억 장치나 대기열을 도입하면 프로세스가 훨씬 개선될 것입니다. 주문을 바리스타에게 직접 건네는 대신 계산원은 주문판 같은 일종의 완충 기억 장치에 주문을 게시합니다.

 

메시지를 완충 기억 장치에 배치한다는 개념을 메시징 또는 대기열이라고 합니다.

밀결합된 아키텍쳐

계산원이 바리스타에게 주문서를 전달하면 애플리케이션은 메시지를 보내 다른 애플리케이션과 통신합니다. 애플리케이션이 앞의 계산원과 바리스타처럼 직접 소통한다면 밀결합된 상태라고 부릅니다

대표적인 특징은 구성 요소 하나가 고장 나거나 변경되면 다른 구성 요소나 심지어 전체 시스템에 문제가 발생한다는 점입니다. 예를 들어 애플리케이션 A가 애플리케이션 B에 메시지를 직접 보낼 때 애플리케이션 B에 장애가 발생하여 메시지를 받을 수 없게 되면 애플리케이션 A에도 오류가 표시되기 시작됩니다. 

소결합된 아키텍처

특정 구성 요소에 장애가 발생하면 구성 요소가 격리되기 때문에 전체 시스템 장애로 확장되지 않습니다. - 더 안정적

계산원과 바리스타 예시처럼 완충 기억 장치 버퍼를 사이에 도입했습니다. 이 경우에는 메시지 대기열을 도입했죠. 애플리케이션 A가 메시지를 대기열로 전달한 후 애플리케이션 B가 처리합니다. 애플리케이션 B에 장애가 발생해도 애플리케이션 A에는 중단이 발생하지 않습니다. 전송 중인 메시지는 여전히 대기열로 전송될 수 있으며 처리될 때까지 대기열에 남습니다.

이것이 소결합된 상태이며 AWS가 AWS 기반의 아키텍처에서 구현하고자 하는 상태입니다.

B에 장애가 발생해도 메시지 대기열에 계속 쌓임

- Amazon Simple Queue Service,  SQS

SQS를 이용하면 볼륨에 상관없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있습니다.

메시지를 잃어버릴 염려가 없으며 다른 서비스 사용을 요구하지도 않습니다. 메시지는 커피 주문이며 주문판은 SQS 대기열이라고 생각하세요. 메시지에는 주문자 이름, 커피 주문 내용, 주문한 시간이 표시됩니다. 메시지에 포함된 데이터를 페이로드라고 하며 이러한 데이터는 전달되기 전까지 보호됩니다. SQS 대기열은 메시지가 처리되기 전까지 배치되는 곳입니다. 그리고 AWS는 사용자가 이러한 대기열을 호스팅할 수 있도록 기본 인프라를 관리합니다. 규모 조정이 자동 실행되고, 안정적이며, 쉽게 구성하고 사용할 수 있습니다. 

- Amazon Simple Notification Service, SNS

Amazon SNS는 메시지를 서비스에 전달하는 데 사용한다는 점에서 이와 비슷하지만 알림을 최종 사용자에게도 전송할 수 있습니다. 게시/구독, 줄여서 Pub/Sub라고 하는 다른 방식으로 전송하죠. 사용자는 메시지를 전달하는 채널인 SNS 주제를 만들 수 있습니다. 그런 다음에는 주제에 대한 구독자를 구성하고 이러한 구독자에게 최종적으로 메시지를 게시합니다. 현실에서는 메시지 하나를 주제에 전달하면 한 번에 모든 구독자에게 메시지가 전달됩니다. SQS 대기열, AWS Lambda 함수, HTTPS 또는 HTTP 웹 후크 같은 엔드포인트도 구독자가 될 수 있습니다.

 

또한 SNS를 사용하면 모바일 푸시, SMS와 이메일을 사용하여 알림을 최종 사용자에게 전달할 수 있습니다. 이를 커피숍에 적용해 보겠습니다. 고객의 음료가 준비되면 알림을 보낼 수 있습니다. 간단한 SMS로 음료를 가져가라고 알리거나 모바일 푸시를 이용하는 식이죠. 

<예시>

모든 주제를 다루는 단일 뉴스레터 대신 이를 3개의 뉴스레터로 나누고 각 뉴스레터는 쿠폰, 커피 상식, 신제품과 같은 특정 주제만을 다룹니다. 이제 구독자는 구독한 특정 주제에 대해서만 즉시 업데이트를 받게 됩니다.

구독자는 주제를 하나 또는 여러 개 구독할 수 있습니다. 예를 들어 첫 번째 고객은 쿠폰 주제만 구독하고 두 번째 구독자는 커피 상식 주제만 구독합니다. 세 번째 고객은 커피 상식 주제와 신제품 주제를 구독합니다.

---

밀결합된 / 소결합된

밀결합된 - <데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등>이 포함될 수 있습니다.
이러한 유형의 아키텍처를 모놀리식 애플리케이션으로 볼 수 있습니다. 애플리케이션 아키텍처에 대한 이 접근 방식에서는 한 구성 요소에서 장애가 발생하면 다른 구성 요소에서 장애가 발생하고, 심지어 전체 애플리케이션에서 장애가 발생할 수도 있습니다.

 

소결합된 - 단일 구성 요소에 장애가 발생해도 다른 구성 요소들은 서로 통신하기 때문에 계속 작동합니다. 소결합 때문에 전체 애플리케이션에서 장애가 발생하는 것이 방지됩니다.

AWS에서 애플리케이션을 설계할 때 다양한 기능을 수행하는 서비스 및 구성 요소를 사용하여 마이크로서비스 접근 방식을 취할 수 있습니다. 다음 두 서비스는 애플리케이션 통합을 촉진합니다. SNS, SQS