search

aws-cloud-clubs / 2023-system-design-interview-1st

0 stars 3 forks source link

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

Open Eeap opened 1 year ago

Eeap commented 1 year ago

❓ Question

📎 Additional context

ahyeon-github commented 1 year ago

📎 reference

https://studylib.net/doc/25766177/system-design-interview

Scaling.Memcache.at.Facebook.pdf

https://changhoi.kim/posts/database/scaling-memcache-at-facebook/

ahyeon-github commented 1 year ago

Question 저는 프로젝트를 할 때 데이터베이스를 샤딩을 사용해본 적이 없어서 현업에서 어떻게 데이터베이스를 샤딩하여 운영을 하는지 궁금하였습니다

bik1111 commented 1 year ago

3조 윤가영님께서 해당 부분 노션에 남겨주셔서 여기에도 공유합니다.

By 윤가영님

궁금해서 더 찾아본 것

요약

  1. 슬레이브를 두는 것 자체로는 주 서버에 대한 부하가 경미함 주 서버가 복제 환경에서 주로 하는 일 2가지 로컬 하드 드라이브에 이벤트를 구성하고 이를 이진 로그(binlog)에 기록 각 연결된 슬레이브에게 기록한 모든 이벤트의 사본을 전송 -> 위의 이유가 큰 비용이 아닌 이유 : 이진로그를 복제하는 것을 복제의 비용으로 여기지 X -> 복제를 하지 않더라도 항상 이진 로깅을 켜놓아야 하기 때문에 문제 해결 및 복구 도구로서 극히 가치 있는 기능

  2. 슬레이브에게 로깅을 전송하는 비용 역시 적음 주 서버는 슬레이브와 TCP 연결을 유지하며, 주 서버는 이벤트가 발생할 때 데이터를 소켓에 복사하기만 하면됨 따라서 그 이후부터는 주 서버는 슬레이브가 해당 이벤트를 실행하는지 여부나 언제 실행하는지에 대해서는 알지도 못하며 신경쓰지 않음.

  3. 어떤 경우에도 주 서버는 슬레이브에서 실제로 업데이트를 실행하는 것은 아님 (중요!!) 주 서버는 단지 슬레이브에게 두 가지 중 하나를 전송 : (1) 실제 실행된 쿼리의 사본 또는 (2) 각 쿼리에서 실제로 삽입/업데이트/삭제된 행들의 데이터. --> 여기서 (2)를 수행하는 과정에서도 위에서 언급한 이진로그를 기록하는 주 서버는 모든 이벤트를 매번 새롭게 갱신하는 것이 아니라 "실제로 변경"이 이루어진 것만 선별해서 기록, 데이터 변경 내역을 효율적으로 "압축" 하여 전송, 여러 개의 슬레이브에게 "병렬적" 으로 분산 전달

참고로, 여기서 말하는 다중화는 데이터원본을 저장하는 주 서버(MasterDB)와 사본을 저장하는 부 서버(SlaveDB)를 의미합니다. ( 책 P7 )