Discord가 수조 개의 메세지를 인덱싱하는 방법

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

인프라/DevOps/보안

대상자

• *대상자_정보**: 클라우드 인프라/DevOps 엔지니어, 대규모 분산 시스템 설계자, Elasticsearch 및 Kubernetes 사용자
• *난이도**: 고급 (대규모 시스템 아키텍처, 분산 처리, 자동화 기술 이해 필요)

핵심 요약

• Redis → PubSub 전환으로 메시지 유실 방지 및 확장성 향상
• Elasticsearch 셀(Cell) 아키텍처 도입: 목적별 데이터 분리, 수평 확장, 장애 복구 자동화
• 쿠버네티스 + ECK 활용: 자동 리소스 관리, 무중단 업그레이드, 실시간 확장 처리

섹션별 세부 요약

1. 기존 아키텍처 문제점

• Redis 기반 메시지 큐: 과부하 시 메시지 유실, 단일 노드 장애 시 40% 작업 실패
• 대규모 Elasticsearch 클러스터: 200+ 노드 관리 부담, Lucene 20억 문서 제한

1. 메시지 라우터 구현

• Rust 기반 비동기 처리: tokio::task::spawn 활용, 메시지 그룹화 및 병렬 처리
• 목적지별 인덱싱: Guild, DM, BFG 셀 분리, 쿼리 성능 최적화

1. 셀(Cell) 아키텍처 구성

• Guild 셀: Guild ID 기준 샤딩, 단일 샤드 인덱스 사용
• DM 셀: 사용자 ID 기준 샤딩, 이중 인덱싱 적용
• BFG 셀: 다중 샤드 인덱스, Lucene 20억 문서 제한 극복

1. 쿠버네티스 자동화

• ECK(Enterprise Kubernetes for Elasticsearch) 도입: 클러스터 토폴로지 선언적 정의, OS 업그레이드 자동화
• HPA 구성 예시: CPU 사용률 70% 기준 Pod 추가/제거, 클러스터 Autoscaler 기반 노드 확장/축소

1. 분산 처리 및 안정성 강화

• 샤딩 전략: 일반 서버(Guild)는 단일 샤드, BFG 서버는 ceil(메시지 수 / 10억) 샤드 할당
• 복제본 구성: 프라이머리 샤드 + 2개 레플리카, 가용성 영역(zone) 기반 분산
• 낙관적 동시성 제어: PUT /guild-messages/message/12345?version=3 활용, 버전 관리로 데이터 충돌 방지

1. 성능 향상 지표

• 메시지 인덱싱 처리량: 50만 → 120만 건/분
• 평균 쿼리 응답 시간: 500ms → <100ms
• P99 응답 시간: 1초 → <500ms
• 인덱스 규모: 제한적 → 수조 개 메시지 지원

1. 장애 복구 프로세스

• 쿠버네티스 노드 장애 감지 → Pod 재스케줄링 → Elasticsearch 복제본에서 데이터 복구 → 서비스 무중단 유지

결론

• 핵심 구현 방법:

1. PubSub으로 메시지 유실 방지, Elasticsearch Cell 아키텍처로 수평 확장 및 장애 복구 자동화
2. Rust 기반 메시지 라우터: 병렬 처리, 메시지 그룹화, Elasticsearch에 일괄 인덱싱
3. Kubernetes + ECK 통한 자동화: HPA, 클러스터 Autoscaler, 무중단 업그레이드

• 실무 팁:

- 대규모 분산 시스템 설계 시 수많은 작은 클러스터보다 수평 확장 가능한 아키텍처 선택

- 메시지 보장 위해 PubSub 시스템 도입, Rust 활용한 고성능 처리

- Elasticsearch의 분산 기능과 쿠버네티스 자동화 결합으로 확장성 및 안정성 극대화

- 샤딩과 복제본 전략을 통해 데이터 가용성 및 처리 성능 최적화