ENCORE CLOUD ARCHITECTURE TIL 2/18

신민창·2021년 2월 18일
0

TIL

목록 보기
11/46

결합 해제된(약결합) 아키텍처 구축

강력하게 통합된 서버 체인을 중심으로 움직이면, 이러한 구성 요소/계층의 하나에 장애가 발생하면 시스템에 치명적인 영향을 줄 수 있습니다. 또한 이 때문에 규모 조정이 지연될 수 있습니다. 한 계층에 서버를 추가하거나 제거하는 경우, 연결된 모든 계층의 모든 서버가 적절하게 연결되어야 하므로 시간이 지연되고 리소스를 추가할수록 복잡성이 크게 증가합니다.

Amazon SQS를 이용한 결합 해제

Amazon SQS는 관리 부담이 없으며 최소한의 구성으로도 바로 사용할 수 있는 완전 관리형 서비스입니다. 이 서비스는 방대한 규모로 작동하므로 하루에 수십억 건의 메시지를 처리할 수 있습니다. 컴퓨터, 네트워크 또는 가용 영역의 장애가 발생하더라도 메시지를 액세스할 수 있도록, 다수의 중복 가용 영역이 있는 고가용성의 단일 AWS 리전 내에 모든 메시지 대기열과 메시지를 저장합니다. 메시지는 동시에 전송하고 읽을 수 있습니다.
개발자는 Amazon SQS 대기열을 익명으로 또는 특정 AWS 계정과 안전하게 공유할 수 있습니다. IP 주소와 특정
시간으로 대기열 공유를 제한할 수도 있습니다.

  • 비동기식 처리를 사용하여 각 단계에서 신속하게 응답
  • 작업 인스턴스의 수를 늘려 성능 및 서비스 요구 사항 처리
  • 메시지가 대기열에 남아 있기 때문에 실패한 단계에서 쉽게 복구

SQS 대기열은 2가지 유형, 표준 대기열과 FIFO 대기열로 구분됩니다.

표준 대기열은 최소 1회 전송 및 최선의 정렬을 제공합니다.

FIFO 대기열은 메시지가 전송된 순서대로 정확히 한 번 처리될 수 있도록 설계되어 있습니다.

SQS 대기열을 사용하는 방법은 여러 가지가 있습니다.
작업 대기열: 동일한 양의 작업 일부를 동시에 처리하지 못할 수 있는 분산 애플리케이션의 구성 요소를 분리합니다.
배치 작업 버퍼링: 아키텍처에 확장성과 안정성을 더하고, 메시지를 손실하거나 지연 시간을 늘리지
않고 일시적인 볼륨 스파이크를 원활하게 처리합니다.

요청 오프로딩: 요청을 전송하여 대화식 요청 경로에서 속도가 느린 작업을 제거합니다.
Auto Scaling: Amazon SQS 대기열을 사용하면 애플리케이션의 로드를 결정하는 데 도움이 됩니다. 또한 Auto Scaling 과 결합 시 트래픽 볼륨에 따라 Amazon EC2 인스턴스의 수를 확장 또는 축소할 수 있습니다.

SQS 대기열을 도입하여 주문 애플리케이션을 개선하는 방법을 알아봅니다.
대기열을 사용하면 처리 로직를 자체 구성 요소로 분리된 후, 웹 애플리케이션과 별도로 구분된 프로세스에서 실행할 수 있습니다. 이를 통해 시스템은 트래픽 급증에 보다 탄력적으로 대처할 수 있으며 비용 관리를 위해 필요한만큼 신속하게 작업을 수행할 수 있습니다. 또한 주문을 메시지로 유지(임시 데이터베이스로 작동하는 대기열을 가지고)하기 위한 메커니즘을 갖추게 되었으며, 데이터베이스와의 트랜잭션의 범위를 스택 아래로
이동할 수 있습니다. 애플리케이션 예외 또는 트랜잭션 장애가 발생하면 SQS 대기열은 주문 처리를 중단하거나 Amazon SQS DLQ (Dead Letter Queue)로 리디렉션하여 나중에 다시 처리할 수 있습니다.

