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)
프로토콜마다 지원하는 비디오 인코딩이 다르고 플레이어도 다르다. 따라서 서비스의 용례에 맞는 프로토콜을 선택해야 한다.
Last updated