[가상 면접 사례로 배우는 대규모 시스템 설계 기초]15. 구글 드라이브 설계

책 리뷰

[가상 면접 사례로 배우는 대규모 시스템 설계 기초]15. 구글 드라이브 설계

punch.pro 2023. 5. 22. 06:43

https://product.kyobobook.co.kr/detail/S000001033116

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬 - 교보문고

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | “페이스북의 뉴스 피드나 메신저,유튜브, 구글 드라이브 같은 대규모 시스템은 어떻게 설계할까?” IT 경력자라도 느닷없이 대규모 시스템

product.kyobobook.co.kr

요구사항

- 기능 요구사항

파일 추가

파일 다운로드

여러 단말 파일 동기화

파일 갱신 이력 조회

파일 공유

파일이 편집되거나 새롭게 공유될 때 알림 표시

- 제외 기능

구글 문서 편집 및 협업 기능

- 비 기능 요구사항

안정성 : 저장소 시스템에서 안정성은 아주 중요합니다.

빠른 동기화 속도 : 파일 동기화에 시간이 너무 많이 걸리면 사용자는 인내심을 잃습니다.

네트워크 대역폭 : 이 제품이 네트워크 대역폭을 크게 쓰면 안 좋습니다.

규모 확장성 : 아무 많은 양의 트래픽도 처리 가능해야 합니다.

높은 가용성 : 일부 서버에 장애가 발생하거나, 느려지거나, 네트워크 일부가 끊겨도 시스템은 계속 사용할 수 있어야 합니.

개략적 추정

- 가입 사용자는 오천만, DAU 1,000만

- 모든 사용자에게 10GB의 무료 저장공간 할당

- 매일 각 사용자가 평균 2개의 파일을 업로드한다고 가정합니다.

- 읽기:쓰기 = 1:1

- 필요한 저장공간 총량 = 5천만 * 10GB = 500페타바이트(Petabyte)

- 업로드 API QPS = 1천만 사용자 * 2회 업로드/24시간/3,600초 = 약 240

- 최대 QPS = QPS * 2 = 480

개략적 설계

우선 한 대의 서버로 시작해서 점진적으로 천만 사용자 지원이 가능한 시스템으로 만들어 보자. 한 대의 서버는 Web Server + DB + Storage(1TB)로 이루어질 것이다.

한 대 서버의 제약 극복

한 대의 서버의 1TB 공간을 모두 쓰면 데이터 샤딩을 통해 공간을 늘려준다.

서버의 장애로 데이터를 잃을 것을 걱정한다면 S3를 고려하자. S3를 통해 데이터 다중화를 할 때는 여러 지역에 걸쳐 bucket을 다중화하자. 이제 확장성, 가용성, 보안, 성능을 제공하는 객체 저장소 서비스인 S3를 활용하게 되었고, 데이터 손실 걱정이 줄었다. 하지만 저장소 외의 지점에서 발생하는 문제는 해결되지 않았다. 그래서 다른 부분을 고민해 본다.

- 로드 밸런서: 트래픽을 분산하고, 특정 웹서버에 장애가 발생하면 우회해 준다.

- 웹 서버: 로드 밸런서로 스케일 아웃이 쉬워진다. 즉 트래픽이 폭증해도 대응이 쉽다.

- 메타데이터 DB: DB를 파일 저장 서버에서 분리해서 SPOF를 피한다. 아울러 샤딩 및 다중화를 적용할 수 있다.

- 파일 저장소: S3를 사용하고, 가용성과 데이터 무손실을 위해 두 개 이상의 지역에 다중화한다.

동기화 충돌

두 명 이상의 사용자가 같은 파일이나 폴더를 동시에 업데이트 하면 충돌이 난다. 충돌을 해결하기 위해 먼저 처리되는 변경을 성공한 것으로 보고, 나중에 처리되는 변경은 충돌로 표시한다. 충돌이 발생하면 로컬 사본(local copy) 버전이 생성되고, 사용자는 두 파일을 합칠지, 하나를 선택할 지 결정해야 한다.

개략적 설계안(전체 설계안)

여기선 볼록 저장소 서버와 아카이빙 저장소, 그리고 오프라인 사용자 백업 큐만 언급한다.(나머지는 직관적이다)

- 블록 저장소 서버

