앱에서 이메일이 발송되지 않는 이유는 무엇인가요

내 로그가 아니라 업체의 로그를 먼저 본다

이 장애에서 헷갈리는 부분은 아무것도 고장 나 보이지 않는다는 점입니다. 코드는 돌았고, 발송 함수는 반환했고, 예외도 없었고, 내 로그에는 메일이 나갔다고 남아 있습니다. 애플리케이션 로그는 내 코드가 무엇을 하기로 결정했는지를 기록하고, 업체의 로그는 그 메일에 실제로 무슨 일이 있었는지를 기록하기 때문입니다. 둘이 어긋나면 업체가 맞습니다. 업체의 활동 화면을 열고 발송이 멈춘 구간으로 필터링하십시오. 보통 특정 시각 이후가 침묵이거나, 사유가 붙은 거절이 줄지어 있습니다. 앞은 내 코드가 호출을 멈췄다는 뜻이고, 뒤는 호출했는데 거절당했다는 뜻입니다.

코드를 바꾸기 전에, API 키를 교체하기 전에, 무언가를 재발송하기 전에 그것부터 하십시오. 하나같이 진단을 어렵게 만들고, 그중 하나는 문제를 악화시킵니다. 이미 발송량으로 표시가 붙은 계정에 재발송을 몰아치는 것은 일시적인 중지를 영구적인 중지로 바꾸는 전형적인 방법입니다.

발송을 실제로 멈추는 네 가지

답이 되는 빈도가 높은 순서로 대략 이렇습니다.

• 성장해서 닿게 된 요금제 한도 일간·월간 발송 상한이 가장 흔한 원인이자 가장 억울하게 느껴지는 원인입니다. 시스템은 아무것도 바뀌지 않았고, 바뀐 것은 가입자 수이기 때문입니다. 한도는 여느 화요일과 똑같은 화요일 아침에 넘어가고, 버려지는 것은 가장 늦게 대기열에 들어간 것, 대개 아침에 나가는 로그인 메일이 아니라 알림과 라이프사이클 메일입니다.
• 업체의 일시 중지 업체는 발송량의 급격한 변화, 임계치를 넘는 하드 바운스율, 스팸 신고를 이유로 계정을 멈춥니다. 이 경우는 보통 경고 메일이 오지만, 수신처는 계정을 만들 때 등록된 주소이고, 작은 팀에서는 이미 아무의 받은편지함도 아닌 경우가 많습니다.
• 깨진 도메인 인증 SPF, DKIM, DMARC 레코드는 DNS에 있으므로 DNS가 바뀌면 깨집니다. 등록기관 이전, 추가가 아니라 대체가 되어 버린 레코드, 만료된 검증, 교체된 서명 키. 이것은 멈추기 전에 나빠집니다. 먼저 특정 메일 서비스로의 전달이 실패하고, 다음으로 반송률이 오르고, 그다음에 중지가 옵니다.
• 내 코드가 호출을 멈췄다 한 환경에만 빠진 환경 변수, 조용히 죽은 큐 워커, 배포 후 꺼진 채로 남은 기능 플래그, 필수 필드가 바뀐 SDK 업데이트. 업체 로그가 거절이 아니라 침묵을 보여 준다면 이쪽 가지이고, 답은 업체 대시보드가 아니라 내 배포 이력에 있습니다.

상태 코드가 아니라 본문을 읽는다

10분이면 끝날 장애를 사흘짜리로 만드는 것이 이것이고, 우리도 자체 시스템에서 같은 실수를 한 번 이상 했습니다. 거절된 호출은 반드시 오류로 도착하지 않습니다. HTTP 200의 응답 본문 안에 실패가 담겨 도착하고, 상태 코드만 확인하는 코드는 그것을 성공으로 기록합니다. 서로 다른 여러 업체에서 정확히 같은 형태를 겪었습니다. 어떤 업체는 토큰에 권한이 없을 때 200 본문에 거짓 성공 플래그를 담아 응답합니다. 다른 업체는 소셜 게시물을 받아들인 뒤 본문에 검증 실패를 담아 응답했고, 봉투만 읽던 우리 시스템은 그 게시물을 발행된 것으로 기록하고 고객에게도 그렇게 알렸습니다. 실제로는 아무것도 게시되지 않았습니다.

거기서 나온 규칙은 짧고, 이메일에도 그대로 적용됩니다. 응답 본문이 업체가 수락했다고 말할 때에만 발송을 성공으로 간주하고, 수락하지 않았을 때는 업체 자신의 사유 문자열을 기록하고, 내가 요약한 문구가 아니라 그 문자열에 대해 경보를 울리십시오. 상태 줄은 API와의 대화를 설명합니다. 본문은 이메일을 설명합니다.

같은 원칙이 속도 제한에도 적용됩니다. 429를 반환하는 업체는 유용하고 일시적인 정보를 전하고 있습니다. 백오프가 없는 코드는 그것을 영구적인 손실로 바꿉니다. 메시지가 버려지고 다시는 재시도되지 않기 때문입니다. 우리도 그 백오프 없이 필요 이상으로 오래 달렸고, 결국 문제를 드러낸 것은 경보가 아니었습니다. 누군가 들여다보러 간 일이었습니다.

다음 번에는 시끄럽게 만들기

의미 있는 조치는 한도를 올리는 것이 아니라 닿기 전에 알아차리는 것이고, 경보는 건수가 아니라 비율에 걸어야 합니다. 「오늘 할당량의 80%를 오후 2시에 썼습니다」는 행동으로 이어지지만, 「100통 보냈습니다」는 요금제가 바뀌는 순간 아무 의미도 없어집니다. 우리 발송량도 가입자가 늘면서 하루 100통을 넘었습니다. 무료 요금제의 상한이 정확히 100통이었습니다. 마침내 들여다본 날 약 107통이었고, 그 주 앞부분에는 100분의 99까지 가 있었습니다. 시스템의 어느 부분도 한마디 하지 않았습니다. 요금제 상향은 쉬운 절반이었습니다. 우리가 여전히 스스로에게 빚지고 있던 경보가 중요한 절반이었고, 그것이 없었던 이유는 상한이 한 번도 가까웠던 적이 없어 아무도 그것을 움직이는 숫자로 생각해 본 적이 없었기 때문입니다.

온 김에 해 둘 만한 것이 두 가지 더 있습니다. 로그인을 실어 나르는 메일이 도착하지 않을 때를 대비해 계정으로 들어가는 두 번째 문을 남겨 두십시오. 이유는 매직 링크 로그인이 실패하는 이유에 적어 두었습니다. 그리고 로그인이나 영수증을 실어 나르는 메일과 캠페인을 실어 나르는 메일을 분리하십시오. 최소한 발송 도메인으로, 가능하면 업체 단위로 나눕니다. 그래야 신고 임계치를 건드린 마케팅 발송이 비밀번호 재설정까지 함께 무너뜨리지 못합니다. 각 흐름에 무엇이 속하는지는 라이프사이클 이메일 구성하기에서 다룹니다. agentceres.com의 AI Growth Officer인 AgentCeres를 만들면서 우선순위를 비싼 수업료로 배웠습니다. 고객이 실제로 요청한 메시지가 가장 먼저 지켜야 할 것입니다.