대용량 트래픽과 데이터 처리를 위해 공부할 내용

대용량 트래픽 & 데이터 처리

예상치 못한 트래픽 처리, MAU가 늘어난 대규모 서비스 등 E-commerce Business의 핵심은 트래픽과 데이터이다.

각 단의 역할

실제 비즈니스에서 발생한 예기치 못한 트래픽에 자유자재로 대응할 수 있는 능력을 키우려면, 각 단계에서 사용할 수 있는 처리 방법을 모두 알고 있어야 한다.

어플리케이션 단

• 코드베이스 분석
  • Codebase: 프로그램의 완전한 소스코드. 보통 사람이 쓴 코드만 포함
• 모듈화 및 구조 개선
• 성능 최적화

데이터베이스 단

• 쿼리 최적화
• 정규화 및 역정규화
• 인덱싱

아키텍처 단

• 아키텍처 변경 및 개선
• 오토스케일링
  • 서비스 불능 상황(서버 과부하, 장애 등) 발생 시, 자동으로 서버를 복제하여 서버 대수를 늘려주는 작업을 주는 AWS 서비스 (가용성)
  • 회사의 서버를 일일이 업그레이드 할래? 서버 대수를 일일이 늘릴래? 아니면 클라우드 환경에서 자동으로 늘려지게 할래? -> Auto-Scaling
• CDN(Content Delivery Network)

  • 지리적 제약 없이, 전 세계 사용자에게 빠르고 안전하게 컨텐츠를 전송할 수 있는 기술

    우리나라에 있는 사람이 미국에 있는 서버로부터 이미지나 파일을 다운받으려고 한다면 시간이 오래 걸림. 서버를 분산시켜 캐싱해둠 → 사용자 요청이 들어옴 → 사용자와 가장 가까운 위치에 존재하는 서버로 매핑 → 캐싱된 내용을 내어줌 : 빠른 데이터 전송!

  • Static Caching, Dynamic Caching

  • 활용 사례

    • netflix: 동영상 스트리밍 전세계 제공 업체이므로, 최대한 지연 없이 빠르게 제공하기 위해서는 CDN 기술 필수
    • 온라인 게임의 정식 서비스 시작 시점에, 다운로드 트래픽이 크게 증가하게 되면, 병목 현상이 발생하거나 서버가 다운될 수 있으므로 CDN 활용

EDA: 이벤트 기반 분산처리 아키텍처

요즘 주목받는 아키텍처인 MSA가 적용된 시스템을 EDA가 보완할 수 있다

• Event Driven Architecture란

  • (보통 분산 아키텍처 환경에서) 이벤트를 생성[발행]하고, 발행된 이벤트를 수신자에게 전송하고, 수신자는 그 이벤트를 처리하는 방식
  • 상호 간 결합도를 낮추기 위해 비동기 방식으로 메시지를 전달하는 패턴
  • 주로 Message Broker(Kafka, RabbitMQ)와 결합하여 구성
    • Kafka와 Redis

• 사용 목적

  • 이벤트 기간, 순식간에 몰리는 트래픽에도 안정적인 대용량 트래픽 처리를 위함.
  • 서버가 다운되지 않게 확장성 높고 안정적인 백엔드 서버를 구축할 필요
    • 순간적으로 몰리는 요청을 캐시로 처리
    • 수많은 주문 처리를 Event-Driven 구조로 처리
    • 많은 정보가 대량으로 빠르게 생성+수정+조회될 수 있도록 DB 관리

• 장단점

  • 분산 시스템 간 느슨한 결합도, 시스템 간 의존성 배제, 확장 및 탄력성 향상
  • Message broker 의존성, 시스템 Flow 파악 어렵

MSA 서비스 설계 및 개발

• MSA 구조로 상위 수준(주요 컴포넌트), 하위 수준(각 컴포넌트 별 인터페이스)을 설계

대규모 트래픽을 고려한 구조 개선 EDA

• Kafka: 몰리는 트래픽 분산에 활용
• EDA: 서비스 간 상호작용을 통해 직접적인 의존성 ↓ 처리량의 유연한 확장 유도

Redis 캐싱을 이용한 고성능 검색

• 검색은 Read가 많으며, 이에 캐싱을 적용해 대용량 Serving을 처리
• Redis: 캐시를 유지하여 빠른 조회를 가능케 함
  • Redis의 Caching Strategy

분산형 NoSQL을 이용한 상태 관리(Cassandra)

• 데이터를 Cassandra에 저장하여 대용량 데이터의 빠른 Read/Write 환경에서 부하가 최소화 + 수평 확장에 용이하게 함
  • NoSQL 비교

CDC를 활용한 데이터 무중단 마이그레이션

• 마이그레이션은 보통 기존 레거시 시스템을 신규로 교체하는 상황에서 발생

  • 이때 기술스택이 다를 수 있음
  • 또한 서비스 중단 없이 다수의 데이터를 마이그레이션해야 함
  • 배치성 마이그레이션 || 점진적 마이그레이션

• CDC

서버리스 아키텍처

• 대용량 트래픽을 견딜 수 있도록 서버리스 아키텍처를 적용
  • 서버리스 vs 서버풀(ec2) 서비스의 비용 비교
    • 기능/wordload 단위로 분리한 MSA 구조로 개발
    • 서비스마다 옵션을 다르게 선택해 비용 및 리소스의 효율적 사용
  • 트래픽이 몰렸을 때 처리 방법
    • 예측 가능한 시나리오라면, 서버리스를 통해 대응하자
      (서버풀로 대용량 서버 상시 유지하면, 비용 ↑)
    • 부하 테스트 시 어떤 지표를 봐야할까?
  • Auto-Scaling을 어떻게 구성해야 합리적일까?
    • 예측 불가한 트래픽에 대해 사전 검증 없는 auto-scaling은 위험함. 어떤 전략을 취해야 할까?
    • 완전관리형 서비스에서 제공되는 auto-scaling 방식(Lambda, RDS, DynamoDB, OpenSearch)

백엔드 성능 개선의 핵심, Redis & Kafka

대용량 데이터 & 트래픽 처리 핵심 기술인 Redis와 kafka는, 동일한 기술 스택이더라도 use case에 따라 다르게 사용된다. 언제 Redis를 쓰면 좋고, 어디에 kafka를 쓰면 좋을까?

• Redis
  • Push 기반 시스템 지원
  • 즉각 데이터 전송 & 데이터 손실은 적은 App에 적합
• Kafka
  • Pull 기반 시스템 지원
  • 대규모 데이터셋 스트리밍 & 높은 복구 성능이 필요한 App에 적합

Redis, Kafka + a

실무에서는 처리량, 지연시간, 서비스 구조 등의 요구사항에 맞추어 적절한 DB를 선택하고, 나아가 성능을 높이기 위해 2~3개 이상의 다양한 DB를 조합하여 활용한다.

• Redis + Kafka + Cassandra
• Kafka + Redis(sentinel)

ref) 패스트캠퍼스