SNS 팬아웃 구조와 DLQ

About this offer

SNS를 정리하면서 하나의 메시지를 여러 구독자에게 동시에 전달하는 팬아웃(fan-out) 구조를 다뤘는데 구독자가 여러 개로 늘어났을 때 그중 하나가 계속 메시지를 받지 못하는 상황은 어떻게 처리되는지는 짚지 않았다. 이번 글에서는 SNS 구독자 중 일부가 실패했을 때 발생하는 문제와 DLQ(Dead Letter Queue)가 왜 필요한지 정리한다. SNS는 구독자마다 독립적으로 메시지를 전달한다 SNS는 하나의 주제(Topic)에 메시지를 발행하면 그 주제를 구독하고 있는 모든 엔드포인트(Lambda, SQS, 이메일 등)로 각각 전달한다. 이때 구독자 각각에 대한 전달은 서로 독립적으로 이루어진다. 즉 구독자 A에게 전달이 실패했다고 해서 구독자 B, C로의 전달이 함께 실패하는 것은 아니다. Publisher ──▶ SNS Topic ──▶ 구독자 A (성공) ├─▶ 구독자 B (실패 → 재시도) └─▶ 구독자 C (성공) 실패한 구독자는 어떻게 되는가 전달에 실패한 구독자에 대해서는 SNS가 일정 정책에 따라 재시도를 수행한다. 하지만 재시도 횟수에는 한계가 있고, 그 한계를 넘어서도 계속 실패하는 경우 해당 메시지는 결국 폐기될 수 있다. 예를 들어 구독하고 있는 Lambda 함수에 일시적인 오류가 있거나 처리량 한도를 초과해 지속적으로 실패를 반환하는 상황이라면 그 메시지는 재시도가 끝난 뒤 아무 기록 없이 사라질 수 있다는 뜻이다. 저번에 정리했던 CloudWatch → SNS → Lambda → Slack 흐름을 생각해보면 만약 Slack 웹훅 호출을 담당하는 Lambda 함수가 일시적으로 오류를 내고 있었다면 그 사이에 발생한 알림 메시지들이 재시도 끝에 조용히 유실될 수 있었다는 것이 된다. 알림이 오지 않았다는 사실 자체도 알아차리기 어려운 상황이 되는 것이다. DLQ가 필요한 이유 이런 메시지 유실을 막기 위해 사용하는 것이 DLQ(Dead Letter Queue)다. 재시도가 모두 실패한 메시지를 그냥 폐기하는 대신에 별도로 지정한 큐(DLQ)로 보내서 보관하는 방식이다. SNS ──▶ 구독자(Lambda) ──재시도 모두 실패──▶ DLQ(SQS 큐)에 보관 └─▶ 이후 별도 확인·재처리 가능 DLQ에 쌓인 메시지를 통해 어떤 메시지가, 언제, 왜 전달에 실패했는지 사후에 확인할 수 있고 필요하다면 원인을 해결한 뒤 재처리할 수도 있다. 즉 DLQ는 실패를 막아주는 장치가 아니라 실패했다는 사실 자체를 조용히 사라지지 않게 남겨두는 장치 에 가깝다. 정리 SNS의 팬아웃 구조는 구독자마다 독립적으로 전달이 이루어지기 때문에 특정 구독자 하나의 장애가 전체 알림 흐름을 막지는 않는다. 다만 그 구독자로의 전달이 재시도 끝에 실패하면 메시지가 유실될 수 있고 알림 시스템에서는 이 유실 자체를 인지하기 어렵다는 문제가 있다. DLQ를 구성해두면 이런 실패 메시지를 남겨서 사후에 확인하고 대응할 수 있다.

Offer details

Provider

velog

Source

velog-rss

Score

54.39

Confidence

49%