<div id="readability-page-1" class="page"><div><div><figure></figure><p id="7aff">안녕하세요, 직방 BE Platform 팀에서 근무 중인 Kevin 입니다.</p><p id="bf6f">BE Platform 팀의 중요한 업무 중 하나는 푸시알림 서비스를 관리하는 것인데요, 오늘은 이 푸시알림 서비스를 운영하면서 겪게된 오류에 대해서 이야기 해보려고 합니다.</p><p id="c405">직방 푸시알림 서비스는 Amazon SQS를 사용하여 개발 되었는데요, 이 글은 SQS를 도입한 시스템에서 SQS가 단일실패지점이 되어 서비스가 중단되었던 경험을 공유하기 위한 것입니다.</p></div><div><p id="87fb">들어가기에 앞서 SQS는 무엇인지, 단일실패지점은 무엇인지 간략하게 알아보겠습니다.</p><p id="84ee"><strong>Amazon SQS(Simple Queue Service)</strong></p><p id="5fb6">AWS를 사용하는 개발자라면 SQS에 대해 한번쯤 들어봤을 것입니다.</p><p id="2713">SQS와 같은 메시지 큐는 MSA(MicroService Architecture)를 보완하는 EDM(Event Driven MicroService)에서 마이크로서비스를 느슨하게 연결(Loosely-coupled)하여 의존성을 제거하는 역할을 합니다.</p><p id="9ef8">SQS는 완전관리형 서비스가 주는 편리함 덕분에 비교적 작은 메시지 크기와 인플라이트 메시지 수의 한계에도 불구하고 마이크로서비스 모범 사례에 자주 등장하고 있습니다.</p><p id="b664"><strong>단일실패지점(single point of failure, SPOF)</strong></p><p id="dccd">시스템 구성 요소 중 동작하지 않으면 전체 시스템이 중단되는 요소를 말하는 것으로 고가용성 시스템을 위해서는 반드시 제거되어야 할 대상입니다.</p></div><div><p id="c960"><strong>그렇다면 ‘Amazon SQS에 숨겨진 단일실패지점’이란 무엇일까요?</strong></p><p id="5267">직방에서는 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할로 SQS를 사용하고 있으며, 푸시알림 서비스의 여러 가지 기술적 요구사항을 SQS에서 제공하는 기능을 통해 해결하고 있습니다.</p><p id="f9da">이 글에서 공유하고자 하는 서비스중단 사례는 SQS가 제공하는 기능 중 FIFO Queue를 사용하는 경우 발생할 수 있는데요, 먼저 SQS가 제공하는 2가지 Queue 타입에 대해 알아보겠습니다.</p></div><div><p id="0ca2"><strong>SQS가 제공하는 2가지 Queue 타입</strong></p><ol><li id="ef7c">Standard Queue</li></ol><ul><li id="0850">적어도 한번(at-least-once) 전송</li><li id="02bb">순서가 뒤바뀔수 있음</li><li id="3bd5">멱등성(idempotent)을 가지는 서비스에 사용</li><li id="c11e">High Throughput</li></ul><p id="6065">2. FIFO Queue</p><ul><li id="8b45">정확히 한번(exactly-once) 전송</li><li id="a87f">순서가 중요하고 중복이 허용되지 않는 경우 사용</li><li id="cdf8">Limited Throughput : 300 TPS</li></ul><figure><figcaption><strong>출처 : https://devocean.sk.com/blog/techBoardDetail.do?ID=163290</strong></figcaption></figure><p id="ca09">직방 푸시알림 서비스는 중복전송방지 및 순서보장이 중요하기 때문에 FIFO Queue를 사용하고 있습니다.</p><p id="2893">다음은 어떤 경우에 FIFO Queue가 단일실패지점이 되어 서비스가 중단될 수 있는지 알아보겠습니다.</p></div><div><p id="8337"><strong>FIFO Queue가 메시지를 처리하는 규칙</strong>은 다음과 같습니다.</p><ul><li id="cec2">큐에 모든 메시지는 메시지그룹 ID를 가지며 이 메시지그룹을 기준으로 정렬되어 순서대로 처리 됩니다.</li><li id="c9aa">큐에서 수신한 메시지를 처리한 후 삭제하지 않으면 동일한 메시지그룹의 다른 메시지를 수신할 수 없습니다.</li></ul><p id="f639">위 내용에 대한 상세한 설명은 아래 AWS 공식문서 링크에 있습니다.</p><p id="195d">직방 푸시알림 서비스에서 MessageConsumer는 아래 4단계를 거쳐서 푸시알림을 전송합니다.</p><ol><li id="54f8">receiveMessage : Queue 메시지 수신</li><li id="20eb">parseMessage : 수신 메시지 JSON 파싱</li><li id="40c1">deleteMessage : Queue 메시지 삭제</li><li id="0d71">sendMessage : 푸시알림 전송</li></ol><p id="c113">메시지처리 과정에서 <strong>SQS FIFO Queue가 단일실패지점이 되어 푸시알림 전송이 중단되는 구체적인 시나리오</strong>는 다음과 같습니다.</p><ol><li id="7dcf">MessageProducer가 잘못된 문법의 JSON 데이터를 담은 메시지를 큐에 전송합니다.</li><li id="7b22">MessageConsumer가 큐 메시지를 수신합니다.</li><li id="a969">parseMessage 단계에서 JSON 파싱에 실패하여 SyntaxError를 던지고 작업을 종료합니다.</li><li id="5002">deleteMessage 단계를 거치지 않았으므로 잘못된 메시지가 큐에 그대로 남아 있습니다.</li><li id="ca19">MessageConsumer는 또다시 같은 메시지를 수신하여 2–4번 과정을 반복합니다.</li><li id="0dc4">하나의 잘못된 메시지로 인해 푸시알림 전송은 중단되고 큐에 메시지는 계속해서 쌓여만 갑니다.</li></ol></div><div><p id="f687"><strong>어디서 부터 잘못되었을까요?</strong></p><p id="13a8">혹자는 parseMessage 단계에서 <strong>예외처리를 누락한 구현단계의 문제</strong>라고 할 수 있습니다. 예외가 발생하면 잡아서 deleteMessage 단계를 거치도록 하면 다음 메시지를 처리할 수 있습니다.</p><ul><li id="3dbc">하지만 모든 예외에 대해 일괄적으로 큐의 메시지를 바로 삭제하면 안됩니다. 예외의 종류에 따라 큐에 남겨두어 재 시도되도록 해야 하는 경우도 있습니다. <strong>처음부터 삭제 되어야 할 모든 예외 케이스를 미리 알고 대처하기는 쉽지 않습니다.</strong></li></ul><p id="462c">또는 <strong>메시지그룹을 여러 개로 분리하지 않은 설계단계의 문제</strong>라고 할 수 있습니다. 메시지 종류에 따라 메시지그룹을 분리하면 문제가 발생하지 않은 다른 그룹에 속한 메시지는 처리할 수 있습니다.</p><ul><li id="a4e0">하지만 <strong>하나의 그룹으로 묶어 처리순서를 지켜야 할 메시지들을 구분하는 것은 쉽지 않습니다.</strong> 비즈니스 로직에 대한 높은 이해도가 필요한 작업이며 처음에 메시지 그룹을 잘 분리했다 하더라도 요구사항이 변경되면 같은 그룹으로 묶여야 할 조건도 바뀌기 마련입니다.</li></ul></div><div><p id="c946"><strong>마치며</strong></p><p id="45b7">처음부터 완벽할 수는 없습니다. 실패를 통해 배우고 얻게된 경험을 공유하여 함께 성장하는 것이 중요하다고 생각합니다.</p><p id="c528">이 글이 Amazon SQS를 도입하여 고가용성 시스템을 빠르게 구축 하려는 분들에게 조금이나마 도움이 되었으면 합니다.</p><p id="1e37">문제를 해결하기 위한 방법은 여러 가지가 있습니다. 더 나은 방법을 찾게되면 다음 글로 다시 돌아오겠습니다.</p><p id="43d2">긴 글 읽어주셔서 감사합니다.</p></div></div></div>

