1. 사용자 수에 따른 규모 확장성
핵심은 두가지.
웹/모바일 트래픽 증가로 인해 추가 처리 서버 필요. => 웹 서버확장.
데이터 용량 확보가 필요. -> 데이터베이스 서버.
.
🎱 관계형보다 비 관계형 데이터가 더 적합한 경우
- 아주 낮은 응답 지연시간(latency)이 요구됨.
- 다루는 데이터가 비정형(unstructured)이라 관계형 데이터가 아님.
- 데이터(JSON, YAML, XML 등)을 직렬화하거나 역직렬화할 수 있기만 하면 됨.
- 아주 많은 양의 데이터를 저장할 필요가 있음.
🎱 스케일 업 vs 스케일 아웃
스케일 업 = 수직적 규모 확장. 즉, 서버에 고사양 자원(더 좋은 CPU, 더 많은 RAM 등)을 추가
스케일 아웃 = 수평적 규모 확장. 즉, 더 많은 서버를 추가.
스케일 업의 한계점 ?
- 한대의 서버에 (물리적으로) CPU나 메모리를 무한대로 증설할 수는 없음.
- 수직적 규모 확장법은 장애에 대한 Failover나 Redundency 방안을 제시하지 않는다. 즉, 장애나면 서버가 터진다.
결국 대규모 애플리케이션을 지원할 때는 수평적 규모 확장, 즉 Scale-out이 더욱 적합하다.
🎱 로드밸런서
자 이제 스케일아웃을 통해 웹 서버를 다중화 하였다.
이제 앞에 로드밸런서를 두고 public ip로 클라이언트의 접속을 받게 한다.
(즉, 더이상 웹서버는 클라이언트 접속을 직접 처리하지 않는다.)
로드밸런서는 사이에서 중개역할을 하며 private ip로 웹서버와 통신, 부하를 처리한다. 당연히 다수의 웹 서버로 스케일아웃 했기 때문에 failover도 가능하다.
🎱 DB 다중화
통상적으로 write 보단 read가 훨씬 많다.
그러니 MASTER / SLAVE로 DB를 나누고. 각각에 write/ read 연산을 맡기자.
이로 인해 기대할 수 있는 이득은 아래와 같다.
- 더 나은 성능. 병렬로 처리될 수 있는 Query 수가 늘어나므로 성능이 좋아진다.
- High Availability. DB 하나가 터져도 나눠진 DB들이 각각 역할을 대체할 수 있다.
- High Reliability. 자연재해 등으로 DB 하나가 터져도. 데이터는 보존될 것이다.
🎱 캐시
이번엔 Latency를 개선해볼 차례다.
- read-through caching strategy
요청받은 웹 서버는 캐시에 응답이 저장돼있는지 확인 후. 있으면 캐시에서 반환. 없으면 DB에서 데이터를 읽어서 캐시에 쓴 후 반환.
캐시에 대한 여러 TIP
- 갱신은 적고 참조는 많으 경우. => 캐시 도입 고려
- 영속적인 데이터는 X
- Expire, Eviction 정책을 고려.
- consistency는 어떻게 할 것인지 생각해보자.
- 장애 대처는? 캐시 서버를 한 대만 두면 SPOF이 될 수 있다.
- 캐시 메모리는 너무 작으면 성능이 떨어진다. 과할당하면 좋다.
🎱 CDN
정적 콘텐츠를 전송하는데 쓰이는 지리적으로 분산된 서버의 네트워크.
Request path, Query String, cookie, request header에 기반하여 HTML 페이지를 캐싱함.
어떤 사용자가 웹 사이트를 방문하면, 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달하게 된다.
