3번째 사이드 프로젝트의 주제를 AdTech 로 결정했습니다. 이번 사이드 프로젝트는 대용량 데이터 처리를 위한 구조를 만들어보고, 실제 대용량 트래픽을 발생시켜 여러 가지 이슈에 부딪혀 보는 것입니다.
AdTech 가 궁금하다면 이 글을 참고해주세요
1. 요구사항
1.1 도메인 분석
AdTech의 주요 사용자는 광고주, 매체사, 유저입니다. 광고주가 광고를 원하면 매체사에서 그 광고를 노출해 주고 이 광고가 유저에게 노출되는 것이죠.
이 광고의 경우 광고주는 토스이고, 매체사는 X이며, 유저는 저를 포함한 X 사용자입니다.
AdTech 플랫폼을 개발하려면 필요한 도메인 지식은 아래 정도가 있습니다. 앞서 예시로 들었던 토스 광고를 예시로 들어보겠습니다.
Campaign, AdGroup, Ad
- Campaign: 토스 친환경 캠페인
- AdGroup: 탄소 중립 (20대 타겟, iOS 유저, Budge 하루 100만원)
- Ad-A: 친환경 활동하면..., 이미지 A
- Ad-B: 친환경 활동하면..., 이미지 B
Impression, Click
- Impression: 13231 (X에 13231번 노출됨)
- Click: 201 (노출된 광고를 201번 클릭함)
1.2 기능적 요구사항
- 광고주가 광고를 등록하고 관리할 수 있음 좋겠다.
- 매체사가 입찰에 참여할 수 있으면 좋겠다.
- 테스트 페이지에 광고가 띄워지면 좋겠다.
- 유저 이벤트가 발생한 경우(노출, 클릭), 이벤트를 감지하여 비용을 부과한다
- 입찰을 통해 광고를 노출시키며, Budget Cap 에 도달할 경우 노출을 중지한다.
- 광고 지표, 예산 지출을 쉽게 확인할 수 있음 좋겠다.
1.3 비기능적 요구사항
- 99% 이상의 가용성 보장, 내결함성을 갖춰야 함
- 초당 최소 1000 TPS
- 입찰 요청 처리 시간은 100ms 이내
- 트래픽 처리 증가 시, 데이터 베이스 부하 분산 가능
- API 서버 수평 확장 가능
2. 구현계획
순차적으로 시스템 구조를 확장할 예정이며 각 계획은 아래와 같습니다.
2.1 1차 시스템 구축
- Monolithic 구조로 개발
- Demand-Side Platform 개발 (광고주 대시보드)
- Supply-Side Playform 개발 (매체주 대시보드)
- Data Management Platform 개발 (관리자)
- Transactional Outbox Pattern, CDC
- k8s 위에서 운영 CNA, IaC
2.2 2차 대용량 트래픽 처리 구조로 확장
- 캐시, 분산락
- RTB 구현
- Sharding (Impression)
- 지표 분석 및 CQRS (MongoDB or Clickhourse)
2.3 3차 대용량 트래픽 처리 성능 확장
- 멀티모듈, 모노 레포
- 데이터레이크하우스
- ML 적용
- CDC, Steraming, Sharding 처리 방식, 기술 변경
3. Next?
도메인 모델링을 진행하고, Spring, NextJS 를 활용해 초기 버전을 개발할 에정입니다. 올해 안에 마무리하는 것이 목표이기 때문에 열심히 개발해보겠습니다.
혹시 구조가 이상하거나 개선할 수 있는 부분이 보이신다면 가감없이 댓글로 조언 부탁드립니다.
감사합니다:)
댓글