zigbang - Medium

안녕하세요, 직방 BE Platform 팀에서 근무 중인 Kevin 입니다.
BE Platform 팀의 중요한 업무 중 하나는 푸시알림 서비스를 관리하는 것인데요, 오늘은 이 푸시알림 서비스를 운영하면서 겪게된 오류에 대해서 이야기 해보려고 합니다.
직방 푸시알림 서비스는 Amazon SQS를 사용하여 개발 되었는데요, 이 글은 SQS를 도입한 시스템에서 SQS가 단일실패지점이 되어 서비스가 중단되었던 경험을 공유하기 위한 것입니다.
들어가기에 앞서 SQS는 무엇인지, 단일실패지점은 무엇인지 간략하게 알아보겠습니다.
Amazon SQS(Simple Queue Service)
AWS를 사용하는 개발자라면 SQS에 대해 한번쯤 들어봤을 것입니다.
SQS와 같은 메시지 큐는 MSA(MicroService Architecture)를 보완하는 EDM(Event Driven MicroService)에서 마이크로서비스를 느슨하게 연결(Loosely-coupled)하여 의존성을 제거하는 역할을 합니다.
SQS는 완전관리형 서비스가 주는 편리함 덕분에 비교적 작은 메시지 크기와 인플라이트 메시지 수의 한계에도 불구하고 마이크로서비스 모범 사례에 자주 등장하고 있습니다.
단일실패지점(single point of failure, SPOF)
시스템 구성 요소 중 동작하지 않으면 전체 시스템이 중단되는 요소를 말하는 것으로 고가용성 시스템을 위해서는 반드시 제거되어야 할 대상입니다.
그렇다면 ‘Amazon SQS에 숨겨진 단일실패지점’이란 무엇일까요?
직방에서는 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할로 SQS를 사용하고 있으며, 푸시알림 서비스의 여러 가지 기술적 요구사항을 SQS에서 제공하는 기능을 통해 해결하고 있습니다.
이 글에서 공유하고자 하는 서비스중단 사례는 SQS가 제공하는 기능 중 FIFO Queue를 사용하는 경우 발생할 수 있는데요, 먼저 SQS가 제공하는 2가지 Queue 타입에 대해 알아보겠습니다.
SQS가 제공하는 2가지 Queue 타입
Standard Queue
적어도 한번(at-least-once) 전송
순서가 뒤바뀔수 있음
멱등성(idempotent)을 가지는 서비스에 사용
High Throughput
2. FIFO Queue
정확히 한번(exactly-once) 전송
순서가 중요하고 중복이 허용되지 않는 경우 사용
Limited Throughput : 300 TPS
직방 푸시알림 서비스는 중복전송방지 및 순서보장이 중요하기 때문에 FIFO Queue를 사용하고 있습니다.
다음은 어떤 경우에 FIFO Queue가 단일실패지점이 되어 서비스가 중단될 수 있는지 알아보겠습니다.
FIFO Queue가 메시지를 처리하는 규칙은 다음과 같습니다.
큐에 모든 메시지는 메시지그룹 ID를 가지며 이 메시지그룹을 기준으로 정렬되어 순서대로 처리 됩니다.
큐에서 수신한 메시지를 처리한 후 삭제하지 않으면 동일한 메시지그룹의 다른 메시지를 수신할 수 없습니다.
위 내용에 대한 상세한 설명은 아래 AWS 공식문서 링크에 있습니다.
Message ordering
FIFO delivery logic
직방 푸시알림 서비스에서 MessageConsumer는 아래 4단계를 거쳐서 푸시알림을 전송합니다.
receiveMessage : Queue 메시지 수신
parseMessage : 수신 메시지 JSON 파싱
deleteMessage : Queue 메시지 삭제
sendMessage : 푸시알림 전송
메시지처리 과정에서 SQS FIFO Queue가 단일실패지점이 되어 푸시알림 전송이 중단되는 구체적인 시나리오는 다음과 같습니다.
MessageProducer가 잘못된 문법의 JSON 데이터를 담은 메시지를 큐에 전송합니다.
MessageConsumer가 큐 메시지를 수신합니다.
parseMessage 단계에서 JSON 파싱에 실패하여 SyntaxError를 던지고 작업을 종료합니다.
deleteMessage 단계를 거치지 않았으므로 잘못된 메시지가 큐에 그대로 남아 있습니다.
MessageConsumer는 또다시 같은 메시지를 수신하여 2–4번 과정을 반복합니다.
하나의 잘못된 메시지로 인해 푸시알림 전송은 중단되고 큐에 메시지는 계속해서 쌓여만 갑니다.
어디서 부터 잘못되었을까요?
혹자는 parseMessage 단계에서 예외처리를 누락한 구현단계의 문제라고 할 수 있습니다. 예외가 발생하면 잡아서 deleteMessage 단계를 거치도록 하면 다음 메시지를 처리할 수 있습니다.
하지만 모든 예외에 대해 일괄적으로 큐의 메시지를 바로 삭제하면 안됩니다. 예외의 종류에 따라 큐에 남겨두어 재 시도되도록 해야 하는 경우도 있습니다. 처음부터 삭제 되어야 할 모든 예외 케이스를 미리 알고 대처하기는 쉽지 않습니다.
또는 메시지그룹을 여러 개로 분리하지 않은 설계단계의 문제라고 할 수 있습니다. 메시지 종류에 따라 메시지그룹을 분리하면 문제가 발생하지 않은 다른 그룹에 속한 메시지는 처리할 수 있습니다.
하지만 하나의 그룹으로 묶어 처리순서를 지켜야 할 메시지들을 구분하는 것은 쉽지 않습니다. 비즈니스 로직에 대한 높은 이해도가 필요한 작업이며 처음에 메시지 그룹을 잘 분리했다 하더라도 요구사항이 변경되면 같은 그룹으로 묶여야 할 조건도 바뀌기 마련입니다.
마치며
처음부터 완벽할 수는 없습니다. 실패를 통해 배우고 얻게된 경험을 공유하여 함께 성장하는 것이 중요하다고 생각합니다.
이 글이 Amazon SQS를 도입하여 고가용성 시스템을 빠르게 구축 하려는 분들에게 조금이나마 도움이 되었으면 합니다.
문제를 해결하기 위한 방법은 여러 가지가 있습니다. 더 나은 방법을 찾게되면 다음 글로 다시 돌아오겠습니다.
긴 글 읽어주셔서 감사합니다.
Amazon SQS에 숨겨진 단일실패지점 was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Amazon SQS에 숨겨진 단일실패지점

댓글