Braze는 고객을 대신하여 하루에 수십억 개의 이벤트를 처리하여 최종 사용자에게 수십억 개의 매우 집중된 개인화된 메시지를 보냅니다. 이러한 메시지 중 하나를 보내지 못하면 영수증을 놓쳤거나 사용자에게 음식이 준비되었음을 알리는 알림을 놓친 것과 같은 결과가 발생합니다. 이러한 주요 메시지가 항상 정확하고 항상 정시에 있는지 확인하기 위해 Braze는 작업 대기열을 활용하는 방법에 대한 전략적 접근 방식을 취합니다.

작업 대기열이란 무엇입니까?

일반적인 작업 대기열은 프로세스가 계산 작업을 대기열에 제출하고 다른 프로세스가 실제로 작업을 실행하는 아키텍처 패턴입니다. 이것은 일반적으로 좋은 것입니다. 올바르게 사용하면 기존의 요청-응답 패러다임에서는 얻을 수 없는 정도의 동시성, 확장성 및 중복성을 제공합니다. 많은 작업자가 최대 동시성을 위해 여러 프로세스, 여러 컴퓨터 또는 여러 데이터 센터에서 동시에 다른 작업을 실행할 수 있습니다. 특정 대기열에서 작업하도록 특정 작업자 노드를 할당하고 특정 대기열에 특정 작업을 보내 필요에 따라 리소스를 확장할 수 있습니다. 작업자 프로세스가 충돌하거나 데이터 센터가 오프라인 상태가 되면 다른 작업자가 나머지 작업을 실행할 수 있습니다.

이러한 원칙을 확실히 적용하고 소규모로 작업 대기열 시스템을 쉽게 실행할 수 있지만 수십억 개의 작업을 처리할 때 이음새가 나타나기 시작합니다(심지어 터지기까지). 하루에 수천 개의 작업에서 수백만 개의 작업으로, 이제는 수십억 개의 작업을 처리하면서 Braze가 직면한 몇 가지 문제를 살펴보겠습니다.

일관성 부족은 약점이다

메시지를 보냈지만 방금 메시지를 보냈다는 사실을 기록하기 전에 충돌이 발생하면 어떻게 됩니까?

여기서 몇 가지 다른 나쁜 결과가 발생할 수 있습니다. 먼저 실패한 작업을 다시 예약하고 메시지를 다시 보낼 수 있습니다. 그것은...이상적이지 않습니다. 아무도 같은 것을 두 번 받고 싶어하지 않습니다. 대신 일정을 전혀 조정하지 않는 것이 좋습니다. 이 경우 내부 회계가 올바르지 않으므로 어트리뷰션, 전환 및 기타 모든 것이 올바르게 진행되지 않을 것입니다.

어떻게 수정합니까? 작업 정의를 작성할 때 멱등성과 재시도 동작에 대해 정말 열심히 생각합니다.

대기열에 대해 이야기할 때 멱등성은 단일 작업이 임의의 지점에서 종료될 수 있고 다시 대기열에 있는 작업이 완전히 다시 실행되며 최종 결과는 정확히 하나의 작업을 성공적으로 실행한 것과 동일함을 의미합니다. 시각. 이것은 우리가 선택한 재시도 동작(최소한 한 번 전달)과 밀접하게 관련되어 있습니다. 모든 작업이 적어도 한 번, 어쩌면 여러 번 실행될 것이라는 점을 염두에 두면 임의의 오류에도 불구하고 일관성을 보장하는 멱등성 작업 정의를 작성할 수 있습니다.

메시지 전송 예제로 돌아가서 일관성을 보장하기 위해 이러한 개념을 어떻게 사용할 수 있습니까? 이 경우 작업을 두 부분으로 나눌 수 있습니다. 첫 번째 작업은 메시지를 보내고 두 번째 작업은 대기열에 추가하고 두 번째 작업은 데이터베이스에 기록합니다. 이 시나리오에서는 원하는 만큼 작업을 재시도할 수 있습니다. 메시지 전송 공급자가 다운되거나 내부 계정 데이터베이스가 다운된 경우 성공할 때까지 적절하게 재시도합니다!

좋은 울타리는 좋은 이웃을 만듭니다

Global Gizmos용 데이터베이스가 다운되면 예제 회사 Consolidated Widgets의 데이터 처리는 어떻게 됩니까?

이 시나리오에서 최소 한 번 전달 전략이 실행 중이면 Global Gizmos의 모든 데이터 처리 작업이 성공할 때까지 계속해서 재시도할 것으로 예상합니다. 데이터베이스가 다운된 동안에도 데이터가 손실되지 않습니다. 그러나 Consolidated Widget의 경우 그다지 좋지 않을 수 있습니다. 작업자가 지속적으로 재시도하고 실패하면 너무 바빠서 Consolidated Widget의 작업을 적시에 처리하지 못할 수 있습니다.

