Dayoung

Dayoung

Be-Developer

© 2024

Dark Mode

대규모 시스템 설계 기초 2 : 6.광고 클릭 이벤트 집계
Aug 2, 2024
  • study,
  • architecture
  1. 광고 클릭 이벤트 집계
    • 디지털 광고 핵심 프로세스는 RTB(Real-Time Bidding), 실시간 경매로 광고가 나갈 지면을 거래한다.

1. 문제 이해 및 설계범위 확정

질문

  • 입력 데이터 형태 : 로그파일
  • 데이터 양 : 매일 10억개의 클릭, 2백만회 광고 게재, 매년 클릭수 30% 증가
  • 요구되는 질의
    • 지난 M분간 클릭 수, 상위 N개
    • 다양한 속성에 따른 집계 필터링 지원
    • 데이터 양은 페이스북이나 구글 규모
  • 엣지케이스
    • 지연, 중복 이벤트 처리가 필요.
      • 클릭이벤트 집계 처리는 수분내에 이루어져야함.
      • RTB(RealTime Bidding) 지연시간은 1초미만

계략적 추정

  • DAU 10억명
  • 사용자는 하루에 1개 광고를 클릭한다 가정
  • QPS = 1만 , 최대는 5배인 5만이라 가정
  • 클릭 이벤트 하나당 0.1KB 저장용량이라 가정 = 월간 3TB 저장소 필요

2. 개략적 설계안 제시 및 동의 구하기

질의 API

  1. 지난 M분간 ad_id에 발생한 클릭 수 : /v1/ads/{:adId}/aggregated_count?from={timestamp}&to={timestmap}&filter=001
    • filter : 필터링 전략 식별자, 코드로 관리됨.
  2. 지난 M분간 가장 클릭이 많은 상위 N개 ad_id 목록

데이터 모델

  1. 클릭 수 데이터모델
    1. ad_id / click_minute(yyyyMMddHHmm) / filter_id / count -> API는 미리 집계된 데이터를 리턴할뿐, 미리 저장되어있어야한다. [[Star schema]]
  2. 상위 N개 데이터모델
    1. window_size/ update_time_minute / most_clicked_ad_ids
  • 원시 데이터를 저장하는 방법과 집계 결과 데이터만 저장하는 방법, 둘다 저장하는것이 좋다.
  원시 데이터만 보관 집계 결과 데이터만 보관
장 - 손실없이 보관 ( 백업 가능 )
- 데이터 필터링 및 재계산 지원		 - 데이터 용량 절감
- 빠른 쿼리
단 - 막대한 데이터 용량
- 낮은 쿼리성능		 - 데이터 손실, 스펙변경시 과거데이터는 대응 불가
특징 - 백업과 재계산 용도이므로 읽기 빈도가 낮다. - 읽기,쓰기 연산 모두 빈번.
적합한 DB - 쓰기 및 시간범위 질의에 최적화된
- [[카산드라]]
- [[InfluxDB]]
- [[Parquet]]		 - 원시데이터와 같은 DB사용하여 복잡도 줄이기
- RDB?

개략적 설계안

  • 동기식 시스템은 특정 컴포넌트의 장애는 전체 시스템 장애로 이어진다.
  • 비동기처리, 메세지 큐를 도입하여 생산,소비자의 결합을 끊으면 각각 독립적으로 확장시킬 수 있다. image

집계 서비스

[[MapReduce]], [[DAG _ 유향 비순환 그래프]] 모델 을 사용하여 빅데이터를 분산처리한다.

3. 상세 설계

스트리밍 vs 일괄 처리 (batch)

  • [[lambda]] : 일괄 및 스트리밍 처리 경로를 동시에 지원하는 시스템 아키텍처. 코드가 두벌 생성되는게 단점.
  • [[Kappa architecture]] : lambda의 단점을 일괄처리와 스트리밍 처리경로를 하나로 결합하여 해결.

  • [[프로그래밍 패러다임 비교]] 참고

  • 재계산 서비스

    • 원시데이터를 읽어 집계 기록용 메세지큐로 전송.
    • 원래 집계서비스와 분리하여 영향이 없도록 함.
  • 시계
    • 이벤트가 발생한 시각을 집계에 사용하는 경우에는 이벤트 지연 처리문제를 잘 해결해야한다.
    • 워터마크 : 집계 텀블링 윈도우의 확장을 통해 조인 대상이 윈도우에서 누락되지 않도록 함.

시간과 집계 window

  • tumbling window : 겹치지않는 같은 시간구간
    • 매분 발생한 클릭 이벤트를 집계하기 좋다.
  • sliding window : 같은 시간 구간 안에 있는 이벤트 집계, 겹칠 수 있다.
    • 지난 m분간 가장 많이 클릭된 상위 n개 광고

전달 보장

  • 정확도가 높아야하므로, [[exactly once]] 방식을 채택.
  • 분산 트랜잭션으로 중복처리되지 않도록 보장해야한다.

시스템의 규모 확장

  1. 메세지 큐 : 흔한 카프카의 규모확장 방식.
  2. 집계 서비스 : 맵리듀스에서 노드 추가/삭제로 대응가능. [[hadoop]] 같은 자원 공급자에 배포하여 관리.
  3. DB : [[카산드라]]는 [[안정해시]] 와 유사한 방식으로 수평적 규모확장 지원됨.

핫스팟 문제

  • hotspot : 데이터 샤딩 불균형으로 더 많은 트래픽을 받는 샤드나 서비스.
  • 집계서비스 노드 추가로 대응가능.

결함 내성

  • 노드에 장애가 생기면 재집계가 필요한데, 시간이 오래걸릴 수 있으므로, 스냅숏을 상태로 저장하여 빠른 복구를 지원한다.

데이터 모니터링 및 정확성

  • 데이터 조정, 정확성
    • 일배치로 만든 데이터와, 스트림으로 처리된 데이터를 비교하여 정확성 확인.
    • 일부 이벤트는 늦게 도착하는 경우도 있으므로, 배치결과와 정확히 같지 않을 수 있다.

대안적 설계안

  • 클릭 데이터를 Hive에 저장하고, 질의를 ES로 사용, 집계는 ClickHouse같은 [[OLAP DB]]를 사용해 처리