시스템 확장 ( Scalability )

Scalability

• 수직적 규모 확장 ( Scale Up ) : 서버의 고사양화
  • 트래픽 양이 적을 때 유용하나 확장에 한계가 있고, Fail Over / Re-Dundancy 에 대한 방안 제시 불가 

• 수평적 규모 확장 ( Scale Out ) : 더 많은 서버 추가
  • 대규모 애플리케이션에 적합

 

1) 웹서버 확장

• Load balancing 을 통해 웹 서버에 트래픽 고르게 분산 -> Failover / Availability 향상

LB를 통한 Web Server 분산

 

2) DB 확장

(1) DB 이중화

• Master - Slave 방식
  • Master : 원본 저장 / 쓰기 연산
  • Slave : 사본 저장 / 읽기 연산
• 병렬로 처리 될 수 있는 질의 수 증가, Reliability / Availability 향상

Master-Slave DB 이중화

 

 

(2) Sharding

• DB를 샤드로 분할 - 모든 Shard는 같은 Schema를 사용하나, Shard에 보관되는 데이터 사이에는 중복 X.
  • 즉,  Schema 내 데이터 분리를 통한 수평적 확장
• Partition key ( 하나 이상의 칼럼) 을 통해 분산됨 - 데이터를 고르게 분산할 수 있는 Partition Key 선정이 중요

Sharding

 

 

3) 효율적 처리

(1) Cache

• 결과 Cost가 높거나 자주 참조되는 데이터를 메모리에 저장 -> 성능 개선 / DB 부하 감소 / 캐시 계층 Scale Up 가능
  • 갱신은 자주 일어나지 않으나 참조가 잦은 경우 유용
• 영속적 보관 목적의 데이터 저장으론 적합 X
• 적절한 만료 기간과 방출 정책 설정 필요
  • 방출 정책의 경우 LRU / LFU / FIFO 등 사용 
• SPOF를 피하기 위해 다중화 필요

DB 부하 감소를 위한 Cache 사용

 

(2) CDN (Contents Delivery Network)

• 정적 컨텐츠 캐시
• 지리적으로 분산된 서버의 네트워크 - 사용자에게 가까운 CDN 서버에서 컨텐츠 전달
• CDN에서 이미지
• 비용 / 적절한 만료기간 고려 필요
  • 자주 사용하지 않는 컨텐츠의 캐싱은 과도한 비용지불의 원인
  • Time-Sensitive한 컨텐츠의 경우 만료 시점의 선정이 중요

CDN을 활용한 정적 컨텐츠 캐싱

 

(3) 상태 정보 분리 (Statless)

• 상태 정보를 NoSQL, Memcached/Redis 등에 보관 함으로서 웹 계층의 수평적 확장 가능
  • 상태 정보에 의존적이면 동일 세션이 동일 서버로만 접근해야함

Stateless

 

 

 

 

 

4) 시스템 확장

(1) 데이터 센터

• 장애 발생 시 장애가 없는 데이터 센터로 트래픽 우회 (GeoDNS)
• DB를 여러 데이터 센터에 걸쳐 다중화

Data Center 이중화

 

(2) 메시지큐 (Message Queue)

• 무손실을 보장하는 비동기 통신 -> 작업 프로세스의 효율화
• 컴포넌트들의 독립성을 강화하여 Fault Tolerance를 높인다.

Message Queue를 통한 Fault Tolerance 향상

 

(3) 로그/메트릭/모니터링/자동화

 

 

정리

• 모든 계층(서버 ~ 데이터 센터)에 다중화 필요 
• 웹 계층 : Stateless / 정적 컨텐츠 : CDN / 가능한 한 많은 캐시 
• 각 계층을 독립적인 서비스로 분할
• 데이터는 샤딩을 통해 확장
• 모니터링 / 자동화

 

가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 01. 사용자 수에 따른 규모 확장성