[Chapter 15] Q&A

[easyfordev]

[Chapter 15] 구글드라이브 설계

• 궁금한 점 혹은 이야기하고 싶은 주제 코멘트로 정리
• 추가로 같이 보면 좋을 것 같은 기술 블로그, 아티클 등 공유

[easyfordev]

이지

느낀점

• 이번 장도 내용이 조금 많은 것을 제외하고는 이해가 안되는 내용이나 어려운 부분은 없었습니다.
• 저장소 관련된 설계 문제는 S3같은 잘 만들어진 외부 서비스를 써서 안정성 등 요구사항을 쉽게 만족시킬 수 있구나.
  • 반드시 처음부터 끝까지 다 설계할 필요 없다는 것을 기억하자. (개발도 마찬가지!)

참고 자료

• NoSQL 데이터베이스는 높은 일관성을 기본적으로 지원하지 않으므로, 동기화 로직 안에 추가적으로 프로그래밍을 해야 한다.
  • 앞 Chapter에서 다뤘던 내용
  • ACID vs BASE
  • BASE : 성능과 가용성을 위해서 ACID의 C와 I의 속성을 포기하고, 분산 시스템에 더 적합하다고 생각되는 성질을 정리한 것
    • Basically Available, Soft-state, Eventually consistency
    • 참고 : CAP 이론
    • https://embian.wordpress.com/2013/06/27/nosql-2/
• 자주 쓰이지 않는 데이터는 아카이빙 저장소(cold storage)로 옮긴다.
  • 아마존 S3 Glacier같은 저장소는 S3보다 훨씬 저렴함
  • 실제로 설계할 때 비용을 줄이기 위해 많이 사용하는 방법. S3 대비 70-80% 정도 절약할 수 있음
    • 파일의 접근에 대한 분석이 먼저 이루어짐. 자주 접근되는 파일이 무엇인지? 1년 지나면 아예 접근되지 않는 파일은 어떤건지?
    • 예) 어
  • 그렇다면, Glacier는 장점만 있는가? No
    • 단점 : 검색이 어렵고, 기본적으로 Get(사용자가 원할 때 다운로드)도 어려움, 업로드도 어려움(업로드가 반영되는데 24시간정도 걸림), 복구도 어려움, UI도 없음(이건 현재 버전에서 개선된듯), 삭제가 어려움(바로 비용떄림)
  • https://bluese05.tistory.com/35
  • https://augustkang.com/posts/aws/s3-glacier-flexible-retrieval-storage-class/

질문

• 알림 서비스 : 정말 롱 폴링이 최선일까요..? 이전 책에서 큐 쓰는 방식이 나왔던 기억이 있는데... (롱 폴링을 직접 구현해보면 재밌겠다)
• 오프라인 사용자 백업 큐 장애 : 이 큐 또한 다중화해둬야 함. 큐에 장애가 발생하면, subscribe 중인 클라이언트들은 백업 큐로 구독 관계를 재설정
  • 어떻게 하는지 아시는 분 있나요..? (나도 링크를 좀 찾아보자)

[KKambi]

한비

공유

1. 책에서 네임스페이스(사용자의 루트 디렉토리)로 사용자별 저장공간을 분리하는데, 네이버의 OwFS 스토리지도 비슷한 개념을 사용한다. Owner라는 단위로 저장소를 구분하며, Owner가 달라지면 파일이 저장되는 서버도 달라진다 (책에서 user_id를 기준으로 샤딩했던 것처럼) Fuse를 통해서 마운트하게 되면 /owfs/{owner이름}/... 이렇게 마운트가 되는 것으로 보아, 동일하게 루트 디렉토리로 구분하는 것 같다.

2. Long polling vs Message broker

   • API 서버 -> 알림 서비스 -> 클라이언트(웹, 안드로이드, iOS, ...)
   • 알림 서버 -> 푸쉬 알림 큐 -> 작업 서버 -> 제3자 알림 서비스 -> 클라이언트
   • 100% 이해되진 않지만, server to server communication에는 메세지 브로커가 적합하고, client-server 간 통신에는 폴링/웹소켓이 적절하다고 한다.
   • 메세지 큐를 사용한다면, API 서버와 알림 서비스 사이에 큐를 두고 롱 폴링은 사용하지 않으면 될 듯 https://softwareengineering.stackexchange.com/questions/426448/long-polling-and-message-brokers

질문

1. (292p) device 테이블에 push_id 필드가 있다는데 보이지 않음 -> 실수겠죠?

[travelbeeee]

현석

느낀점

• 어려운 내용은 없었습니다.
• 이지님과 마찬가지로 '어떤 시스템 설계'를 면접에서 요구받았을 때는, 핵심 기능들을 캐치해서 면접 시간 내에 잘 개발하고, 나머지 부가 기능들은 이미 잘 만들어져있는 서비스(e.g. S3) 를 이용하겠다고 말씀드리는게 좋을 것 같다.

동기화 충돌

