알림 시스템 설계 면접 퀴즈

알림 시스템은 여러 서비스가 함께 쓰는 플랫폼입니다. 그래서 한 서비스의 발송이 다른 서비스의 알림을 밀어내는 것이 이 설계의 중심 문제입니다.

기능 요구사항과 범위 밖

발송 대상 추출을 뺀 것이 중요합니다. "30일 미접속 사용자에게" 같은 조건으로 대상을 뽑는 일은 각 서비스가 합니다. 우리는 받는 사람 목록과 내용을 받아 보내는 일만 합니다.

경계를 이렇게 그으면 우리 시스템이 사용자 데이터베이스를 알 필요가 없습니다.

평균과 피크가 17배 다르다

하루 5천만 건 은 평균 초당 578건입니다. 그런데 마케팅 발송이 시작되면 피크 초당 1만 이 됩니다.

폭주하는 쪽이 급하지 않은 알림이라는 것이 핵심입니다. 비밀번호 재설정 알림이 마케팅 100만 건 뒤에 줄을 서면 1분 안에 도착이라는 요구를 어깁니다.

그래서 급한 것과 급하지 않은 것을 같은 줄에 세우지 않습니다. 이 판단이 뒤의 큐 구조를 정합니다.

숫자가 정하는 것

채널마다 성질이 다르다

한 시스템으로 세 채널을 다루지만 성질이 크게 다릅니다.

같은 알림을 세 채널로 보내는 것이 기본이 아닙니다. 문자는 비싸고, 세 곳에서 같은 알림을 받으면 사용자가 짜증을 냅니다. 어느 채널로 보낼지가 판단입니다.

수신 거부를 요구사항에 못 박는다

수신 거부는 우리가 정하는 정책이 아닙니다. 마케팅 알림에는 법적 요구가 걸려 있고, 어기면 서비스 전체가 위험해집니다.

그래서 발송 직전에 확인합니다. 대상 목록을 만든 시점과 실제 발송 시점 사이에 사용자가 거부했을 수 있습니다. 목록이 클수록 그 시차가 커집니다.

알림 시스템의 특이한 점은 마지막 단계가 우리 것이 아니라는 것입니다. 푸시는 운영체제 제공자를, 문자는 통신사 쪽을, 메일은 메일 발송 서비스를 거칩니다.

통제가 끝나는 지점

우리가 할 수 있는 것은 제공자에게 넘기는 것까지입니다. 그 뒤는 볼 수 없고 바꿀 수 없습니다.

이 경계를 인정하는 것이 설계의 출발점입니다. 도착을 보장하려 하지 말고, 넘기는 것까지를 확실하게 만들고 그 뒤는 관찰합니다.

채널마다 다른 것을 한 겹으로 감싼다

제공자마다 요청 형식과 인증 방식과 오류 코드가 다릅니다. 그것이 우리 코드 전체에 퍼지면 제공자를 바꿀 때 모든 곳을 고쳐야 합니다.

우리 코드는 "이 사람에게 이 알림을 보낸다" 만 말한다
겹 하나가 제공자 차이를 흡수한다

제공자를 바꿀 때 우리 코드가 바뀌지 않아야 합니다. 문자 제공자는 실제로 바뀝니다. 가격과 도달률 때문에 옮기는 일이 흔합니다.

제공자가 우리를 제한한다

제공자에게도 속도 제한이 있습니다. 피크 초당 1만 을 그대로 밀면 거절당합니다.

처리율 제한 설계에서 우리가 만든 장치를 이번에는 우리가 지키는 쪽입니다. 상대가 알려 주는 재시도 시각을 따르고, 지키지 않으면 차단됩니다.

한 채널의 장애가 다른 채널을 막지 않게

문자 제공자가 느려지면 그 발송이 쌓입니다. 같은 일꾼과 같은 큐를 쓰면 푸시 알림도 함께 멈춥니다.

그래서 채널마다 큐와 일꾼을 나눕니다. 크롤러에서 호스트별로 큐를 나눈 것과 같은 구조이고, 이유도 같습니다. 한 곳의 느림이 다른 곳으로 번지지 않게 하는 것입니다.

제공자의 응답을 어떻게 읽나

제공자가 200을 주면 "받았다" 입니다. "도착했다" 가 아닙니다. 이 구분을 흐리면 도달률 지표가 실제와 크게 달라집니다.

세 가지를 구분해 기록해야 무엇이 잘못됐는지 알 수 있습니다. 도달 추적은 뒤에서 따로 다룹니다.

피크 초당 1만 이 몰릴 때 1분 안에 도착해야 하는 알림이 함께 있습니다. 두 요구를 같은 줄에서 만족시킬 수 없습니다.

한 줄이면 뒤에 선 것이 늦는다

마케팅 100만 건이 큐에 들어가고 그 뒤에 비밀번호 재설정 알림이 붙으면, 앞의 100만 건을 처리한 뒤에야 나갑니다. 초당 1만이라도 100초가 걸립니다.

그래서 줄을 나눕니다. 급한 줄과 대량 발송 줄을 따로 두고 일꾼을 배정합니다.

급한 줄은 양이 적어서 늘 비어 있다
그 비어 있음이 1분을 지켜 준다

몇 개로 나누나

셋이 흔한 선택입니다. 더 나누면 관리가 늘고, 둘로 줄이면 보통 알림이 대량 발송에 밀립니다.

보내는 서비스가 종류를 정합니다. 그런데 모두가 자기 알림을 급한 것으로 표시하려 하므로, 급한 줄에 넣을 수 있는 종류를 목록으로 관리해야 합니다. 아니면 급한 줄도 곧 막힙니다.

대량 발송을 일부러 늦춘다

대량 발송은 지연이 허용됩니다. 그래서 일부러 천천히 보냅니다.

세 번째가 특히 중요합니다. 100만 명에게 동시에 알리면 그 앱과 서버가 동시 접속을 받습니다. 알림 시스템이 상대 서비스를 무너뜨리는 셈입니다.

취소할 수 있어야 한다

대량 발송은 시작한 뒤 잘못된 것을 알게 되는 일이 흔합니다. 내용이 틀렸거나 대상이 잘못됐을 때입니다.

큐에 다 넣고 시작하면 취소할 방법이 없다
발송 작업을 하나의 단위로 두고 중단 가능하게 만든다

천천히 보내는 것이 취소 가능성을 만듭니다. 한꺼번에 밀어 넣으면 이미 나간 것을 되돌릴 수 없습니다. 두 이유가 같은 결론을 가리킵니다.

급한 줄이 막히면 무엇을 하나

급한 줄도 막힐 수 있습니다. 제공자 장애나 갑작스러운 인증 요청 폭증 때입니다.

이때는 대량 발송을 멈추고 자원을 급한 줄로 옮깁니다. 대량 발송은 지연이 허용되므로 멈춰도 됩니다. 우선순위가 있다는 것은 급할 때 무엇을 버릴지 정해 두었다는 뜻입니다.

버릴 것을 정해 두지 않은 우선순위는 이름만 있는 것입니다.