Phase 8레슨 37
Uber 아키텍처
Dispatch, Geospatial Index, Surge Pricing, Trip Lifecycle — 실시간 매칭
💡ELI5·
택배 배정과 Uber 매칭
승객 호출 → 위치를 격자(H3)로 변환 → 인접 격자의 가용 드라이버 조회 (Redis Geo) → 거리/ETA 정렬 → 가장 가까운 드라이버에게 전송 → 드라이버 수락 → 매칭 완료 → 실시간 위치 추적 (WebSocket) → 도착 → 결제 → 평점 → 트립 종료
💡 비유 — 택배 배정. 고객(승객)이 호출하면 가장 가까운 기사(드라이버)를 배정. 도시를 격자로 나누고, 각 격자에 있는 기사를 실시간으로 추적. 수요가 많은 격자는 할증(Surge).
🔬Deep Dive·
H3 Hexagonal Grid
사각형 격자: 육각형 격자 (H3): ┌──┬──┐ ⬡⬡⬡ │ │ │ ⬡⬡⬡⬡ ├──┼──┤ ⬡⬡⬡ │ │ │ 인접 격자 간 거리 균일 └──┴──┘ 반경 검색 정확 H3: 지구를 육각형으로 분할 (해상도 선택 가능) → 격자 ID로 드라이버/수요를 인덱싱
🔬Deep Dive·
트립 라이프사이클
| 단계 | 이벤트 | 시스템 |
|---|---|---|
| 호출 | 승객이 목적지 입력 | Trip Service |
| 매칭 | 가까운 드라이버 탐색 | Dispatch + Redis Geo |
| 수락 | 드라이버가 수락 | Matching Service |
| 이동 | 실시간 위치 추적 | WebSocket + Kafka |
| 완료 | 도착, 결제 | Payment Service |
| 평가 | 상호 평점 | Rating Service |
⚖️Trade-off·
Uber의 아키텍처 Trade-off
| 선택 | 이점 | 대가 |
|---|---|---|
| Microservices (2000+) | 독립 배포/확장 | 관측성, 일관성 복잡 |
| H3 격자 | 정확한 지리 검색 | 격자 시스템 학습 비용 |
| 이벤트 소싱 | 장애 복구 가능 | 이벤트 로그 저장 비용 |
| 실시간 Surge | 수요/공급 균형 | 가격 변동에 대한 사용자 불만 |
❓ 체크포인트 질문
- 1.Uber가 Geospatial Index에 Hexagon을 사용하는 이유는?
- 2.실시간 매칭에서 가까운 드라이버를 찾는 방법은?
- 3.Surge Pricing이 실시간으로 어떻게 계산되는가?
- 4.Uber가 Microservices로 전환한 이유는?
- 5.트립 진행 중 장애가 나면 어떻게 복구하는가?