• 책에서 첨부한 링크에 따르면 가장 흔한 접근법은 3가지 방법이다.

  • Locking
  • 가장 간단한 기법.
  • N명이 공유하는 문서를 1명이 Open 하면 나머지 N-1 명은 read-only 상태가 된다.
  • git 에서는 수정 중인 issue 를 다른 팀원이 이미 수정했으면, 업데이트가 안되는데 이 기법인가??
  • Event Passing
  • It relies on capturing all user actions and mirroring them across the network to other users.
    • 서로서로 상대방이 반영한 내용을 미러링하고 있는다.
    • 줌에서 서로 공유하는 문서함(?) 같은거 열면 서로 그림그리고, 글씨쓰는거 실시간으로 반영되는데 같은 기법으로 추정
  • Three-way merges
  • 1. 클라가 서버로 파일을 보낸다
  • 2. 서버는 클라가 보내온 파일들의 변화를 추출하고, 3-way merge 를 한다.
  • 3. 다시 클라에게 새로운 복사본을 보내준다.
  • git 에서 사용하는 3-way merge 방법.

• 책 링크 : https://neil.fraser.name/writing/sync/

궁금증

1. 블록 저장소 서버에서 파일을 블록으로 나눠서 해시값을 부여하면, 재구성해서 순서대로 다시 파일로 합칠 때는 해당 해시값이 몇 번째 순서인지도 메타데이터로 저장하고 있겠죠...?? ( 당연한 것 같은데 맞게 이해한건지 궁금해서 끄적끄적해봅니다... )
2. p.296 저장소 공간 절약에서 '중요한 버전만 보관' 한다는 전략은 구글 드라이브를 생각했을 때, 가장 최신 버전을 중요하다고 판단하는 걸까요?? 판단 기준이 궁금합니다. (서비스 목적마다 다르겠지만...!)

[janeljs]

지선

• 번외) 백엔드 전문가인 친구에게 물어봤더니.. - 저자는 백엔드 전문가가 아니었던 건가?
• https://neil.fraser.name/writing/sync/, https://www.youtube.com/watch?v=2auwirNBvGg
  • Locking
  • 동시에 한 사람만 편집 가능
  • Event passing
  • 내 영어실력...이라는 현석님 코멘트를 보고 읽어봤습니다ㅋㅋ
  • 사용자가 발생시키는 모든 이벤트(타이핑, 잘라내기, 붙여넣기, 드래그, 자동교정, 폰트 변경 등)를 다른 사용자에게도 전송하는 방법
  • 요즘이 언제인지는 모르겠지만 요즘 제일 인기있다함
  • Operational Transformation이라는 알고리즘 사용
    • 낙관적 동시성 제어 알고리즘
    • 락 없이도 충돌 해결 가능
    • operation = event
    • operation(target, location) e.g. insert(a, 1)
    • 기본 concept: 한 개의 상태로 converge해야함
    • 즉 operational transformation은 a 대신 a', b 대신 b' 이벤트를 전송하는 것
      • a'는 어떻게 만드는데? 우리가 변환 알고리즘 구현해야한다고 한다...^^ 완전 동일한 이벤트가 아니라 상황에 맞는 operation을 수행하도록
      • 보통 서버는 operation 그대로 보내주고 client에서 operational transformation을 수행한다 함
  • Three-way merge
    • 클라이언트에서 서버로 데이터 전송
    • 서버가 three-way merge 실행
    • 서버가 클라이언트에게 새 버전 보냄
    • 즉 sync 문제 발생하면 클라는 무조건 새 버전 버리고 다시 시도해야함
    • 누군가라도 타이핑하고 있으면 새로운 요청이 받아들여지지 않는 상태
• 만약 s3를 사용한다면 동시에 편집하는 걸 실시간으로 s3에 저장..하는건가? 나중에 저장한다는 뜻일까?와 같은 것이 궁금했는데 델타 동기화나 블록 단위 압축을 사용한다는 걸 알았다.
• 예에 책 끝났다~

[zziri]

지훈

• 같은 문서를 편집할 때 발생할 수 있는 동기화 문제를 해결하는 방법이 궁금했는데, 현석님이 잘 정리해주셨습니다
  • https://wonyong-jang.github.io/git/2021/02/05/Github-Merge.html
• 이번 장에서는 특별히 언급할 부분은 없습니다...

[meloncha]

민석

rsync algorithm : 블록 저장소 서버의 델타 동기화(delta sync) 방법

• rsync algorithm : https://rsync.samba.org/tech_report/tech_report.html
• 파일이 수정되면 전체 파일 대신 수정이 일어난 블록만 동기화한다
• 수정이 일어난 블록을 어떻게 찾을까?

수정이 일어난 블록 찾는 법

1. 파일 서버 데이터를 일정한 크기의 블록으로 나눈다
2. 블록을 hash한 값들을 클라이언트에 보낸다
3. 클라이언트는 수정한 데이터를 블록 크기만큼 '롤링 해시'하여 해시 값을 비교한다
4. 비교 후 겹치는 데이터는 제외하여 수정되는 데이터 블록만 파일 서버에 보낸다 참고 ) https://stackoverflow.com/questions/1535017/rolling-checksums-in-the-rsync-algorithm

블록의 순서는 어떻게 알 수 있을까?

• 메타데이터 데이터베이스의 block 테이블이 파일의 블록들의 순서를 저장한다
• 수정되는 데이터 블록을 보낼 때 어떤 블록을 변경해야 하는지 offset 을 추가하여 보낼 것 같다