1.a 사용자 수에 따른 규모 확장성 ( Database + LoadBalancer )

영슈·2023년 6월 3일
0

단일 서버

  • 서버가 하나의 컴퓨터로 운영
  • Web App , Database , Cache ... in 1 Server
    +++ DNS 는 Third Party 가 제공하는 서비스 이므로 , 우리 시스템 일부가 아님.
  1. Client -> DNS ( api.mysite.com - Domain Name )
  2. DNS -> Client ( 15.125.23.214 - Ip Address )
  3. Client -> Server ( 15.125.23.214 - Request )
  4. Server -> Client ( HTML Page - Response )
    => 수많은 부하를 담당하기에 , 한계가 있음.
    => Web Layer - Data Layer 를 서로 분리

로드 밸런서 ( Web Layer )

  • 부하 분산 집합에 속한 서버들에게 트래픽 부하 고르게 분산
  • 보안적 이점
    => Web Server 가 Client 접속 직접 처리 X
    => Server 간 통신에는 Private IP Address 이용
  • failover 해결 & availability 향상
    => Server 가 offline 일 시 , 다른 Server 에 보냄. ( failover 방지 )
    => Traffic 이 Critical Path 에 도달하면 , 더 많은 서버 추가만 하면 OK

데이터 베이스 ( Data Layer )

  • 관계형 DB : MySQL , Oracle , PostgreSQL
  • 비관계형 DB : MongoDB , Neo4j , Cassandra

비 관계형 특징

  • 아주 낮은 응답 지연시간 요구
  • 데이터가 비정형 ( unstructured )
  • 데이터 직렬화 ( Serialize ) or 역직렬화 ( deserialize ) 만 가능하면 됨
  • 아주 많은 양 데이터 저장할 필요가 있음

scale up = 스펙 업

  • 서버에 고사양 자원 ( 🔼 CPU , 🔼 Memory ) 을 추가
  • AWS Rds 에는 24TB RAM 을 가지고 있는 상품도 있음.
  • stackoverflow 는 2013 년 사용자 전부를 Master Database로 처리한 일례가 있음.
    => 물론 , 지금은 당연히 분산형으로 구축
  • 장애 대한 자동복구 (failover) , 다중화(redundancy) 방안 제시 X
  • 비용이 많이 들고 , SPOF ( Single Point of Failure ) 로 인한 위험성 존재
    => 결국 서버 하나이기에 , 한계점 존재

scale out = 샤딩

  • 더 많은 서버를 추가해 성능 향상시키도록 함.
  • DB를 shard 라는 단위로 분할 ( 같은 Schema 공유 , 보관 Data 간 중복 X )
  • 샤딩 키에 의해 구분 ( Data 를 어떻게 분산할지 정함 )
    => 몹시 중요 ( Sharding Key 에 의해 올바른 DB에 질의를 보내므로 )

고려할 점

  1. resharding : 데이터가 너무 많아지거나 , 데이터 분포가 균등하지 못할때 발생
    => 샤드 키 계산 Function 변경 & Data 재배치
  2. celebrity : ≈ hotspot key , 특정 샤드에 질의가 집중되 서버 과부화 발생
    => 유명인사 마다 샤드 할당 하는 식으로 , 유연한 샤드 관리
  3. join & de-normalization : 여러 샤드로 쪼갤 시 , 조인 하기 힘들어짐.
    => 비정규화가 꼭 나쁜 것만은 아니다.

데이터베이스 다중화

master - slave 관계를 설정 + Data 원본은 Master Server , Data 사본은 Slave Server 에 저장

  • write ( insert , delete , update ) 는 Master , read 는 Slave 에서 담당
    => 대부분의 경우 , read 가 write 보다 많으므로!
  • better Performance : 변경 연산은 master , read 연산은 slave에 분산되므로 Parallel Query 수 증가!
  • reliability : 서버 중 일부가 파괴되어도 데이터 보존
  • availabilty : 데이터 여러 지역 복제 , 장애 발생 시 다른 곳에서 가져옴.

Case1. Slave Server 가 한 대 일때 , Down 일 경우 :

=> read 연산은 master 에 한시적 전달 + 새로운 Slave 가 대체

Case2. Master Server Down 일 경우 :

=> 한 대의 Slave 있을시에는 , 그 Server 가 Master 되며 , 위와 동일
=> production development 에서는 고려할 점 추가
( 부 서버에 보관된 데이터 최신 상태가 아닐 수 있으므로 )

0개의 댓글