파일을 블록 단위로 쪼개서 업로드 하는 서버다. 이 때 각 블록은 고유한 해시값이 할당된다. 그리고 이 해시값은 메타데이터 데이터베이스에 저장된다. 블록을 재구성하려면 블록들을 원래 순서대로 합쳐야 한다.

- 클라우드 저장소

블록 단위로 나눠져 클라우드 저장소에 보관된다.

- 아카이빙 저장소

오랫동안 사용되지 않은 비활성 데이터를 저장한다.

- 오프라인 사용자 백업 큐

클라이언트가 오프라인일 때 변경이나 알람을 큐에 두어 클라이언트가 접속 했을 때 동기화 한다.

상세 설계

상세 설계에선 블록 저장소 서버, 메타데이터 데이터베이스, 업로드 절차, 다운로드 절차, 알림 서비스, 파일 저장소 공간 및 장애 처리 흐름에 대해 더 자세히 알아본다.

블록 저장소 서버

파일 업데이트가 일어날 때마다 전체 파일을 갱신하면 네트워크 비용이 비싸다. 이를 위해 두 가지 해결책이 있다.

- 델타 동기화: 파일이 수정되면 변경된 블록만 갱신하는 방식

- 압축: 블록 단위로 압축해두면 데이터 크기를 줄일 수 있다.

높은 일관성 요구사항

이 시스템은 강한 일관성 모델을 기본으로 지원해야 한다. 이를 위해서 메모리 캐시가 일반적으로 지원하는 최종 일관성 모델에서 약간의 장치를 추가해야 하는데, 그건 원본에 변경이 발생하면 캐시를 무효화 하는 작업이다.

RDB는 강한 일관성을 보장하기 쉽지만, NoSQL은 그렇지 않으므로 동기화 로직 안에 프로그램해 넣어야 한다. 이 시스템은 RDB를 사용해서 일관성 요구사항에 대응한다.

메타데이터 데이터베이스

메타데이터 데이터베이스 스키마 설계안은 다음과 같다.

업로드 절차

파일 수정의 경우도 업로드와 비슷하므로, 따로 언급하지 않는다.

다운로드 절차

알림 서비스

알림 서비스는 롱 폴링, 웹소켓 방식 중에 선택해야 한다. 이 중 본 설계안 은 롱 폴링을 사용할 것이다. 그 이유는 채팅서비스와 달리 양방향 통신이 필요치 않고, 웹소켓은 알림을 보낼 일은 그렇게 자주 발생하지 않으며, 단시간에 많은 양의 데이터를 보내지 않는 구글 드라이브에 적합하지 않다.

저장소 공간 절약

파일 갱신 이력을 보존하고 안정성을 보장하기 위해서는 파일의 여러 버전을 저장해야 한다. 하지만 보드 백업하면 용량이 부족하니, 다음과 같은 전략을 사용하자.

- 중복 제거: 중복된 파일 블록은 제거하자

- 지능적 백업 전략: 한도 설정(파일 버전 갯수 제한), 중요 버전만 보관(자주 변경되는 문서는 불필요한 저장본 제거)

장애 처리

몇 가지 종류의 장애를 살펴보자

- 로드밸런서 장애: 로드 밸런서끼리 박동 신호를 통해 장애를 감지하자

- 블록 저장소 서버 장애: 다른 서버가 미완료 상태 또는 대기 상태인 작업을 이어받아야 한다.

- 클라우도 저장소 장애: 한 지역에서 장애가 발생하였다면 다른 지역에서 파일을 가져오자

- API 서버 장애: API서버는 로드 밸런서가 요청을 할당하지 않으므로 격리할 수 있다.

- 메타데이터 캐시 장애: 캐시 서버도 다중화한다.

- 메타데이터 DB장애: 주 DB 서버 장애는 부 DB서버를 주 DB서버로 만들고 부 DB서버 하나를 추가한다. 부 DB 서버 장애는 다른 부 DB서버에게 읽기 연산을 위임하고, 다른 서버 하나를 추가한다.

- 알림 서비스 장애: 한 서버에 장애가 발생하면 수만 명 이상의 사용자가 롱 폴링 연결을 새로 만들어야 함(복구 오래걸림)

- 오프라인 사용자 백업 큐 장애: 큐 또한 다중화해 두어야 한다.

저작자표시