피드로 돌아가기
Dev.toInfrastructure
원문 읽기
130만 세션 리플레이 처리를 위한 Monolithic 구조의 분산 아키텍처 전환
How we scaled to 1.3 MILLION Session Replays
AI 요약
Context
단일 노드 K3s 클러스터 기반의 Monolithic Ingestion 구조로 인한 확장성 한계 직면. 트래픽 급증 시 Cloudflare의 DDoS 오탐지로 인한 데이터 유실 및 단일 노드 CPU Max 도달에 따른 시스템 불능 상태 발생.
Technical Solution
- API Pod의 역할을 Handshake 전담으로 제한하고 Postgres(PgBouncer) 기반의 Durable Row 생성으로 상태 관리 분리
- 고부하 Client Upload 트래픽을 전담하는 Upload Relay 계층을 구축하여 Core API 리소스 고갈 방지
- In-memory Task 관리 체계를 Postgres 기반 Durable Queue로 전환하여 Pod 재시작 시에도 작업 연속성 보장
- 워크로드 특성에 따라 가벼운 메타데이터 처리(ingest-workers)와 무거운 스크린샷 처리(replay-workers)로 Worker Deployment 분리
- HA Postgres 및 Redis 구성과 자동 Failover 도입을 통한 단일 지점 장애(SPOF) 제거
- S3 버킷의 5천만 객체 제한 해결을 위해 Postgres 기반의 Dynamic Multi-bucket Topology 및 Weighted Traffic Splitting 구현
실천 포인트
- 트래픽 급증 시 Edge 보안 솔루션의 False Positive 가능성 검토 및 API 전용 Bypass 필터 준비 - Worker Pod의 가용성 보장을 위해 In-memory 큐 대신 Database 기반의 Durable Queue 도입 검토 - 클라우드 스토리지의 물리적 객체 수 제한을 대비한 Multi-bucket 라우팅 테이블 설계 - 처리 비용이 다른 작업들을 서로 다른 Deployment로 분리하여 리소스 격리 및 독립적 스케일링 적용