호텔 예약 시스템

• Airbnb system 설계
• 항공권 예약 system 설계
• 영화 ticket 예매 system 설계

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

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

• 비기능 요구사항
  • 높은 수준의 동시성 (concurrency): 성수기, 대규모 event 기간에는 일부 인기 hotel의 특정 객실을 예약하려는 고객이 많이 몰릴 수 있음
  • 적절한 지연 시간: 사용자가 예약할 때 응답 시간이 빠르면 이상적이지만 예약 요청 처리에 몇 초 정도 소모되는 것은 괜찮음
• 개략적 규모 추정
  • 총 5,000개 hotel, 100만 개의 객실 가정
  • 평균적으로 객실의 70% 사용, 평균 투숙 기간은 3일로 가정
  • TPS (Transactions Per Second)
    • 일일 예약 건수 $=\frac{10^6\times0.7}{3}=233,333\simeq240,000$
    • 초당 예약 건수 $=\frac{240,000}{10^5}\simeq3$
  • QPS (Queries Per Second)
    • Hotel/객실 상세 page: 사용자가 hotel/객실 정보 확인 (조회 발생)
    • 예약 상세 정보 page: 사용자가 날짜, 투숙 인원, 결제 방법 등의 상세 정보를 예약 전 확인 (조회 발생)
    • 객실 예약 page: 사용자가 ‘예약’ button을 눌러 객실 예약 (Transaction 발생)
    • 대략 10%의 사용자가 다음 단계로 진행, 90%의 사용자는 이탈한다 가정
    • $\therefore$ $3\ (TPS) * 10 * 10 = 300\ (QPS)$

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