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

1장 사용자 수에 따른 규모 확장성

 

단일 서버 구조

• 사용자는 도메인 api.mysite.com인 웹 사이트에 접속한다
• 접속을 위해 DNS가 도메인을 IP 주소로 변환한다. (보통 제3 사업자가 운영하는 유료 서비스를 이용한다)
• IP 주소로 변환되고 나면 HTTP 요청이 전달된다
• 요청 받은 웹 서버는 HTML 페이지나 JSON 응답을 반환한다.

 

데이터베이스

• 사용자 수가 증가하면 서버 하나로는 부족하기 때문에 여러 서버를 두어야함
• 하나는 웹/모바일 트래픽 처리 용도이고, 하나는 데이터베이스 처리 용도이
  
  

데이터베이스 종류

• 관계형 데이터베이스
  • MYSQL, Oracle, PostgresSQL
  • 테이블과 열, 컬럼으로 표현함
  • Join 이 가능
• 비 관계형 데이터베이스
  • NoSql 이라 부름
  • GouchDB, Neo4j, Cassandra, HBase, DynamoDB
  • 키-저장소, 그래프 저장소. 칼럼 저장소, 문서 저장소로 분류가 가능
  • RDB와 가장큰 차이점은 Join연산을 지원하지 않음

 

NoSql을 사용해야 하는 경우

• 아주 낮은 응답 지연시간(latency) 이 요구됨
• 다루는 데이터가 비정형임 (관계형 데이터가 아님)
• 데이터(JSON, YAML, XML)을 직렬화 or 역직렬화 할 수 있기만 하면 됨
• 아주 많은 양의 데이터를 저장할 필요가 없음

 

수직적 규모 확장 vs 수평적 규모 확장

수직적 규모 확장(scale up)

• 더 좋은 cpu, ram 을 추가하는 행위

수평적 규모 확장(scale out)

• 더 많은 서버를 추가하여 성능을 개선하는 행위

 

수직적 규모 확장의 단점

• CPU나 메모리 추가에도 한계가 있음
• 자동복구(failover) 나 다중화(re-dundancy) 방안을 제시하지 않음 -> 서버에 장애가 발생하면 웹 사이트가 완전히 중단됨

사용자가 늘어남에 따라 응답속도가 느려지거나, 서버 접속이 불가능 한 경우를 해결하기위해 로드밸런서를 이용함

 

 

로드밸런서

 

트래픽 부하를 고르게 분산하는 역할을 함 

• 서버 1이 다운되면 모든 트래픽은 서버 2로 전송됨 => 웹 사이트 전체가 중단되는 일이 방지됨
• 트래픽이 증가하게 되면 웹 서버 계층에 더 많은 서버를 추가하면 됨. 로드벨런서가 알아서 트래픽을 분산해줌

웹 계층은 개선이 되었다. 허나 하나의 데이터베이스 서버뿐이고, 장애가 발생할 수 있다.

 

데이터베이스 다중화

• 일반적으로 서버 사이에 주-부(master-slave) 관계를 설정함
• 주 데이터베이스에선 write 쓰기 연산을 지원한다.
• 부 데이터베이스에서는 주 데이터베이스로부터 사본을 전달받고 read 읽기 연산을 지원한다.

 

데이터베이스 다중화시 이점

• 성능
  • 주-부로 역할을 나누었기 때문에 병렬로 처리될 수 있는 질의(query)가 증가하고 성능이 좋아진다
• 안전성
  • 데이터를 지역적으로 떨어진 여러 장소에 다중화 시킬 수 있음(손상 되어도 데이터 보존 가능)
• 가용성
  • 데이터를 여러 지역에 복제해 둠으로써, 하나의 데이터베이스 서버에 장애가 발생하더라도 다른 서버에 있는 데이터를 가져와서 서비스 지속 가능

 

 

로드벨런서와 데이터베이스 다중화를 고려한 설계안

 

캐시

 

• 값 비싼 연산 결과나 자주 참조되는 데이터를 메모리 안에 두고 요청보다 빨리 처리할 수 있도록 하는 저장소
• 응답시간을 개선 가능 
• 데이터베이스보다 훨씬 빠름
• 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어날경우 고려할 만함 

 

 

읽기 주도형 캐시 전략(read-through caching strategy)

• 웹 서버가 요청을 받음
• 캐시에 응답이 저장되어있는지 확인함
• if(저장되어있다면) 해당 데이터를 클라이언트에게 반환
• else 데이터베이스에 쿼리를 통해 데이터를 찾고, 캐시에 저장 후 클라이언트에게 반환함

 

캐시 사용시 유의할 점

• 어떤 데이터를 캐시에 둘 것인가?
  • 캐시 데이터는 휘발성 데이터이기 때문에, 영속적으로 보관할 데이터를 캐시에 두는 것은 바람직하지 않음
• 캐시에 보관된 데이터는 어떻게 만료되는가?
  • 만료정책이 없으면 데이터가 캐시에 계속 남아있게 된다.
  • 만료 기한이 너무 짧으면 데이터베이스를 너무 자주 읽게된다
  • 만료 기한이 너무 길면 원본과 차이 날 가능성이 높아진다.
• 일관성은 어떻게 유지되는가?
  • 일관성이란 데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부이다.
  • 저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리되어있지 않다면 일관성이 깨질 수 있음
• 장애에는 어떻게 대처할 것인가?
  • 캐시 서버를 한 대만 두는경우 SPOF(Single Point of Failur)이 발생할 수 있음
  • 이를 피하기 위해선 캐시 서버를 분산 시켜야함
• 캐시 메모리는 사이즈는 얼마나 크게 잡을 것인가?
  • 캐시 메모리가 너무 작으면 데이터가 너무 자주 캐시에 밀려나버려 캐시 성능이 떨어짐
  • 캐시 메모리를 과할당하여 해결이 가능
• 캐시 내 데이터 방출 정책은?
  • 캐시가 꽉 찼을 경우 데이터를 내보내는 방식
  • LRU(Least Recently Used)
    • 가장 많이 사용함
    • 마지막으로 사용된 시점이 가장 오래된 데이터를 내보내는 정책
  • LFU(Least Frequently Used)
    • 사용된 빈도가 가장 낮은 데이터를 내보냄
  • FIFO(First In First Out)
    • 가장 먼저 캐시에 들어온 데이터를 내보냄

 

 

다음장 2장 

https://mingg123.tistory.com/251

[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 2장 개략적인 규모 추정