다량의 트래픽이 들어올 때 처리 방안
기본적으로 웹 계층과 DB 계층을 나누어서 생각한다.
1. 웹 계층의 경우에
로드밸런서와 웹 서버의 수평적 확장을 통해 해결한다.
여기서 로드밸런서는 Public IP로 외부에 노출된 상태고, 내부 웹 서버는 Private IP로 외부로부터 보호한다.
2. DB 계층의 경우에
다중화를 통해 해결한다.
다중화는 Master와 Slave 구조로 나누어 고려한다.
대부분의 웹 어플리케이션은 Read 연산이 많다. 따라서 여러 대의 Slave를 통해 병렬적으로 질의할 수 있도록 한다.
Master에서는 Write연산을 진행하면 나머지 DB와 데이터 동기화 작업을 수행한다.
이렇게 될 경우 아래와 같은 이점을 얻을 수 있다.
- 성능
- 안정성 (서버가 유실 됐을 때)
- 가용성
하나가 다운된다면?
만약 Master 서버가 다운된다면?
일시적으로 Slave가 Master로 될 것이다.
그런데 이 경우 데이터가 최신 상태가 아닐 수 있다.
이 경우는 복구 스크립트나 마스터의 다중화를 통해 해결할 수 있다.
만약 Slave 서버가 다운된다면?
만약 한 대 뿐이라면 단순히 Master로 갈 것이고, 여러 대라면 나머지 서버가 다운된 서버를 대체할 것이다.
데이터 용량이 과도할 때
DB 스펙 자체를 늘리는 수직적 확장 방법도 있지만, 수평적 확장 방법인 샤딩도 고려해볼 수 있다.
샤딩 구성
DB를 여러 대의 서버로 구성한다. 이 때 각 서버에는 데이터의 중복이 일어나지 않는다. 이 때 샤딩 키(파티션 키)의 역할이 중요해진다. 키를 바탕으로 어느 DB 서버에 저장될 지 결정되기 때문이다. 만약 키가 균일하게 분배하지 못한다면 아래와 같은 현상이 나타날 수 있다.
샤딩 시 발생할 수 있는 상황
(1) 데이터의 재샤딩
하나의 샤드에서도 데이터의 양을 감당할 수 없을 때, 재 샤딩을 고려해야 한다. 이럴 때어떻게 다시 분배할 건지를 고려해야 하며, 안정 해시 방법이 존재한다.
(2) 유명인사 문제 (핫스팟 키 문제)
데이터 자체는 고르게 분배한 것처럼 보이나, 특정한 키워드로만 트래픽이 몰리는 문제.
예를들어 연예인의 이름을 저장하는데 더 유명 연예인의 경우 트래픽이 더 몰릴 수 있다. 이경우
(3) 조인문제
샤딩할 경우 조인하게 되면 어려움이 존재한다. 이를 해결할 수 있는 방법 중 하나는 데이터베이스를 비정규화하여 1개의 테이블에서 질의를 수행할 수 있도록 하는 것이다.
읽기 성능을 향상 시켜야 할 때
캐싱을 통해 달성한다.
- 값 비싼 연산
- 자주 참조되는 데이터
위 2가지 상황에서 캐시는 바람직하다.
- DB 부하 감소
- 캐시 계층 자체로 독립적으로 확장 가능성
캐싱을 도입 시 아래와 같은 요소를 고려해야 한다.
1. 어떤 Data를 캐싱할건지
변경이 빈번하게 일어난다면 수정하는 비용이 더 크다.
2. Data의 일관성
캐싱된 데이터와 실제 데이터 저장소와 데이터 일치하지 않는 상황이 발생 할 수 있다.
3. Data의 방출 방법
캐싱 공간이 꽉 찼을 때, 어떤 데이터를 방출할 것인가?
LRU(오래된 거), LFU(빈도 수), FIFO를 고려해볼 수 있다.
4. Data의 만료
캐싱 영역에 보관될 Data에 대해 Expire 기간을 설정하는 것이 바람직하다. 왜냐하면 캐시에 계속 남게 되므로 다른 문제를 발생시킬 수 있다.
5. SPOF 방지
캐시 서버를 한 개만 두면 단일 장애 지점이 되므로 여러 대로 분산해야 안정적으로 운용 할 수 있다.
+ 또 공부해볼 것 - 여러 상황에서의 캐싱 전략
출처
"가상 면접 사례로 배우는 대규모 시스템 설계 기초" - (알렉스 쉬)
오래걸리거나 비싼 연산이 존재하는데 처리량을 늘리고 싶을 때
메시지 큐로 이를 해결 할 수 있다.
메시지 큐는 기본적으로 데이터의 무손실을 보장하는 비동기 통신를 지원하는 컴포넌트다.
이 컴포넌트를 추가함으로써 서비스 간 coupling을 낮출 수 있다. 이 말은 서비스가 일단 메시지 큐로 보내놓고 그 이후 연산을 진행하게 되고, Publisher가 Consumer가 아니라 메시지 큐만 바라보기 때문이다.
적합한 상황
적합한 상황이 어떤 웹 요청을 처리하는데 외부 API를 호출해야 하는 부분, 혹은 이미지 프로세싱 처럼 연산이 많을 때
이럴 때 작업을 메시지 큐에 넣어놓고 비동기적으로 작업을 완료한다.
응답속도에 미치는 영향
네트워크 지연과 DB 지연
네트워크 지연은 네트워크에 보내는 데이터 양 자체를 압축을 통해 줄여야 한다.
DB 지연은 Disk의 물리적 행위이기 때문에 느릴 수 밖에 없다. 이 경우도 읽는 양 자체를 줄여야 한다.
예를 들어 인덱스를 태우더라도 무조건 빠른게 아니라 읽어오는 양 자체가 많으면 느리다.
