Introduction

LLM이 발전하면서 distributed training, serving이 점점 더 중요해지고 있다.
분산 환경에서 cluster 간 통신은 필수적이고, 저지연/고처리량 network가 핵심이다.
PyTorch, DeepSpeed, vLLM 등 다양한 framework로 쉽게 구현할 수 있지만 (물론,,, 처음엔 삽질을…), 이러한 기술들의 이해도를 높히기 위해 본 글을 작성한다.

광고 클릭 이벤트 집계

Ad click event aggregation system: A system designed to collect, process, and analyze data related to ad click events. It ensures real-time processing and accuracy of data, crucial for digital advertising processes like Real-Time Bidding (RTB), where transactions must be completed within a second.

• RTB (Real-Time Bidding): Digital 광고의 핵심 process, 실시간 경매 절차를 통해 지면 (inventory) 거래
  • 1초 내에 모든 process가 마무리 돼야 함
• Ad click event aggregation
  • Online 광고가 얼마나 효율적이었는지 측정하는 데 결정적 역할 $\rightarrow$ 광고주가 얼마나 많은 돈을 지불할지 영향
  • 결과에 따라 광고 campaign 관리자는 광고 예산을 조정하기도 하고, target group이나 keyword를 변경하는 등 광고 전략을 수정하기도 함
  • 핵심 지표: CTR (Click-Through Rate), CVR (Conversion Rate)

지표 모니터링 및 경보 시스템

지표 (metrics) monitoring 및 경보 (alerting) system: Infra의상태를 선명하게 볼 수 있도록 하여 높은 가용성과 안정성을 달성하는 데 중추적 역할 수행

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

• 개략적 요구사항 및 가정
  • 대규모 infra를 monitoring 해야 함
    • 일간 능동 사용자 수 1억 명 (100 million)
    • Server pool 1,000개, pool당 server 수 100개의 운영 지표 수집 가정
      $\rightarrow$ Monitoring 지표의 수: 약 1,000만개
    • Data 보관 기간: 1년
      • 수집한 raw data 7일 보관
      • 1분 단위 data로 변환 후 30일 보관
      • 1시간 단위 data로 변환 후 1년 보관
  • Monitoring 지표 예시
    • CPU 사용률
    • 요청 수
    • Memory 사용량
    • Message queue 내의 message 수
• 비기능 요구사항 및 제약사항
  • 규모 확장성: 늘어나는 지표 수 및 경보 양에 맞게 확장 가능
  • 낮은 응답 지연: Dashboard와 경보 (alert)를 신속하게 처리할 수 있도록 query에 대한 낮은 응답 지연 보장
  • 안정성: 중요 경보를 놓치지 않도록 높은 안정성 보장
  • 유연성: 기술 변화에 따라 유연한 통합 가능
  • Log monitoring 또는 분산 (distributed) system 추적 (tracing)은 고려 X

분산 메세지 큐

• Advantages
  • 결합도 완화 (decoupling): Component 사이의 강한 결합이 사라지므로 각각 독립적 갱신 가능
  • 규모 확장성 개선: Message queue에 data를 생산하는 생산자 (producer)와 queue에서 message를 소비하는 소비자 (consumer) system 규모를 traffic 부하에 맞게 독립적으로 scale out 가능
  • 가용성 개선: System의 특정 component에 장애가 발생해도 다른 component는 queue와 계속 상호작용 가능
  • 성능 개선: 손쉬운 비동기 통신 가능 ($\because$ producer는 응답을 기다리지 않고 message 생산, consumer는 읽을 message가 있을 때 소비)
• Message queue vs. Event streaming platform
  • Apache Kafka와 Pulsar는 message queue가 아닌 event streaming platform
  • RocketMQ, ActiveMQ, RabbitMQ, ZeroMQ와 같은 message queue와 비교하여 지원 기능이 점점 비슷해져 차이가 희미해짐

Feature	Message Queue (e.g., RabbitMQ, ActiveMQ)	Event Streaming Platform (e.g., Kafka, Pulsar)
Primary Use Case	Decoupling producers and consumers	Real-time data streaming and processing
Message Retention	Short-term, until consumed	Long-term, configurable retention
Message Ordering	FIFO (First In, First Out)	Partition-based ordering
Scalability	Limited, vertical scaling	High, horizontal scaling
Throughput	Moderate	High
Latency	Low	Low to moderate
Fault Tolerance	Basic	Advanced, with replication
Consumer Model	Push-based	Pull-based
Use Case Examples	Task queues, notification systems	Log aggregation, real-time analytics

구글 맵

Google Maps: 위성 이미지, 거리 뷰, 실시간 교통 상황, 경로 계획 등 다양한 서비스를 제공하고 있다.

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

아래 세부 사항은 가상 면접관과의 대화를 통해 문제를 이해하고, 설계 범위를 정의한 내용이다.