Introduction

1
2
3
4
5
6
7
8
9
10
11
12
13

$ npm install -g typescript
$ npm init -y
Wrote to /path/to/package.json:
...
$ tsc --init
Created a new tsconfig.json with:
  target: es2016
  module: commonjs
  strict: true
  esModuleInterop: true
  skipLibCheck: true
  forceConsistentCasingInFileNames: true
You can learn more at https://aka.ms/tsconfig

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와 비교하여 지원 기능이 점점 비슷해져 차이가 희미해짐