Introduction

Feature JavaScript (JS) TypeScript (TS)
Type System Dynamic Static + Dynamic
Compilation Interpreted (runtime) Compiled to JS (transpile)
Type Checking No Yes (compile-time)
IDE Support Basic Advanced (IntelliSense, etc.)
Learning Curve Easy Slightly higher
Community Very large Large, growing
Ecosystem Huge Uses JS ecosystem
Error Catching Runtime Compile-time + Runtime
Annotation Not required Optional (but recommended)
OOP Support Prototype-based Class-based (ES6+), Interface
Install.sh
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
Read more »

Introduction

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

Read more »

광고 클릭 이벤트 집계

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)
Read more »

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

지표 (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
Read more »

분산 메세지 큐

  • 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
Read more »