잘 선택된 대기열 이름을 사용하고 필요에 따라 특정 대기열을 일시 중지하여 이 문제를 해결할 수 있습니다. 우리의 도구 벨트에 이것을 사용하여 외과적 방식으로 인프라 조각에 대한 부담을 완화할 수 있습니다. 위의 시나리오에서 Global Gizmos의 데이터베이스가 다운되었다는 것을 알게 되면 백업이 될 때까지 데이터 처리 대기열을 일시 중지하여 특정 중단이 다른 고객에게 영향을 미치지 않도록 할 수 있습니다!

기다림은 고통스럽다

Consolidated Widgets 및 Global Gizmos가 5분 간격으로 각각 5천만 명의 사용자에게 이메일 캠페인을 보낸다면 어떻게 될까요? 누가 먼저 갈까?

단순 작업 대기열 시스템에는 작업자가 작업을 가져오는 단순한 "작업" 대기열이 있습니다. 다양한 작업과 작업 유형이 있으면 각각 다른 우선 순위 또는 해당 대기열에서 끌어오는 작업자 유형이 있는 여러 유형의 대기열을 갖게 될 것입니다. 그런 맥락에서 우리는 데이터 처리, 메시징 및 다양한 유지 관리 작업을 위한 다양한 단순 대기열을 보유하고 있습니다.

하루에 수십억 개의 개인화된 메시지를 보낼 때 하나의 "메시징" 대기열로는 잘리지 않습니다. 위의 예와 같이 해당 대기열이 매우 커지면 어떻게 됩니까? 먼저 도착한 작업을 우선시합니까?

우리의 동적 대기열 시스템은 일반적으로 일종의 우선순위 때문에 실행할 준비가 된 작업이 실행되기 전에 오랜 시간 대기하는 작업 기아 현상을 해결하려고 합니다. 간단한 "메시징" 대기열에서 우선 순위는 단순히 작업이 대기열에 들어간 시간입니다. 즉, 큰 대기열 끝에 추가된 작업은 매우 오랜 시간 동안 대기할 수 있습니다.

캠페인과 모든 메시지를 대기열에 추가할 때 큰 "메시지" 대기열에 작업을 추가하는 대신 이 캠페인에 대한 완전히 새로운 대기열을 생성합니다. 이 대기열이 무엇인지 알 수 있도록 특별한 이름으로 완성됩니다. 그것을 찾는 방법. 대기열에 작업을 추가한 후 "동적 대기열" 목록을 가져오고 이 새 대기열 이름을 끝에 추가합니다.

이 전략을 사용하여 작업자에게 "동적 대기열" 목록에서 동적 대기열의 이름을 선택한 다음 해당 특정 대기열의 모든 작업을 처리하도록 지시할 수 있습니다. 이를 통해 메시지가 가능한 한 빨리 전송되고 모든 고객이 동일한 우선 순위로 처리되도록 할 수 있습니다.

결과적으로 특정 작업자의 작업 지역이 증가하기 때문에 캐시 적중률이 더 높고 데이터베이스 연결이 더 적은 것과 같은 다른 이점이 있습니다. 모두가 이긴다!

항상 백업 계획을 세우십시오

데이터베이스가 다운되고 일부 대기열이 일시 중지되고 작업 대기열이 가득 차기 시작하면 어떻게 됩니까?

때때로 중요한 기반 시설이 단순히 당신에게 죽습니다. 보조 및 백업이 준비되어 있지만 백업 인프라를 승격하는 데 걸리는 시간은 거의 0이 아닙니다. 전체 애플리케이션 인프라에 여러 계층의 대기열을 갖는 것은 이러한 유형의 이벤트의 영향을 완화하는 데 매우 유용할 수 있습니다.

우리가 사용하는 그러한 전략 중 하나는 장치 자체에서 대기하는 것입니다. 수백만 및 수백만 개의 장치에 Braze SDK를 사용하는 서로 다른 애플리케이션이 있으며 이러한 애플리케이션에서 우리는 데이터를 API로 전송하기 위해 대기열을 활용합니다.

어떤 이유로든 SDK가 해당 데이터를 제출하려고 하고 실패하면 SDK는 성공할 때까지 지수 백오프 알고리즘을 사용하여 재시도를 대기열에 넣습니다. 이 전략은 인프라 또는 코드 오류의 영향을 최소화합니다. 장치가 단순히 자체 데이터를 대기열에 추가하고 모든 것이 다시 온라인 상태가 되면 이를 Braze로 보내기 때문입니다.

빠르게 움직이고 깨지지 않음

하루가 끝나면 우리의 목표는 누구보다 집중적으로 개인화된 메시지를 보내는 것입니다. 여기에는 신속하게 움직이고 탄력적으로 모든 것을 올바르게 처리하는 것이 포함됩니다. 작업 대기열은 Braze 인프라의 핵심이므로 우리는 항상 우리의 성능을 관찰하고 모범 사례를 적용하며 게임에서 최고가 되기 위해 새로운 전략과 고급 기술을 실험하고 있습니다.

마케팅 자동화 공간에서 이러한 유형의 고성능, 저지연 시스템 엔지니어링이 당신을 흥분시킨다면, 당신은 반드시 우리 구인 게시판을 확인해야 합니다!