[22일차] | 대규모 시스템 설계 기초2 | 책너두

주요 사용 사례

• 사례 1. 클릭 이벤트 수 집계
• 사례 2. 가장 많이 클릭된 상위 N개 광고 반환
• 사례 3. 데이터 필터링
  • 스타 스키마(Star Schema)
    • 데이터를 필터링 기준에 따라 사전 집계
    • 별도의 컴포넌트 추가 없이 기존의 집계 서비스를 사용할 수 있다.
    • 그러나 수많은 버킷과 레코드가 생성되므로 데이터 용량이 증가한다.

3단계: 상세 설계

• 주요 개념
  • 스트리밍 vs 일괄 처리
  • 시간과 집계 윈도우(aggregation window)
  • 전달 보증(delivery guarantee)
  • 시스템의 규모 확장
  • 데이터 모니터링 및 정확성
  • 최종 설계 다이어그램
  • 결함 내성(fault tolerance)

스트리밍 vs 일괄 처리

• 현재까지 설계한 아키텍처는 기본적으로 스트리밍 처리를 기반으로 한다.

람다 아키텍처 vs 카파 아키텍처

• 람다 아키텍처는 스트리밍 처리와 일괄 처리를 모두 지원한다.
  • 이를 위해 스트리밍용, 일괄 처리용 코드로 나뉜 두 벌의 코드를 작성해야 한다.
• 카파 아키텍처는 이 두 경로를 하나의 스트리밍 파이프라인으로 처리한다.

데이터 재계산

• 버그 수정 등의 이유로 기존 데이터를 재계산하는 경우가 발생 할 수 있다.
• 재계산의 흐름
  • 재계산시에는 원시 데이터를 직접 읽어서 처리한다.
    • 메시지 큐를 별도로 사용하지 않는다.
  • 추출된 데이터는 재계산을 위한 별도의 집계 서비스로 전달되어 처리한다.
    • 실시간 처리 과정과 간섭하는것을 방지하기 위함이다.
  • 집계 결과는 두번째 메시지 큐로 전달되어 DB에 저장된다.

시간

• 집계를 할 때, 사용가능한 시간의 선택지는 크게 두개 주어진다.

  • 이벤트 시각: 이벤트가 발생한 시각
  • 처리 시각: 집계 서비스가 이벤트를 처리한 시각

• 이 두 시간 사이에는 필연적으로 지연이 발생한다.

  • 때로는 네트워크 문제 등으로 인해 굉장히 큰 지연이 발생할 수 있다.

  • 이로인해 아래와 같은 장단점이 발생한다.

    구분	장점	단점
    이벤트 시각	- 데이터 정확성 보장	- 클라이언트의 시간이 잘못 설정되었거나, - 악성 사용자가 데이터를 조작하는 경우 문제 발생
    처리 시각	- 서버에서 처리하므로 안정적임	- 데이터 정확성 떨어짐

  • 대체로는 이벤트 발생시각을 사용하는 것이 좋다.

• 지연으로 인한 데이터 정확도 하락을 최소화 하기위해 워터마크를 사용한다.

  • 워터마크
    • 집계 윈도우의 종료 시각을 확장한다.
    • 이를 통해 처리시각이 이벤트 발생시각보다 늦어지는 경우에도 좀 더 정확하게 데이터를 처리할 수 있다.

집계 윈도우

• 집계 윈도우의 종류에는 아래와 같이 네 가지가 있다.
  • 텀블링 윈도우(Tumbling Window) 혹은 고정 윈도우(Fixed Window)
  • 호핑 윈도우(Hopping Window)
    • 고정 윈도우가 일정 단위시간 간격으로 이동하는 윈도우
  • 슬라이딩 윈도우(Sliding Window)
    • 실시간으로 이동하는 윈도우
  • 세션 윈도우(Session Window)
    • 특정 이벤트의 발생이나 타임아웃 등을 기준으로 정의되는 윈도우