[AWS] Cloud Watch: Amazon SNS + Lambda vs Lambda 단독 호출 비교

목차

---

1. 서론

저는 현재 Cloud Watch를 이용해 AWS 리소스 모니터링 환경을 구성하고 있습니다.

아래 그림은 제가 구성하려는 모니터링 아키텍처입니다.

AWS의 리소스들을 CloudWatch로 모니터링하고, 임계치가 넘으면 Cloud Watch 알람을 생성하며 이는 Amazon SNS에 게시됩니다. SNS에 주제가 게시되면 이를 구독하는 Lambda가 트리거되고, Lambda는 Slack을 통해 개발자에게 알림을 주는 구조입니다.

이렇게 구성한 이유는 이전에 AWS SAA 시험과 Cloud Watch 워크숍을 진행하며 Cloud Watch →  Amazon SNS →  Lambda 구조를 당연하게 생각했기 때문입니다.

 

이 아키텍처를 구성하던 중 CloudWatch 설정에서 아래 내용을 발견했습니다.

알림 메뉴에선 SNS에 Cloud Watch 경보를 게시할 Amazon SNS 주제를 선택할 수 있고, Lambda에선 Cloud Watch 경보 발생 시 호출할 Lambda 함수를 선택할 수 있습니다.

즉 제가 구상한 아키텍처에선 Cloud Watch → SNS → Lambda 순서지만, 굳이 SNS를 끼지 않아도 Cloud Watch → Lambda로 아키텍처를 간소화할 수 있습니다.

 

이번 포스팅에선 이 두 가지 경우를 비교해 보겠습니다: Cloud Watch → SNS → Lambda, Cloud Watch → Lambda

---

2. Amazon SNS features and capabilities

Amazon SNS를 사용하지 않는 경우의 장점은 당연히 아키텍처와 운영 복잡도를 간소화할 수 있다는 점일 것입니다.

그렇다면 Amazon  SNS를 사용하는 경우, 장점이 무엇일까요? 이를 알아보기 위해 우선 Amazon SNS의 특징과 capabilities를 알아보겠습니다.

(참고 문서: https://docs.aws.amazon.com/sns/latest/dg/welcome-features.html)

 

---

Amazon SNS offers a comprehensive set of features designed to enhance messaging between applications and users. These features enable seamless communication, secure message delivery, and robust message management, ensuring high availability, durability, and flexibility for a wide range of messaging use cases.

 

위 AWS 문서의 설명을 참고했을 때, SNS는 여러 엔드포인트에 대해 고가용성, 내구성, 유연함을 보장하며 application과 user 간 매끄럽고 안전한 통신을 가능하게 합니다.

 

저는 '여러 엔드포인트'와 '고가용성'에 집중했습니다.

왜냐하면 이 기능들은 Amazon SNS를 거치지 않는 Cloud Watch → Lambda 구조에서는 취할 수 없는 Amazon SNS만의 장점이기 때문입니다.

---

Amazon SNS endpoints

여기서 엔트포인트란 다음과 같습니다.

• 애플리케이션 간 메시징
  • Amazon Data Firehose, Lambda Functions, Amazon SQS 등
• 애플리케이션 - 사람 간 알림
  • 모바일 휴대폰 전화번호, 모바일 애플리케이션, 이메일 주소 등

따라서 Amazon SNS를 사용하면 Lambda 외 많은 앤드포인트들과 아키텍처를 통합할 수 있습니다.

---

Amazon SNS delivery retry policy

메시지의 고가용성은 'delivery retry policy'를 통해 보장합니다.

(참고 문서: https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html)

Amazon SNS defines a delivery policy for each delivery protocol. The delivery policy defines how Amazon SNS retries the delivery of messages when server-side errors occur (when the system that hosts the subscribed endpoint becomes unavailable). 

 

위 문서를 확인하면 Delivery policy stage가 있습니다.

Amazon SNS가 메시지 전송을 실패했을 때 어떤 단계로 메시지 재전송을 처리할 지 나타냅니다.

https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html

 

1단계: Immediate Retry Phase (No Delay) – 전송 시도 이후 즉시 발생합니다. 재시도 간 딜레이가 없습니다.

 

2단계: Pre-Backoff Phase – 1단계 이후 발생합니다. SNS는 이 단계를 backoff function을 적용하기 전에 시도하는 일련의 재시도(set of retries)로 사용합니다.  재시도할 횟수와 재시도 간의 딜레이를 설정합니다.

 

3단계: Backoff Phase – 이 단계에선 retry-backoff function을 사용해서 재시도 간 딜레이를 제어합니다. 최소 지연, 최대 지연, 그리고 지연이 최소 지연에서 최대 지연으로 얼마나 빠르게 증가하는지를 정의하는 retry-backoff function을.  설정합니다. 이 함수는 산수(arithmetic) 함수, 지수(exponential) 함수, 기하(geomtetric) 함수, 또는 선형(linear) 함수일 수 있습니다.

 

4단계: Post-Backoff Phase – 3단계 이후 발생합니다. 재시도 횟수와 재시도 간 딜레이를 설정합니다. 4단계가 마지막 단계입니다.

 

각 단계에 대해 재시도를 어떻게 시도할 지는 위 문서의 표에 자세히 기술되어 있습니다.

https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html

표를 확인해 보면 Lamba와 같은 AWS 관리형 서비스는 총 100,015번의 재시도를 요청합니다.

특히 Post-backoff phase에서 20초 딜레이로 100,000만 번의 전송을 요청하기 때문에 재전송은 최대 23일 동안 유지됩니다. 

 

AWS 관리 엔드포인트, Customer 관리 엔드포인트와 다르게 HTTP 엔드포인트의 경우 JSON을 각 단계의 재시도 횟수, 딜레이 등을 직접 지정할 수 있습니다.  이 문서를 참고해주세요.

 

CloudWatch와 Lambda를 바로 통합하면 Lambda를 한 번만 트리거합니다. 따라서 만약 트리거에 실패할 경우 

---

3. 최종 선택

Amazon SNS를 사용할 경우 장점과 단점은 다음과 같습니다.

• 장점: 여러 엔드포인트 사용 가능, 고가용성의 알람 전송
• 단점: (SNS를 사용하지 않는 경우보다) 관리할 게 하나 늘어남

저는 최종적으로 Amazon SNS를 사용하여 Cloud Watch →  Amazon SNS →  Lambda 구조를 채택했습니다.

그 이유는 다음과 같습니다.

1. 당장은 Lambda만 사용하므로 여러 엔드포인트를 사용하진 않지만, 아키텍처는 요구사항 에따라 언제든  바뀔 수 있습니다. 따라서 확장성이 좋은 SNS를 사용하는 것이 유리합니다.
2. 고가용성의 알람 전송: Amazon SNS를 사용하면 23일 동안 10만 번의 재시도를 합니다. SNS를 사용하지 않을 경우 재시도는 두 번만 발생하는 것을 고려했을 때 가용성의 차이는 아주 큽니다.
   (참고 문서: "Lambda retries function errors twice.", https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)
3. 큰 장점에 비해 아주 작은 단점: Amazon SNS를 사용할 경우 위의 확장성과 고가용성을 확보할 수 있습니다. Amazon SNS는 완전 관리형 서비스이기 때문에 관리가 거의 필요하지 않으며, 요금도 요청 100만 건 당 0.5 달러로, 아주 저렴합니다.