이 사용 사례에 관한 자세한 내용은 https://aws.amazon.com/blogs/compute/building-loosely-coupled-scalable-c-applications-with-amazon-sqs-and-amazon-sns 를 참조하십시오

Amazon SNS와 결합 해제

Amazon Simple Notification Service (Amazon SNS)는 클라우드에서 손쉽게 알림 기능을 설정, 작동 및 전송할 수
있는 웹 서비스입니다. 이 서비스는 “게시-구독”(pub-sub) 메시징 패러다임을 따르며 “푸시” 메커니즘을
사용하여 클라이언트에 알림을 전달합니다.

사용자는 주제(Topic)를 생성하고 어떤 게시자 및 구독자가 주제와 통신할 수 있는지를 결정하는 정책을 정의함으로써 주제에 대한 액세스를 제어합니다. 게시자는 자신이 생성한 주제 또는 게시할 권한이 있는 주제로 메시지를 보냅니다.
게시자는 각 메시지에 특정 대상 주소를 포함하는 대신 메시지를 해당 주제로 전송할 수 있습니다. Amazon SNS 는 주제와 해당 주제를 구독하는 구독자 목록을 일치시켜 각각의 구독자에게 메시지를 전송합니다.
각 주제는 Amazon SNS 엔드포인트를 식별하는 고유한 이름을 가지므로, 게시자는 메시지를 게시하고 구독자는 알림을 받도록 등록할 수 있습니다. 구독자는 구독하는 주제에 게시된 모든 메시지를 수신하며, 특정 주제를 구독하는 모든 구독자는 동일한 메시지를 수신합니다.
Amazon SNS 는 암호화된 주제를 지원합니다. 암호화된 주제에 메시지를 게시할 때 Amazon SNS 는 메시지를 암호화하기 위해 AWS KMS (https://aws.amazon.com/kms/)에서 제공하는 고객 마스터 키(CMK)를 사용합니다.
https://aws.amazon.com/blogs/compute/encrypting-messages-published-to-amazon-sns-with-aws-kms/

Amazon SNS 특징
• 각 알림 메시지에는 게시된 메시지 하나가 포함되어 있습니다.
• 메시지의 순서는 보장되지 않습니다.
• 메시지는 게시된 후에는 삭제될 수 없습니다.
• Amazon SNS 전송 정책을 사용하여 메시지 전송 실패 시 재시도를 제어할 수 있습니다.
• 메시지에는 XML, JSON, 서식 없는 텍스트 등의 텍스트 데이터를 최대 256KB 까지 담을 수 있습니다.

실습 S3 버킷에 이미지가 업로드 되면, SNS와 람다를 이용하여 이메일 알람 보내기

SNS - 주제 - 주제 생성



생성한 주제의 ARN을 복사하여 보관

구독 생성


후 구독생성

등록한 이메일 확인

Lambda로 이동 후 이전에 만들어놓은 CreateS3Thumbnail 함수에 다음 코드 복사 붙여넣기

message ="test message"
sns = boto3.client('sns')
sns.publish(
#아래 부분은 위에서 생성한 Topic 의 ARN 붙여넣기
TopicArn = "arn:aws:sns:ap-northeast-2:451111111:imageUploadTopic",
Message=message,
Subject="Image Upload Alert",
MessageStructure ="raw"
)


후 저장

권한으로 이동하여 Lambda-S3-ExcutionRole 클릭

정책 연결 클릭하여 AmazonSNSFullAccess 추가

이제 함수 TEST 버튼 클릭 OR S3 버킷에 이미지 업로드시 이메일이 도착하는지 확인한다.


잘 작동하는 것을 볼 수 있다.

0개의 댓글