프로그래매틱 오디오 광고 업계에서 101ms는 수익 제로를 의미합니다. 이는 성능 문제가 아니라, 존폐 위기를 뜻하는 문제입니다.  저희는   모든 요청은   이 시간을 놓치면 입찰이 취소됩니다. 101밀리초가 되면 사실상 존재하지 않는 것과 마찬가지입니다. 하루 약 3억 5천만 건, 주당 약 20억 건의 요청을 처리하는 오디오 광고 DSP를 운영하고 있습니다. 100밀리초 이내에 수신, 평가 및 응답되어야 합니다.  저희는 3명의 엔지니어링 팀과 월 1만 달러 미만의 클라우드 비용으로 이 모든 것을 구현합니다. 입찰 인프라, 애플리케이션 계층, 데이터베이스 및 운영까지 모든 것을 동일한 팀이 담당합니다.   RTB 생태계  광고 기술에 대해 잘 모르시는 분들을 위해 간단히 설명드리자면, 프로그래매틱 광고는 실시간 입찰(RTB) 방식으로 운영됩니다.  공급 측면에는   있습니다. AdsWizz나 Triton과 같은 플랫폼은 팟캐스트 플레이어, 스트리밍 앱 및 기타 오디오 플랫폼 등 수천 개의 앱과 게시자의 광고 인벤토리를 통합합니다. SSP(공급측 플랫폼)가  수요 측에는   가 있습니다. DSP는 광고주를 대변하는 시스템으로, 당사 시스템과 같이 특정 노출에 입찰할지 여부를 실시간으로 결정합니다. DSP(수요측 플랫폼)  청취자가 팟캐스트 앱을 열고 광고 슬롯이 사용 가능해지면, 앱은 SSP(Supply-Side Platform)와 통신합니다. 그러면 SSP는 여러 DSP(Demand-Side Platform)에 입찰 요청을 보냅니다. 저희 시스템은 이 요청을 수신하여 사용자와 활성 캠페인을 평가하고, 입찰가를 계산한 후 응답을 보냅니다. 이 모든 과정은 처음부터 끝까지 100ms 이내에 완료되어야 합니다.  지연 시간은 단순히 측정 지표가 아닙니다. 지연 시간 자체가 결과물입니다.  그 점을 받아들이고 나니, 일반적인 웹 애플리케이션 설계 방식으로는 안 된다는 것이 분명해졌습니다. 마이크로서비스 간 네트워크 연결을 허용할 수 없었고, 방대한 쿠버네티스 환경 구축에 드는 클라우드 비용도 감당할 수 없었습니다. 살아남기 위해서는 제약 조건을 고려한 설계가 필수적이었습니다.  그 제약 조건은 이론적인 것이 아니었습니다. 초기에는 클라우드 크레딧이 있었기 때문에 효율성에 대해 크게 걱정하지 않았습니다. 하지만 크레딧이 소진되자 모든 아키텍처 결정에 실질적인 비용이 발생하기 시작했습니다. 그때 우리는 시스템을 처음부터 다시 설계하여 지연 시간, 비용 및 운영 간소화를 최적화해야 했습니다.  다음은 3인 팀이 비용 낭비나 스트레스 없이 대규모 글로벌 RTB 시스템을 운영할 수 있도록 하는 아키텍처입니다.  1. 지리적 요인을 첫 번째 필터로 활용하기: 네트워크 물리학을 고려한 설계  당사가 통합하는 주요 오디오 SSP인   는 미국, 유럽 및 동남아시아에 걸쳐 호스팅됩니다. 인도 광고주를 위한 캠페인 로직을 담당하는 애플리케이션 레이어는 인도에 있습니다. Triton, AdsWizz, Magnite(이전 Rubicon), MCTV  이 지역들 간의 네트워크 왕복 시간만 해도 애플리케이션 로직이 실행되기 전에도 약   소요됩니다. 이는 허용된 시간보다 두 배 이상 초과하는 수치입니다. 240밀리초가  해결책은 간단했지만 타협할 수 없는 사항이었습니다. 우리는 미국 서부(오리건), 유럽 중부(프랑크푸르트), 아시아 태평양(싱가포르 및 홍콩)   에 입찰 클러스터를 배포했습니다. 의 네 가지 전략적 AWS 리전  이를 통해 SSP가 입찰 요청을 보낼 때 하드웨어까지의 거리가 무시할 수 있을 정도로 짧아지므로(일반적으로 한 자릿수 밀리초) 100ms의 예산 대부분을 실제 컴퓨팅에 사용할 수 있습니다.  2. 모놀리스-마이크로서비스 하이브리드   우리는 기존의 모놀리식 아키텍처와 마이크로서비스 아키텍처의 중간 형태에 해당하는 아키텍처를 개발했습니다. 서비스를 네트워크 전체에 분산시키는 대신,   함께 배치하고, 글로벌 로드 밸런서를 통해 이러한 가상 머신을 수평적으로 확장합니다. 긴밀하게 연결된 소규모 서비스 클러스터를 단일 가상 머신에  각 VM 내부(단일 노드로 취급됨)는 마치 소형 분산 시스템처럼 보입니다.    : 내부 트래픽 관리자 역할을 하는 단일 인그레스 컨테이너입니다. Nginx    : CPU를 최대한 활용하기 위해 동일한 머신에서 Node.js 입찰 서비스의 복제본 3~5개를 실행합니다. 입찰자    : 코드와 함께 실행되는 로컬 Redis 인스턴스입니다. Redis  이러한 방식의 가장 큰 장점은 기본적으로 데이터 지역성입니다. 입찰자는 데이터를 가져오기 위해 네트워크를 거치지 않고 로컬 호스트에서 바로 읽습니다. 또한 이를 통해   훨씬 높일 수 있습니다. 예를 들어, c6i.xlarge와 같은 대형 VM을 사용하고 여러 워커에서 단일 인메모리 데이터셋을 공유함으로써 RAM 대 CPU 비율을 크게 개선하여 낭비를 최소화하고 처리량을 극대화할 수 있습니다. 리소스 밀도를  3. 논리: 빠르게 실패하기  100ms의 마감 시간을 맞추려면 단순히 빠른 코드만으로는 부족합니다. 시스템은 언제 작업을 하지 말아야 할지 신속하게 판단해야 합니다.  대부분의 입찰 요청은 결국 낙찰되지 않습니다. 이러한 요청이 상태, 데이터베이스 또는 쓰기 경로에 접근하도록 허용하는 것은 지연 시간 예산을 초과하는 가장 빠른 방법입니다. 따라서 입찰자는 "실패 가능성"에 따라 순서가 지정된 의사 결정 트리로 구성되며, 가장 비용이 적게 드는 검사부터 먼저 실행합니다.  검사는 대략 다음과 같은 순서로 진행됩니다.    : 입찰의 상당 부분이 여기서 실패합니다. 이는 간단한 비교이며 거의 즉시 결과를 보여줍니다. 지리적 위치 확인    : 지리적 위치 확인이 완료되면 플랫폼 및 기기 제약 조건을 검증합니다. 운영체제 및 기기 확인    : 앱이 허용된 인벤토리와 일치하는지 확인합니다. 퍼블리셔/앱 타겟팅    : 요청이 이러한 필터를 통과한 경우에만 사용자 수준 데이터, 예산 및 속도 조절 로직 또는 조정이 필요한 기타 복잡한 경로에 접근합니다. 상태 유지 로직  빠른 실패를 통해 마이크로초 단위로 트래픽의 90%를 차단하고, 실제로 전환으로 이어지는 입찰에만 CPU 사이클을 할당합니다.  4. 데이터 아키텍처: 규칙 관리에는 Redis, 프로필 관리에는 Aerospike 사용  우리는 데이터 접근 패턴과 "데이터 최신성 유지" 비용을 기준으로 데이터 아키텍처를 두 계층으로 나누었습니다.  규칙: 로컬 Redis  각 노드는 로컬 Redis에 "활성화된" 메타데이터(활성 캠페인 및 예산 한도)를 저장합니다. cron 워커는   사용하여 60초마다 중앙 API에 접속하여 최신 "실제 정보"를 다운로드합니다. 풀(pull) 방식을  우리 규모에서는 이러한 60초의 데이터 지연이   이라는 위험을 초래합니다. 여러 노드가 동일한 오래된 예산 데이터에 동시에 접근할 경우, 클라이언트가 할당한 금액보다 더 많은 비용을 지출할 수 있습니다. '과다 지출'  저희는   통해 이를 처리합니다. 즉, 노드 수를 예산 관리의 입력값으로 간주합니다. 활성 입찰 노드 수가 증가함에 따라 각 노드는 사용할 수 있는 예산의 "할당량"을 동적으로 줄입니다. 노드가 오래된 데이터를 사용하더라도 현재 노드 수를 기준으로 로컬 제한이 이미 설정되어 있습니다. 지출은 급증하는 대신 부드럽게 감소하며, 시스템은 다음 갱신 주기에 수렴합니다. 제동 메커니즘을  프로필: 에어로스파이크(SSD의 장점)  사용자 수준 데이터 프로필 조회, 빈도 제한 및 리타겟팅에는 대규모의 가변 데이터 세트에 대한 밀리초 미만의 빠른 액세스가 필요합니다. 기존 관계형 데이터베이스 관리 시스템(RDBMS)은 당사 가격대에서 이러한 부하를 처리할 수 없습니다.  우리는 이 계층에   사용하는데, 그 이유는 Aerospike가 전체 작업 세트를 RAM에 유지하는 대신 SSD를 기본 저장소로 처리하도록 최적화되어 있기 때문입니다. 이를 통해 예측 가능한 지연 시간을 확보하는 동시에 하드웨어 비용을 ElastiCache와 같은 순수 RAM 솔루션의 일부로 유지할 수 있습니다. Aerospike를  이 계층의 가격을 저렴하게 유지하기 위해, 우리는 데이터 관리에 매우 철저합니다.  10일 규칙: 저희는 최근 10일 동안 활동한 사용자의 데이터만 보관합니다.  1천만 명 제한: 저희는 가장 활동적인 사용자 몇 백만 명만 남기고 데이터셋을 적극적으로 정리합니다.  사용자가 더 이상 활동을 하지 않으면 해당 사용자의 데이터는 삭제됩니다. 이러한 방식을 통해 저장 비용은 일정하게 유지되는 반면, 입찰자는 중요한 사용자에게만 집중할 수 있습니다.  5. "비동기"의 비밀: 부담 분리  첫 번째 버전은 기술적으로 비동기 방식을 시도했습니다. 입찰 응답을 즉시 전송하고, Node.js 함수가 백그라운드에서 계속 실행되면서 로그를 MongoDB에 기록하도록 했습니다.    : 트래픽은 일정하게 유지되지 않고 급증합니다. 피크 시간대에는 입찰 응답이 끝났음에도 불구하고 Node.js 컨테이너가 "떠 있는" 상태로 남아 연결을 유지하고 데이터베이스 쓰기를 완료하려고 CPU 리소스를 소모했습니다. 이로 인해 자동 스케일러가 쓰기   처리하기 위해 더 많은 VM을 생성하게 되었고, 결국 데이터베이스에 과도한 연결이 발생하여 과부하가 걸렸습니다. 함정 작업 백로그를    : "비동기 코드"에서 "   "로 전환했습니다. 입찰자와 쓰기 경로 사이에   완충 장치로 도입했습니다. 이제 입찰자는 Kafka에 메시지를 푸시하고 즉시 리소스를 해제합니다. "쓰기" 작업은 별도의 소비자 그룹에서 제어된 속도로 처리됩니다. 해결책 비동기 아키텍처 Kafka를  6. 벤치마킹: 추측하지 말고 측정하라  이 정도 규모에서는 인스턴스 유형을 추측하는 데 비용이 많이 듭니다. 따라서 이론에 의존하는 대신 벤치마킹을 수행했습니다.  우리는 입찰자가 컴퓨팅 자원이나 메모리 자원에 제약을 받는지, 노드당 적절한 작업자 프로세스 수는 몇 개인지, 인스턴스 크기가 지연 시간에 어떤 영향을 미치는지 등의 가설을 세웠습니다. 여러 AWS 인스턴스 제품군과 크기를 대상으로 테스트를 진행했고, 단일 노드에서 실행되는 입찰 서비스 수를 다양하게 조정했습니다.  데이터 계층에서도 동일한 접근 방식을 취하여 실제 부하 상황에서 MongoDB에 가장 적합한 머신 유형을 찾기 위해 다양한 유형을 테스트했으며, 최대 처리량보다 안정적인 지연 시간을 우선시했습니다.  이 모든 것은 실제 운영 환경과 유사한 초당 쿼리 수(QPS)를 시스템에 가하는 부하 테스트를 통해 검증되었으며, 응답 시간과 지연 시간(tail latency)을 측정했습니다. 일부 가정은 맞았지만, 많은 가정은 틀렸습니다.  핵심은 간단했습니다.   . 100ms의 제약 조건에서는 벤치마크 결과가 이론치를 항상 능가한다는 것입니다  7. 재무 운영: 청구액을 1만 달러로 유지하는 방법  스타트업은 트래픽 급증 때문에 망하는 것이 아닙니다. 클라우드 크레딧이 소진될 때 망하는 것입니다. 저희에게 비용 관리는 나중에 고려할 사항이 아니라 시스템 설계 단계부터 포함된 핵심 요소입니다.  협상을 통해 비용을 절감할 수 있었습니다. 정액 할인 혜택을 받기 위해 리셀러를 통해 결제를 진행했고, 대역폭의 경우   약정하여 CDN 가격을 온디맨드 요금 대비 60% 이상 낮출 수 있었습니다. 저희 트래픽 규모에서는 이러한 약정 하나만으로도 상당한 비용 절감 효과를 볼 수 있었습니다. 월 1PB 정도의 데이터 전송량을  또한, 우리는 우려 사항을 구분합니다. 상태 비저장 입찰 서버는 크게 할인된 스팟 용량에서 실행되는 반면, 상태 저장 데이터베이스는 예측 가능하고 수명이 긴 인스턴스를 사용합니다.  우리 규모에서 하루에 수억 건의 기록을 저장하는 것은 시한폭탄과 같습니다. 상세한 입찰 기록은 보존 기간이 짧아 몇 달이 아닌 며칠 정도면 충분합니다. 보관해야 할 데이터는 이벤트 단위가 아닌 시간 단위로 집계하여 더 저렴하고 검색이 용이한 저장소로 옮깁니다. 규정 준수 또는 과거 기록 감사 목적으로만 필요한 데이터는 콜드 스토리지로 이동시켜 표준 스토리지 대비 80~90%의 비용 절감 효과를 얻습니다.  하지만 가장 큰 절약 방법은 할인이 아니라   입니다. 활용률  대부분의 시스템은 "안전을 위해" CPU 사용률을 20~30%로 유지합니다. 하지만 저희 시스템은 그럴 필요가 없습니다. 내결함성 아키텍처와 부하를 안정적으로 분산하도록 설계된 덕분에 CPU   까지 높여도 문제없습니다. 유휴 상태에 대한 비용은 발생하지 않습니다. 만약 특정 코어에 대한 비용을 지불하고 있다면, 그 코어는 항상 제 역할을 하고 있는 것입니다. 사용률을 80%  효율성을 최우선 고려 사항으로 여기는 그러한 사고방식 덕분에 교통량이 증가하더라도 요금이 변동 없이 유지되는 것입니다.  8. 세 명으로 운영하기: "수업료" 철학  세 명으로 글로벌 규모의 사업을 운영하려면 시스템이 아닌 사람이 모든 부담을 감당해야 합니다. 우리는 핵심 경로에서 사람의 개입을 최소화하고 가능한 한 단일 장애 지점을 제거하도록 운영을 설계합니다. 또한 역할 분담을 없애 각 엔지니어가 전체 스택을 다룰 수 있도록 함으로써 운영 지식이 단일 장애 지점이 되는 일이 없도록 합니다.  인프라는 기본적으로 일회용입니다. 노드에 문제가 발생하면 현장에서 디버깅하지 않고 즉시 종료한 후 자동 스케일러가 자동으로 교체합니다. 복구는 문제 조사보다 빠르며, 모든 인스턴스는 알려진 정상 상태에서 시작됩니다.  관찰 가능성은 중요하지만, 대시보드만으로는 소규모 팀에 큰 도움이 되지 않습니다. 저희는 사람의 개입이 필요한 경우에만 트리거되는 실행 가능한 알림(Datadog을 통해)에 의존합니다. 지역 클러스터 속도가 느려지거나 소비자가 지연되는 경우에만 알림을 받습니다. 그 외의 모든 작업은 자동화되어 있습니다.  하지만 자동화는 마법이 아닙니다. 우리는 여전히 때때로 수업료를 지불합니다.  초기 사례 중 하나로, 예산 상태를 갱신하는 백그라운드 작업이 아무런 오류 메시지 없이 실패했습니다. 입찰자는 오래된 데이터를 계속 사용하며 이미 종료되었어야 할 캠페인에 비용을 지출했는데, 이는 전형적인 "좀비 입찰자" 상황이었습니다. 우리는 고객에게 환불해 주고 문제를 해결했으며, Datadog에서 모니터링하는 하트비트 검사를 통해 시스템을 강화했습니다. 이제 예산 최신 상태는 명확하게 표시되며, 오류가 발생하면 경고가 트리거됩니다. 입찰자가 유효한 업데이트를 받지 못하면 입찰이 중단됩니다.  소규모 팀에서는 실수가 불가피합니다.  하지만 같은 실수를 반복하는 것은 선택 사항입니다.  마무리 생각  이 시스템의 어떤 결정도 그 자체로는 특별하지 않습니다. 이 시스템이 작동하는 이유는 이러한 결정들이 어떻게 복합적으로 작용하는지 때문입니다.  네트워크 물리학이 경계를 설정합니다. 지역성과 빠른 장애 복구 로직은 100ms 경로를 보호합니다. 비동기 경계는 트래픽 급증을 흡수합니다. 직관은 측정으로 대체됩니다. 비용 관리와 높은 활용률은 경제성을 보장합니다. 시스템이 자체적으로 복구할 수 없을 때만 사람이 개입하도록 운영이 설계되었습니다.  이 이야기는 광고 기술이나 특정 기술 스택에 관한 것이 아닙니다. 규모가 커질   상기시켜 주는 것입니다. 지연 시간, 비용, 인력을 최우선 고려 사항으로 삼으면, 결과적으로 더 복잡해지는 것이 아니라 더 단순한 아키텍처가 탄생하는 경향이 있습니다. 수록 제약 조건은 장애물이 아니라 설계의 중요한 요소가 된다는 점을  목표는 인상적인 것을 만드는 것이 아니었습니다. 오래도록 살아남을 수 있는 것을 만드는 것이었습니다.

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

이 오디오는 이야기의 원래 언어로 제작되었습니다!

20억 건의 요청, 100밀리초 마감 시한, 월 1만 달러: 효율적인 글로벌 RTB 시스템 구축

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

Crypto Growth: 효과적인 사용자 페르소나 만들기

탭하여 수익 창출: 텔레그램에서 솔라나 이전에 100억 명의 암호화폐 사용자를 확보할 수 있음

보이지 않는 레이어: 사용자 인터뷰가 대체할 수 없는 자산인 이유

바다 항해: 데이터 레이크를 사용하여 프로덕션 등급 RAG 애플리케이션 개발

Crypto Growth: 효과적인 사용자 페르소나 만들기

탭하여 수익 창출: 텔레그램에서 솔라나 이전에 100억 명의 암호화폐 사용자를 확보할 수 있음

보이지 않는 레이어: 사용자 인터뷰가 대체할 수 없는 자산인 이유

바다 항해: 데이터 레이크를 사용하여 프로덕션 등급 RAG 애플리케이션 개발

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps