사용자 수에 따른 규모 확장성
단일 서버
웹, 앱, 데이터베이스, 캐시가 모두 한 대 서버
DB 분리
로드밸런서(부하 분산)
데이텁메이스 다중화
마스터: 쓰기
슬레이브: 읽기
(마스터 변경 내역은 슬레이브에 즉시 반영)
캐시
자주 참조되는 데이터를 메모리 안에 보관
즉, DB로 요청을 보내지 않고 캐시 계층에서 데이터 반환
대표적으로 memcachedAPI
고려 사항
- 캐시 메모리 크기
- 데이터 방출 정책(캐시가 차 버린 경우)
SECONDS = 1
cache.set('myKey', 'hi there', 3600 * SECONDS)
cache.get('myKey')콘텐츠 전송 네트워크(CDN)
지리적으로 분산된 서버의 네트워크
정적 콘텐츠 전송 목적
이미지, 비디오, CSS, JavaScript 파일 등 캐시
동적 콘텐츠 캐싱도 가능한데 나중에 다룸
요약하면 요청에 따라 HTML 페이지 캐시
대표적으로 클라우드프론트, 아카마이
TTL에 따라 만료되지 않은 요청을 CDN에서 처리됨
고려 사항
- CDN 입출에 따라 데이터 전송 요금 부과, 자주 사용되지 않는 콘텐츠 캐싱은 이득 크지 않음
- 적절한 TTL 중요
- CDN 장애 시 대처 필요
- 콘텐츠 무효화 방법
무상태(stateless) 웹 계층
바람직한 건 상태 정보를 DB와 같은 지속성 저장소에 보관, 필요할 떄 가져오는 것
이렇게 구성된 걸 무상태 웹 계층이라고 함.
상태 정보가 서버가 아닌 외부 DB에서 관리하도록 하는 것
(sql, nosql 뿐만 아니라 redis와 같은 캐시 시스템도 가능)
데이터 센터
동일 인프라를 각각 지리적으로 다른 인프라에 구성
상태 정보만 동일 DB에서 관리하면 됨.
메시지 큐
무손실을 보장하는 비동기 통신 컴포넌트
생산자(발행자)와 소비자가 존배
생산자 -> [메시지 큐] -> 소비자
생산자는 메시지 큐에 발행하며, 소비자는 메시지큐를 구독하고, 메시지는 소비자에 의해 소비된다.
소비자는 메시지 큐를 구독한다.
메시지 큐 별도 작업 서버가 필요함.
로그, 메트릭, 자동화
로그: 에러 로그 등
메트릭: CPU, 메모리, 디스크I/O, DB 성능, 캐시 성능, DAU, 수익, 리텐션(재방문) 등
자동화: CI/CD
데이터베이스 규모 확장
수직적 확장: 자원 증설, 한계가 있음
수평적 확장: 서버 증설, 샤딩이라고 함.
샤딩: DB를 샤드(shard)라고 부르는 작은 단위로 분할
모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이에는 중복이 없음
샤드는 조각, 파편이라는 뜻
일종의 해싱으로 특정 트래픽은 특정 DB에 저장
고려 사항
- 샤딩 키(파티션 키): 데이터가 어떻게 분산될지 정하는 하나 이상의 칼럼(예 user_id)
- 재샤딩: 특정 샤드가 모두 소모되면 샤드 소진(shard exhaustion) 샤드 키 계산 함수 변경 필요
- 유명인사(celebrity) 문제: 핫스팟 키 문제, 특정 샤드에 질의가 집중(저스틴 비버와 같은 조회가 몰리는 경우)
- 조인과 비정규화: DB를 여러 샤드로 쪼개면 조인이 힘들어짐. DB를 비정규화해서 조인이 아닌 한 번의 쿼리로 처리할 수 있음.
백만 사용자, 그 이상
특별한 전략이 필요
기본을 기억하기
- 웹 계층은 무상태 계층
- 모든 계층 다중화
- 가능한 많은 데이터 캐시
- 여러 데이터 센터 지원
- 정적 콘텐츠는 CDN
- 데이터 계층은 샤딩을 통해 확장
- 각 계층은 독립적 서비스로 분할
- 시스템 지속적인 모니터링, 자동화 도구
개략적인 규모 추정
2의 제곱수
2^10 1KB
2^20 1MB
2^30 1GB
2^40 1TB
2^50 1PB
고가용성
시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력
처리율 제한 장치 설계
별도 미들웨어 서버를 두고, 레디스 등에 기록해서 씀.
락은 시스템의 성능을 상당히 떨어뜨린다.
안정 해시 설계
서버 수가 달라지면(해시 함수 변경) 캐시 미스 문제 발생
안정 해시: 해시 테이블 크기가 조정될 때 평균적으로 오직 k/n개의 키만 재배치하는 해시 기술
k는 키의 개수, n은 슬롯 개수
(반대: 전통적 해시 테이블은 슬롯의 수가 바뀌면 거의 대부분 키를 재배치 함)
안정 해시는 모듈러 연산이 아님. 해시 링에 배치.
서버가 추가/삭제되도 일부 키만 재배치 됨
키-값 저장소 설계
CAP 정리
데이터는 일관성, 가용성, 파티션 감내성 세 가지 요구사항을 도시에 만족시키는 분산 시스템 설계 불가능
유일 ID 생성기
- 다중 마스터 복제
- UUID
- 티켓 서버
- 트위터 스노플레이크 접근법
URL 단축키 설계
이런 식으로 개략적으로 추정하기!
