Key Points

일종의 노트 개념으로 핵심 포인트만 모아봅니다.

지표

• 규모 확장성 (서버 1대 → N대), 고가용성 (high availability)
  • 다중화 (replication)
  • 샤딩 (sharding)
    • 작업 대상 데이터의 양을 줄일 수 있다
    • 샤딩 정책 - 데이터를 서버마다 균등하게 배분하는 방법 고안
• 동시성
  • 이중화/다중화
    • 무상태 (stateless)하게 유지
  • 동기화
    • 동기화 충돌
      • 버저닝
• 일관성
  • RDB - ACID 보장
  • NoSQL - ACID 기본 지원하지 않음, 프로그래밍 로직으로 대체
• 응답 속도
  • 시스템의 응답 속도: ~100ms

요구사항

일간 능동 사용자는? 매일 평균 몇 건의 작업을 수행하는지/평균 소비하는 시간이 얼마인지? 각 작업마다 평균 몇 바이트의 데이터가 필요한지?

트래픽 규모

• 일별 능동 사용자 수(DAU: Daily Active User)
  • 5천만(5M)?
• 인원 제한은 어느 정도로 해야 하는지?
• 동시 접속자 수
  • 동시 접속자 수 x 접속 당 필요한 서버 메모리 = 접속에 필요한 서버 메모리
• CDN (Content Delivery Network)
  • 캐시
  • 국가/지역별 센터에 배치하여 사용자 근거리로 지정해 응답 지연 개선

QPS (Query Per Second)

초당 몇 번의 질의가 들어오는지를 구한다.

최대 QPS ~= QPS * 2

데이터 보관 기간

• 내용/길이 제한
• 보관 기한 (10년, … 영원히)
• 공간 절약 (p.296)
  • 중복 제거(de-dupe) - 두 블록이 같은 블록인지 해시값으로 판단
  • 지능적 백업 전략
    • 한도 설정
    • 중요한 버전만 보관
  • 아카이빙 저장소(cold storage) - 자주 쓰이지 않는 데이터는 아카이빙 (e.g., AWS S3 Glacier)

응답 지연 (Latency)

몇 ms 안에 처리해야하는지?

클라이언트

지원 기기

모바일 앱 / 웹(브라우저) / 스마트 TV / …

데이터 관련

• 암호화
• 데이터 유형
  • RDBMS
    • 일반적인 데이터
    • 데이터 가운데 롱 테일(long tail)에 해당하는 부분을 잘 처리하지 못함.
    • 인덱스가 커지면 데이터에 대한 무작위 접근(random access)을 처리하는 비용이 늘어남.
      • e.g., 특정 사용자가 언급된 메시지를 보거나, 특정 메시지로 점프(jump)하여 무작위한 데이터 접근을 하는 경우
  • NoSQL - 자유로움
  • Key-Value Store
    • 수평적 규모확장(horizontal scaling)이 쉬움
    • 데이터 접근 지연 시간(latency) 낮음
    • 많은 안정적인 채팅 시스템이 채택
      • Facebook Messenger - HBase
      • Discord - Cassandra

캐싱 (Caching)

• 캐시 미스(cache miss) (p.238)
  • 데이터가 캐시에 없는 경우
  • 캐시 서버의 메모리가 부족할 경우
  • 캐시 서버에 장애가 있을 경우
• 브라우저 캐싱(browser caching) (p.239)
  • cache-control 응답 헤더 활용
  • e.g., 구글 검색 엔진

추가 논의 / 처리 기법 / 키워드

• 다양한 파일 유형 (확장성)
  • 원본 저장소(original storage) (p.252)
    • 대형 이진 파일 저장소(BLOB: Binary Large Object storage) - 이진 데이터를 하나의 개체로 보관하는 데이터베이스 관리 시스템
• 종단간 암호화
• 안전성
• 성능 개선 (p.267)
  • CDN
  • 병렬화 - 느슨하게 결합된 시스템 만들기 (e.g., 메시지 큐)
• 오류 처리
• 다국어 지원
• 스트림 프로세싱
  • 아파치 하둡 맵리듀스(Apache Hadoop MapReduce)
  • 아파치 스파크 스트리밍(Apache Spark Streaming)
  • 아파치 스톰(Apache Storm)
  • 아파치 카프카(Apache Kafka)
• 안정 해시
• 블룸 필터
• 메세지 큐
• 오류 처리 (p.272)
  • 회복 가능 오류(recoverable error) - 몇 번 더 시도(retry)하면 해결된다. 복구 어려우면 오류 코드 반환
  • 회복 불가능 오류(non-recoverable error) - 중단 후 오류 코드 반환
• 로드 밸런싱
  • 로드 밸런서(load balancer): API 서버 각각으로 고르게 요청을 분산하는 역할
  • 로드밸런서끼리 박동(heart) 신호를 주기적으로 보내서 상태를 모니터링 (p.297)
• 트라이 (Trie) (p.229)
• 데이터 샘플링 (p.239)
• 롱테일 (p.271)

ID 생성 방식 (Ch.7 - 분산 시스템을 위한 유일 ID 생성기 설계)

• base64 (요구사항에 따라 base62 등 다양)
• UUID
• 스노우플레이크 - 전역적 64-bit 순서 번호(sequence number) 생성기
• 지역적 순서 번호 생성기 (local sequence number generator) - ID의 유일성은 같은 그룹(e.g., DB 파티션) 안에서만 보장

서비스 탐색 (Service Discovery)

• 기준
  • 클라이언트의 위치(geographical location)
  • 서버의 용량(capacity)
• 솔루션
  • 아파치 주키퍼(Apache Zookeeper) - 사용 가능한 서버를 등록시켜두면 클라이언트가 접속을 시도하면 사전에 정한 기준에 따라 최적의 서버를 골라준다.

개념

SPOF (Single Point of Failure)

• 해당 서버가 죽으면 해당하는 전체 서비스가 중단, 최악의 경우 다른 서비스까지 중단
• 해결법: 다중화
• 서버 1대는 지양해야 함

채팅

• 양방향 통신
  • 폴링(polling)
  • 롱 폴링(long polling)
    • Dropbox
  • 웹소켓(WebSocket)
• 상태 유지 서비스 (웹소켓)
• 접속 상태 관리
  • 접속 장애
    • 박동(heartbeat) 검사
      • 마지막 이벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 접속 상태를 온라인으로 유지, 그렇지 않으면 오프라인
      • e.g., 매 5초바다 박동 이벤트를 보내고, 30초 동안 아무런 메시지를 받지 않으면 오프라인으로 변경

비디오 스트리밍 (Ch.14)

• 비디오 트랜스코딩 (p.253) - 비디오 인코딩이라고 부르기도 하는 절차로, 비디오의 포맷(MPEG, HLS 등)을 변환하는 절차. 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림을 제공하기 위해 필요.
• 스트리밍 프로토콜(streaming protocol) (p.256)
  • 비디오 스트리밍을 위해 데이터를 전송할 때 쓰이는 표준화된 통신 방법
  • 널리 쓰이는 방식
    • MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP)
    • Apple HLS (HTTP Live Streaming)
    • Microsoft Smooth Streaming
    • Adobe HTTP Dynamic Streaming (HDS)
  • 프로토콜마다 지원하는 비디오 인코딩이 다르고 플레이어도 다르다. 따라서 서비스의 용례에 맞는 프로토콜을 선택해야 한다.