여러 플랫폼은 BM으로 광고 클릭 이벤트를 선택하고 있고, 전체 광고 매출에서 차지하는 비중은 커지고 있다
대규모 규모에 걸맞는 광고 클릭 이벤트에 대해 설계해 보겠다
온라인 광고의 핵심적 혜택은 실시간 데이터를 통해 광고 효과를 정량적으로 측정할 수 있어 실시간 경매(Real-Time Bidding, 이하 RTB)라 부른다
이 경매 절차를 통해 광고가 나갈 인벤토리를 거래한다
광고가 나갈 인벤토리를 경매하면, 광고 거래소에서 해당 인벤토리를 제공하고 광고주가 경매를 하게된다
이 프로세스에서 속도가 중요하고, 데이터의 정확성 또한 중요하다
해당 집계는 온라인 광고가 얼마나 효율적이었는지 측정하는데 결정적인 역할을 하며, 광고주가 얼마나 많은 돈을 지불할지에 영향을 준다
핵심 지표로는 클릭률, 전환률 등이 있다
1단계 : 문제 이해 및 설계 범위 확정
입력 데이터는 어떤 형태인지? 양은?
- 분산된 로그 파일에 추가되는 형태, 10억 개의 광고 클릭, 광고 2백만 회 게재, 클릭 이벤트의 수는 매년 30% 증가
중요하게 지원되어야 할 질의 형태
- 특정 광고에 대한 M분 간의 클릭 이벤트 수
- 지난 1분간 가장 많이 클릭된 광고 100개, 질의 기간과 광고 수는 변경 가능해야 한다(집계는 분당 진행)
- ip, user_id, country 등의 속성으로 상기 2개 질의 결과를 필터링 할 수 있어야 한다
엣지 케이스에 대한 처리
- 예상보다 늦게 도착한 이벤트
- 중복된 이벤트
- 시스템 일부의 장애 복구 고려
지연 시간 요건
- 모든 처리는 수 분 내에 처리
- RTB는 1초 이내 처리, 광고 클릭 집계는 주로 광고 과금 및 보고에 사용되기 때문에 몇 분 정도 지연은 허용
기능 요구사항
- 지난 M분 동안 ad_id 클릭 수 집계
- 매분 가장 많이 클릭된 상위 100개의 광고 아이디 반환
- 다양한 속성에 따른 집계 필터링 지원
- 데이터의 양은 구글 규모
비기능 요구사항
- 집계 결과 정확성은 데이터가 RTB 및 광고 과금에 사용되므로 중요
- 지연되거나 중복된 데이터를 적절히 처리
- 견고성 : 부분적인 장애는 감내
- 지연 시간 요구사항 : 전체 처리 시간이 수 분내에 반드시 처리
일간 능동 사용자 수는 10억명에 평균 1개의 광고를 클릭한다고 가정 시 10억 건의 광고 클릭 이벤트가 발생한다
대략적으로 1초에 만건의 광고 클릭이 발생하며, 처리량이 몰릴 경우 50000건이라고 가정한다
클릭 이벤트 하나당 0.1KB가 필요하다고 가정하여 일일 저장소 요구량은 100GB, 월간 3TB이다
2단계 : 개략적 설계안 제시 및 동의 구하기
질의 API 설계
소비자 앱의 클라이언트는 대시보드를 이용하는 데이터 과학자, 제품 관리자, 광고주 같은 사람들이다
대시보드를 이용하는 순간 집계 서비스에 질의가 발생한다
필요한 질의로는
- 지난 M분 동안 ad_id 클릭 수 집계
- 매분 가장 많이 클릭된 상위 100개의 광고 아이디 반환
- 다양한 속성에 따른 집계 필터링 지원
에 대해 공통 사용되는 API가 필요하다
API 1 : 지난 M분간 각 ad_id에 발생한 클릭 수 집계
API 2 : 지난 M분간 가장 많은 클릭이 발생한 상위 N개 ad_id 목록
데이터 모델
이 시스템이 다루는 데이터는 두 종류이다
원시 데이터
로그 파일에 포함된 원시 데이터는
[AdClickEvent] ad001, 2021-01-01 00:00:01, user 1, 207.48.22.22, USA
꼴이며 이런 데이터가 여러 어플리케이션 서버에 기록되어 있다
이 방법으로는 원본 데이터를 손실 없이 보관 가능하며 데이터 필터링 및 재계산에 이용될 수 있다
하지만 데이터 용량을 많이 차지하게 되고 질의 성능이 낮아 연산이 오래 걸린다
집계 결과 데이터
id: ad001, timestamp: 202101010000, count:5
광고 필터링을 지원하기 위해 이 기록에는 filter_id를 추가한다
하나의 원시 데이터들의 취합에서 필터 아이디에 따라 다른 집계 결과 데이터를 가지게 된다
지난 M분 동안 가장 많이 클릭된 상위 N개의 광고를 반환하는 질의를 지원하기 위해서는
window_size(분 단위 집계 윈도우 사이즈), update_time_minute(마지막으로 갱신된 타임 스탬프), most_clicked_ads(ID 목록)
으로 구성된다
이 방법은 데이터 용량이 절감되며 질의 또한 빠르다
하지만 데이터가 손실되어 저장되기 때문에 재가공이 어려운 단점이 있다
문제 발생 시 디버깅에 활용하기 위해 원시 데이터도 보관하며, 버그로 집계 데이터가 손상된 경우 버그 수정 후 집계 결과를 다시 생산한다
원시 데이터는 양이 많으므로 직접 질의하는 것은 비효율적이다
원시 데이터는 백업 데이터로 활용된다. 오래된 데이터는 cold storage로 옮겨 비용을 절감한다
집계 결과 데이터는 활성 데이터이므로 질의 성능을 높이기 위해 튜닝한다
이러한 이유들로 두 데이터를 모두 저장하는 것이 바람직하다
데이터 베이스의 선택
원시 데이터는 질의가 거의 필요없지만 평균 쓰기가 10,000/s ~ 50,000s이고, 쓰기 중심 서비스이기 때문에 백업과 재계산 용도로만 사용되어 읽기 연산 빈도가 낮다
RDBMS로도 구축이 가능하지만 쓰기 및 시간 범위 질의에 최적화된 카산드라나 InfluxDB를 사용하는 것이 바람직하다
아파치 카산드라란? - 자유 오픈 소스 분산형 NoSQL 데이터베이스로, 단일 장애 점 없이 고성능을 제공하면서 수많은 서버 간의 대용량의 데이터를 관리하기 위해 설계 - DB를 해시 링 구조로 분산화하여 여러 인스턴스에서 구동할 수 있다. 사용자는 분산된 여러 DB를 하나의 DB처럼 조작할 수 있다 (레플리카 X) - 해시 링 구조의 분산된 쓰기 연산을 진행할 수 있기 때문에 마스터가 한 개인 RDBMS보다 쓰기 성능이 좋다
집계 데이터는 시계열 데이터이며 읽기/쓰기 연산을 둘 다 많이 사용한다
각 광고에 대해 매 분마다 질의를 던져 고객에게 최신 집계 결과를 제시해야 하기 때문에 총 200만 개의 광고가 있다고 하였으므로 읽기 연산이 많이 발생할 수 밖에 없고, 쓰기 연산 또한 마찬가지이다
그렇기 때문에 마찬가지로 같은 데이터 베이스를 이용하거나 이전 장처럼 시계열 데이터베이스 InfluxDB를 이용한다
개략적 설계안
실시간으로 빅데이터를 처리할 때 데이터는 지속적으로 들어오며, 집계 서비스도 마찬가지이다
하지만 입력은 원시 데이터이고, 출력은 집계 결과이다
기본적으로 로그 모니터에서 데이터를 푸쉬하면, 데이터 집계 서비스에서 요구사항 결과를 데이터베이스에 저장하고 이를 질의 서비스가 질의한다
비동기 처리
위 처리 방법은 기본적으로 동기 방식으로 생산자와 소비자가 항상 같은 스펙이 아니므로, 트래픽이 증가해 이벤트 수가 소비자의 처리 용량을 뛰어 넘는다면 문제가 발생할 수 있다
특정 컴포넌트의 장애가 전체 시스템의 장애가 되는 것을 피하기 위해 비동기 방식을 채택한다
일반적인 방안은 카프카 같은 메시지 큐를 도입하여 생산자와 소비자의 결합을 느슨하게 만들고, 그 결과로 전체 프로세스를 비동기로 동작하게 하여 규모를 독립적으로 확장하도록 하는 것이다
그럼 로그 모니터에서 메시지 큐로 발생하면 해당 내용을 원시 데이터베이스 기록 프로세스와 데이터 집계 서비스를 각각 소비자 그룹으로 나눠 메시지를 분배하고, 데이터 집계 서비스에서도 메시지 큐로 집계 결과를 보내 집계 결과 데이터베이스에 저장하는 것을 비동기화 시킨다
집계 결과 데이터베이스에 보내는 메시지 큐에는 분 단위로 집계된 광고 클릭 수와 분 단위로 집계된 가장 많이 클릭한 상위 N개 광고가 전송되는데, 정확하게 한 번 데이터를 저장하기 위해서 카프카와 같은 신뢰성 있는 메시지 큐를 사용하는 것이다
예를 들면 특정 조건에 만족하는 데이터는 노드1로 보내고, 그렇지 않은 노드는 2로 보내는 식으로 한다
카프카의 파티셔닝과는 다르게 맵 노드는 구분지을 때 데이터를 정리하거나 정규화할 수 있고, 데이터가 생성되는 방식에 대한 제어권이 없는 경우에는 카프카가 같은 ad_id를 갖는 이벤트들이 다른 카프카 파티션에 입력될 수 있기 때문이다
집계 노드
ad_id별 광고 클릭 이벤트 수를 매 분 메모리에 집계한다
맵 리듀스 패러다임에서 집계 노드는 리듀스 프로세스의 일부라고 볼 수 있다
리듀스 노드
모든 집계 노드가 산출한 결과를 최종 결과로 축약한다
각 집계 노드는 자기 관점에서 가장 많은 클릭이 발생한 광고 n개를 추려 리듀스 노드로 보내고, 리듀스 노드느느 그 결과를 모아 최종적으로 n개의 광고만 남긴다
3단계 : 상세 설계
스트리밍 vs 일괄처리
개략적 아키텍처는 일종의 스트림 처리 시스템이다
본 설계안은 스트림 처리와 일괄 처리 방식을 모두 사용한다
스트림 처리는 데이터를 오는 대로 처리하고 거의 실시간으로 집계된 결과를 생성하는데 사용하고,
일괄 처리는 이력 데이터를 백업하기 위해 활용한다
온라인 시스템
일괄 처리 시스템
스트리밍 시스템
응답성
클라이언트에게 빠르게 응답
클라이언트에게 응답 X
클라이언트에게 응답 X
입력
사용자의 요청
유한한 크기를 갖는 입력, 큰 규모 데이터
입력에 경계가 없음
출력
클라이언트에 대한 응답
구체화 뷰, 집계 결과 지표
구체화 뷰, 집계 결과 지표
성능 측정
가용성, 지연 시간
처리량
처리량, 지연 시간
사례
온라인 쇼핑
맵리듀스
플링크
람다 아키텍처는 두 가지 처리를 동시에 지원하는 시스템으로 처리 경로를 각각 두어 유지 관리해야 하는 코드가 두 벌이다
카파 아키텍처는 일괄 처리와 스트리밍 처리 경로를 하나로 결합 해 이 문제를 해결한다
집계한 데이터가 중대한 버그로 인해 다시 계산하는 경우가 있는데, 이때에는 버그 발생 시점부터 원시 데이터를 다시 읽어 재계산 한다
일괄 처리 프로세스를 통해 원시 데이터 저장소에서 데이터를 검색한 뒤, 다시 전용 집계 서비스(실시간 데이터 처리 과정이 과거 데이터 재처리 프로세스와 간섭하는 것을 막기 위해)로 전송하여 별개의 메시지 큐로 전송해 집계 결과 데이터 베이스에 반영한다
시간
집계를 하려면 타임 스탬프가 필요한데, 두 가지 방법으로 수집할 수 있다
1. 이벤트 시각 : 광고 클릭이 발생한 시각으로 클라이언트 의존
2. 처리 시각 : 집계 서버가 클릭 이벤트를 처리한 시스템 시각으로 서버에 의존
실제 이벤트가 발생한 시각은 이벤트 시각이지만 클라이언트가 생성한 타임 스탬프이므로 설정된 시각이 잘못 되었거나 악성 사용자가 고의로 조작하는 경우가 발생할 수 있다
처리 시각은 이를 방지할 수 있지만 계속 되는 실패나 서버의 문제로 부정확한 시각이 기록될 수 있다
워터마크라는 기술이 있는데 광고 클릭 이벤트는 1분 단위로 끊어지는 텀블링 윈도를 사용해 집계한다면, 이벤트 발생 시각을 기준으로 이벤트가 어떤 윈도에 속하는지 결정하면 윈도에서 해당 이벤트에 눌렸지만, 처리되지 않은 클릭을 집계하지 못하게 된다
워터마크는 집계 윈도의 확장으로 특정 시간동안 안에 이루어진 처리를 이전 윈도로 집계하는 것이다
이 크기는 비즈니스 요구사항에 따라 달라지며 커질수록 정확도는 높아지지만 대기 시간이 늘어나 지연 시간이 늘어난다
집계 윈도
윈도(Window)에는 텀블링 윈도, 호핑 윈도, 슬라이딩 윈도, 세션 윈도가 있다
텀블링 윈도는 앞에서 얘기했던 것 처럼 시간을 같은 크기의 겹치지 않는 구간으로 분할하여 매 분 발생한 클릭 이벤트를 집계하기 적합하다
슬라이딩 윈도는 데이터 스트림을 여러 구간을 하나의 윈도로 하여 겹칠 수 있다(슬라이딩 윈도우 알고리즘 느낌)
그래서 지난 M분간 가장 많이 클릭된 상위 N개 광고를 알아내기에 적합하다
전달 보장
집계 결과는 과금 등에 이용될 수 있기 때문에 데이터의 정확성과 무결성이 중요하다
- 이벤트의 중복 처리를 어떻게 피할 수 있는가?
- 모든 이벤트의 처리를 어떻게 보장할 수 있는가?
이는 정확히 한 번이 적절하다
데이터 중복 제거
중복 데이터는 다양한 곳에서 발생할 수 있다
- 클라이언트 측 : 클라이언트가 같은 이벤트를 여러 번 보내는 경우, 악의적인 의도로 전송되는 중복 이벤트를 처리하는 데 광고 사기/위험 제어 컴포넌트가 필요하다
- 서버 장애 : 집계 도중에 집계 서비스 노드에서 장애가 발생하였고 업스트림 서비스가 이벤트 메시지에 대해 응답을 받지 못하면 같은 이벤트가 다시 전송되어 재차 집계될 가능성이 있다
서버 장애 측에 대해 더 알아보자면 발생한 장애의 결과로 중복 데이터가 생길 수 있는데 업스트림 카프카로 오프셋을 저장하여 데이터 소비 상태를 관리한다
[업스트림 카프카] - [집계 서비스 노드] - [다운 스트림 카프카]
집계 서비스 노드가 업스트림에서 소비한 데이터에 대한 집계 처리를 다운 스트림에 전송한 뒤 장애가 발생해 업스트림에 완료에 대해 응답하지 못하는 경우가 생길 수 있다
그럼 복구 된 집계 서비스 노드는 다시 오프셋 100부터 이벤트를 소비하려 할 것이고 데이터 중복이 발생한다
간단한 해결 방법으로는 외부 파일 저장소에 오프셋을 기록하는 것이지만 이렇게 하면 결국 장애 순서에 따라 처리를 하지 않는 문제가 발생할 수 있다(데이터 손실 발생하거나 다시 데이터 중복 발생)
그렇기 때문에 근본적으로 해결하려면 분산 트랜잭션을 넣어 해당 실패에 대해 모든 작업을 실행 전으로 되돌려야 한다
분산 트랜잭션이란? 2개 이상 네트워크 시스템 간의 트랜잭션 트랜잭션 매니저는 이러한 리소스에 관련된 모든 동작에 대해 트랜잭션의 생성 및 관리를 담당
시스템 규모 확장
메시지 큐의 규모 확장
생산자 : 인스턴스 수에는 제한을 두지 않아 확장하기 쉽다
소비자 : 그룹 내의 재조정 메커니즘은 노드 추가/삭제를 통해 쉽게 조정 가능하다
브로커 :
- 해시 키 : 같은 ad_id를 갖는 이벤트를 같은 카프카 파티션에 저장하기 위해 ad_id를 해시 키로 사용한다
- 파티션의 수 : 수가 변하면 같은 ad_id를 갖는 이벤트가 다른 파티션에 기록되는 일이 생길 수 있다
충분히 파티션을 확보하여 수가 동적으로 늘어나는 일은 피한다
- 토픽의 물리적 샤딩 : 하나의 토픽으로 충분하지 않을 수 있으므로 지역에 따라 나누거나 사업 유형에 따라 토픽을 나눠 복잡해지고 비용이 늘어나나 재조정 시간이 단축된다
집계 서비스의 규모 확장
앞서 설계안에서 집계 서비스는 맵리듀스 연산으로 구현되어 있다
분배(맵) 프로세스가 카프카에서 전달된 데이터를 룰에 따라 분배하고, 축약(리듀스) 프로세스가 축약 연산을 한다
규모를 노드의 추가/삭제를 통해 수평적으로 조정하며 처리 대역폭을 높이려면 두 가지 선택지가 있다
1. 광고 id마다 별도의 처리 스레드(멀티 쓰레딩)
쉽게 구현이 가능하며 자원 공급자에 대한 의존 관계가 없어진다
2. 집계 서비스 노드를 아파치 하둡 같은 자원 공급자에 배포하는 방식(멀티 프로세싱)
컴퓨팅 자원을 추가하여 시스템 규모를 확장할 수 있다
데이터 베이스의 규모 확장
카산드라는 consistent hash와 유사한 방식으로 수평적인 규모 확장을 기본적으로 지원한다
데이터는 각 노드에 균등하게 분산되며, 사본도 적당한 수만큼 만들어 분산한다
해시 링 위의 특정 해시 값 구간에 데이터 보관을 담당하고 다른 가상 노드의 데이터 사본도 보관한다
클러스터에 새 노드가 추가되면 가상 노드 간의 균형을 자동으로 다시 조정하여 샤딩을 조정하지 않아도 된다
핫스팟 문제 다른 서비스나 샤드보다 더 많은 데이터를 수신하는 서비스나 샤드를 핫스팟이라 하며, 광고 클릭 집계 시스템의 경우 특정 광고만 다른 광고에 비해 광고력(?)이 높아서 많은 클라이언트의 접속으로 핫스팟이 발생할 수 있다 이벤트 파티션을 광고에 따라 나누기 때문에 특정 노드가 다른 노드보다 더 많은 광고 클릭 이벤트를 수신할 수 있고, 서버 과부하 문제가 발생할 수 있다
이 문제는 더 많은 집계 노드를 할당하여 완화할 수 있다( 맵 -> 집계 -> 리듀스) 자원 관리자가 새로운 집계 노드를 할당해 원래의 집계 노드가 이벤트를 분할하고, 각자 처리 후 결과를 리듀스해서 다시 원래의 집계 노드에 결과를 반환한다
이외에도 Global-Local Aggregation, Split Distinct Aggregation 같은 방법이 있다
결함 내성
집계는 메모리에서 이루어지므로 집계 노드에 장애가 생기면 결과에 손실이 생긴다
하지만 기존에 업스트림 카프카 브로커를 통해 이벤트를 다시 받아와 손실된 값을 다시 받아올 수 있다
카프카 데이터를 원점부터 다시 재생하면 집계가 오래 걸리므로 시스템 상태를 스냅샷으로 저장하고 마지막으로 저장된 상태부터 복구하는 것이 바람직하다
업스트림 오프셋 뿐만이 아닌, M분간 가장 많이 클릭된 광고 N개 같은 데이터도 메모리에 저장되므로 저장해야 한다
스냅샷을 이용하면 복구 절차가 단순해진다
집계 서비스 노드 하나에 장애가 발생하면 해당 노드를 새 것으로 대체한 다음 마지막 스냅샷에서 데이터를 복구하면 되고(분산 트랜잭션으로 카프카는 롤백되었다), 스냅샷을 마지막으로 찍은 후에 도착한 새로운 이벤트는 새 집계 서비스 노드가 브로커에서 읽어가 다시 처리한다
데이터 모니터링 및 정확성
RTB 및 청구서 발행 목적으로 정상적으로 동작하는지 확인하고 데이터 정확성을 보장하는 것은 중요하다
지속적 모니터링
다음 지표는 지속적으로 모니터링해야 한다
- 지연 시간 : 데이터를 처리하는 단계마다 지연시간이 추가될 수 있으므로 시스템 중요 부분에서 추적이 가능하도록 해야 한다
- 메시지 큐 크기 : 큐의 크기가 갑자기 늘어난다면 더 많은 집계 서비스 노드를 추가해야 한다. 카프카는 분산 커밋 로그 형태로 구현된 메시지 큐이므로 카프카를 사용하는 경우에는 레코드 처리 지연 지표를 대신 추적하면 된다
- 집계 노드의 시스템 자원 : CPU, 디스크, JVM 등
조정(Reconciliation)
다양한 데이터를 비교하여 데이터 무결성을 보증하는 기법이다
매일 각 파티션에 기록된 클릭 이벤트를 이벤트 발생 시각에 정렬한 결과를 일괄 처리하여 만들어 낸 다음 실시간 집계 결과와 비교한다(윈도 크기에 따라 정확도가 달라진다)
윈도 크기에 관계없이 일부 이벤트는 늦게 도착할 수 있으므로 배치 작업 결과가 실시간 집계 결과와 정확히 일치하지 않을 수 있다
조정 또한 재계산 서비스와 마찬가지로 일괄 처리를 위해 별개의 서비스를 구축하는 것이 좋다
대안적 설계안
광고 클릭 데이터를 하이브에 저장한 다음 빠른 질의는 ElasticSearch 계층에 얹어서 처리하는 것이다
Apache Hive란? Apache Hive는 사용자가 SQL를 사용하여 페타바이트 데이터를 읽고 쓰고 관리할 수 있도록 한다 대규모 데이터 세트를 효율적으로 저장하고 처리하는 데 사용되는 오픈 소스 프레임워크인 Apache Hadoop을 기반으로 빌드되어, Hadoop과 긴밀하게 통합되며 페타바이트 규모의 데이터를 신속하게 처리하도록 설계되었다 Hive는 SQL과 유사한 인터페이스로 Apache Tez 또는 MapReduce를 활용하여 대규모 데이터 세트를 쿼리할 수 있다
Elastic Search란? Elasticsearch는 Apache Lucene에 구축되어 배포된 검색 및 분석 엔진이다 로그 분석, 전체 텍스트 검색, 보안 인텔리전스, 비즈니스 분석 및 운영 인텔리전스 사용 사례에 일반적으로 사용되며, 간단한 REST 기반 API, 간단한 HTTP 인터페이스를 제공하고 스키마 없는 JSON 문서를 사용해 다양한 사용 사례에서 쉽게 시작하고 빠르게 애플리케이션을 구축한다 분산 성질로 인해 큰 볼륨의 데이터를 병렬로 처리할 수 있고 역색인을 통해 최고의 일치 항목을 빠르게 찾을 수 있다
