13장 구글 독스 서비스 설계

[jongfeel]

13장 구글 독스 서비스 설계

13.1 기능적 요구 사항

• 사용자 등록 및 인증
• 문서 생성, 편집, 삭제
• 실시간 협업 및 동기화
• 문서 공유 및 접근 권한 관리
• 버전 기록과 문서 수정 관리 기능
• 댓글과 수정 제안 기능
• 검색 및 문서 정리 기능

13.2 비기능적 요구사항

• 확장성
• 높은 가용성과 안정성
• 낮은 지연 시간
• 데이터의 일관성과 무결성

13.3 데이터 모델

• User
• Document
• Revision
• CollaboratorPermission: v사용자와 문서를 연결하고 view, edit, comment 등 권한 수준과권한이 부여된 시간 명시
• Comment
• Suggestion: 문서에 대한 수정이나 변경 제안
• Folder
• FolderDocument: 폴더와 문서 관계

Figure 13.1: An overview of the entity relationship diagram for a Google Docs-like service data model

13.3.1 데이터 간 관계

1:N 관계

• User - Document: 한 사용자는 여러 문서를 소유할 수 있습니다.
• Document - Revision: 하나의 문서는 시간에 따라 수정 기록을 여러 개 축적합니다.
• Document - Comment: 하나의 문서에는 여러 사용자가 남긴 댓글이 포함될 수 있습니다.
• Document - Suggestion: 하나의 문서에는 여러 제안이 추가될 수 있습니다.
• User - Folder: 한 사용자는 여러 폴더를 생성할 수 있습니다.

N:N 관계

• User - Document: 한 사용자는 여러 문서에서 협업할 수 있으며, 반대로 하나의 문서에도 사용자가 여러 명 참여할 수 있습니다. 이 관계는 CollaboratorPermission 엔티티로 관리합니다.
• Folder - Document: 하나의 폴더는 여러 문서를 포함할 수 있으며, 동시에 하나의 문서가 여러 폴더에 속할 수도 있습니다. 이런 관계는 FolderDocument 엔티티로 관리합니다.

13.4 시스템 규모 산정

13.4.1 가정 상황

• 전체 사용자 수: 1000만 명
• 사용자 1인당 평균 문서 수: 100개
• 문서 하나의 평균 크기: 50KB
• 문서당 평균 수정본 수: 10개
• 수정본 하나의 평균 크기: 50KB
• 문서 하나당 평균 협업자 수: 5명
• 문서당 평균 댓글 수: 20개
• 댓글 하나의 평균 크기: 1KB
• 사용자 1인당 평균 폴더 수: 10개

13.4.2 저장소 규모

• 문서 저장소
  • 전체 문서 수: 사용자 수 1000만 명×1인당 작성 문서 100개 = 10억 개
  • 전체 문서 저장 용량: 문서 10억 개×문서당 50KB = 50TB
• 수정본을 저장하는 저장소
  • 전체 수정본 수: 문서 10억 개×문서당 수정본 10개 = 수정본 100억 개
  • 전체 수정본 저장 용량: 수정본 100억 개×수정본당 50KB = 500TB
• 댓글 저장소
  • 전체 댓글 수: 문서 10억 개×문서당 댓글 20개 = 댓글 200억개.
  • 전체 댓글 저장 용량: 댓글 200억 개×댓글당 1KB = 20TB
• 사용자 및 메타데이터 저장소
  • 사용자 메타데이터: 사용자 수 1000만 명×1인당 1KB = 10GB
  • 폴더 메타데이터: 사용자 수 1000만 명×1인당 폴더 10개×폴더당 1KB = 100GB
  • 협업 권한 메타데이터: 문서 10억 개×문서당 협업자 5명×권한당 1KB = 5TB
• 전체 저장소
  • 문서 저장소: 50TB
  • 수정본 저장소: 500TB
  • 댓글 저장소: 20TB
  • 협업 권한 메타데이터 저장소: 5TB
  • 사용자 및 폴더 메타데이터 저장소: 110GB
  • 합계: 575TB

13.4.3 대역폭

• 문서 업로드에 필요한 대역폭
  • 하루 평균 문서 업로드: 사용자 수 1000만 명×1인당 하루 업로드 문서 1개×문서당 50KB = 500GB/일
• 문서 다운로드에 필요한 대역폭
  • 하루 평균 문서 다운로드: 사용자 수 1000만 명×1인당 하루 다운로드 문서 10개×문서당 50KB = 5TB/일
• 협업 및 동기화 대역폭
  • 하루 평균 협업 업데이트: 사용자 수 1000만 명×1인당 하루 문서 10개×문서당 협업자 5명×업데이트당 10KB = 5TB/일
  • 총 대역폭 요구량
    • 문서 업로드: 500GB/일
    • 문서 다운로드: 5TB/일
    • 협업 및 동기화: 5TB/일
    • 합계: 10.5TB/일

13.4.4 처리량

• 문서 렌더링 및 포맷팅
  • 최대 초당 문서 렌더링 수: 사용자 수 1000만 명×1인당 하루 문서 조회 10개 ÷ 하루 86,400초 ≈ 초당 1200번 렌더링
• 문서 수정 및 병합
  • 최대 초당 수정 비교 작업 수: 사용자 수 1000만 명×1인당 하루 문서 작업 10개×문서당 하루 1번 수정 ÷ 하루 86,400초 ≈ 초당 1200번 비교
• 실시간 협업 및 동기화
  • 최대 동시 협업자 수: 사용자 수 1000만 명×동시 접속률 10%×문서당 협업자 5명 ≈ 실시간 협업자 500만 명
  • 최대 초당 협업 업데이트 수: 실시간 협업자 500만 명×1인당 분당 업데이트 수 1번 ÷ 60초/분 ≈ 초당 업데이트 83,000번

13.5 고수준 설계

Figure 13.2: The high-level system design of a file-sharing service

13.5.1 고수준 설계의 소프트웨어 구성 요소와 모듈

• 클라이언트-서버 아키텍처
• 로드 밸런서
• API 게이트웨이
• 마이크로서비스 아키텍처
  • 문서 서비스
  • 협업 서비스
    • 동시 편집 시 충돌 해결을 위해 운영 변환(Operational Transformation, OT) 알고리즘 사용
  • 수정 기록 서비스
  • 접근 제어 서비스
  • 알림 서비스
  • 캐싱: 레디스 같은 분산 캐싱 레이어 사용
  • 데이터베이스
  • 관계형 데이터베이스
    • 사용자 프로필, 문서 메타데이터, 접근 권한, 협업 관련 정보 등 메타데이터 저장
  • 비관계형 데이터베이스
    • 문서 내용과 수정 내역을 저장
  • 스토리지 시스템: S3나 구글 클라우드 스토리지 같은 분산 스토리지 시스템에 저장. 대용량 파일 처리를 위해 병렬 업로드를 위해 지능형 청킹(intelligent chunking)이나 멀티파트 API를 활용
  • 실시간 통신: 웹소켓 활용
  • 모니터링 및 로깅: 프로메테우스와 그라파나 이용, 서비스 전체 로그를 ELK 스택 사용
  • 보안 및 개인 정보

13.6 마이크로서비스 세부 설계

13.6.1 문서 서비스 설계

• POST /documents: 새 문서를 생성합니다.
  • 요청 본문: 문서 메타데이터(제목, 소유자 등)와 문서 내용(content)의 초깃값
  • 응답: 새로 만든 문서 객체와 해당 문서의 ID
• GET /documents/{documentId}: 특정 문서 ID로 문서를 조회합니다.
  • 응답: 문서 메타데이터와 콘텐츠를 포함한 문서 객체
• PUT /documents/{documentId}: 특정 문서의 메타데이터 또는 콘텐츠를 수정합니다.
  • 요청 본문: 수정된 문서 메타데이터 또는 콘텐츠
  • 응답: 수정된 문서 객체
• DELETE /documents/{documentId}: 특정 문서 ID로 문서를 삭제합니다.
  • 응답: 성공 또는 오류 메시지
• GET /documents/{documentId}/revisions: 특정 문서의 수정 이력을 조회합니다.
  • 응답: 문서와 연관된 수정 이력 객체 목록

데이터 모델

Figure 13.3: An overview of the entity relationship diagram for the Document Service

문서 생성 과정

Figure 13.4: A document creation flow sequence

문서 조회 과정

Figure 13.5: Document retrieval flow sequence diagram

문서 업데이트 과정

Figure 13.6: Document update flow sequence diagram

문서 삭제 과정

Figure 13.7: A document deletion flow sequence

문서 수정 과정

Figure 13.8: A revision history retrieval flow sequence

---

캐싱

서버 캐싱뿐만 아니라, 사용자 웹 브라우저의 캐시도 활용하면 성능을 높이고 오프라인에서도 문서를 열어 보거나 수정할 수 있습니다.
클라이언트 애플리케이션은 IndexedDB나 로컬 스토리지 등 웹 브라우저 캐시로 로컬에서 변경 사항을 저장하고, 일정 간격으로 서버와 동기화할 수 있습니다. 이렇게 하면 다음 장점이 있습니다.

• 반응 속도 향상: 변경 사항이 로컬 캐시에 즉시 반영되므로 사용자 입장에서 더 빠르게 업데이트할 수 있습니다.
• 오프라인 지원: 인터넷이 끊겨도 문서를 열어 보거나 수정할 수 있으며, 변경된 내용은 연결이 복구되면 자동으로 서버와 동기화됩니다.
• 복원력: 네트워크가 잠시 끊기더라도 작업 내용이 사라지지 않고, 연결이 복구되면 자동으로 동기화됩니다.
• 서버 부하 감소: 변경 사항을 모아서 일정 간격으로 동기화하면 실시간 서버 요청 횟수를 줄일 수 있습니다.

오류 처리 및 데이터 일관성

데이터베이스에서 문서 메타데이터를 수정할 때는 트랜잭션과 개별 연산이 중간에 실패하지 않고 한 번에 처리되도록 보장하는 방식을 이용하여 데이터가 엉키지 않도록 합니다.

다른 서비스와 연동

문서 서비스는 협업 서비스, 접근 제어 서비스 등 파일 공유 시스템의 여러 서비스와 연동됩니다. 문서를 생성하거나 수정하면 문서 서비스는 협업 서비스에 이를 알립니다. 그러면 실시간으로 동기화되고, 누가 문서를 보고 있는지 등 정보가 업데이트됩니다.

확장성 및 성능

문서 서비스는 확장성과 높은 성능을 유지하기 위해 상태를 저장하지 않는 스테이트리스한 마이크로서비스 형태로 배포할 수 있습니다.

13.6.2 협업 서비스 설계

Figure 13.9: The Collaboration Service design

협업 서비스의 API 엔드포인트

• POST /collaborate/{documentId}: 문서에서 편집 모드로 전환합니다.
  • 요청 본문: 사용자 ID 및 세션 정보
  • 응답: 협업 세션 정보와 초기 문서 상태
• WebSocket /collaborate/{documentId}: 실시간으로 협업할 수 있도록 웹소켓 연결을 설정합니다.
  • 클라이언트는 웹소켓으로 협업과 관련된 이벤트를 주고받습니다.
• POST /presence/{documentId}: 문서에서 사용자 접속 상태를 업데이트합니다.
  • 요청 본문: 사용자 ID 및 접속 상태(예 온라인, 오프라인, 자리 비움)
  • 응답: 성공 또는 오류 메시지

협업 과정

Figure 13.10: A collaboration flow sequence

운영 변환

운영 변환은 실시간 협업을 지원하면서 문서의 일관성을 유지하는 기법입니다.
협업 서비스가 운영 변환 알고리즘을 적용하면, 여러 사용자가 동시에 문서를 편집할 때 발생할 수 있는 충돌이나 문제를 해결할 수 있습니다.
운영 변환의 핵심 개념은 현재 문서 상태와 이전에 적용된 작업 이력을 바탕으로 새로 들어오는 작업을 변환하는 것으로, 작업 순서와 관계없이 모든 사용자가 동일한 최종 문서 상태를 유지할 수 있도록 합니다.

접속 상태 관리하기

협업 서비스는 사용자의 접속 상태를 관리하여 협업 중인 사용자가 서로의 온라인 상태를 실시간으로 파악할 수 있도록 합니다.
사용자가 협업 세션에 참여하면 클라이언트는 /presence/{documentId} 엔드포인트로 접속 상태를 업데이트하는 요청을 보냅니다.
협업 서비스는 사용자의 접속 상태를 갱신하고, 변경 사항을 다른 협업 참여자에게 알립니다.

확장성 및 성능

협업 서비스는 확장성과 높은 성능을 유지하기 위해 상태를 저장하지 않는 스테이트리스 마이크로서비스 형태로 배포할 수 있습니다.
서비스 인스턴스를 여러 개 실행하고, 로드 밸런서를 사용하여 들어오는 요청과 웹소켓 연결을 분산하면 부하를 효과적으로 나눌 수 있습니다.
또 레디스 같은 분산 캐시를 활용하여 문서의 현재 상태와 접속 정보를 저장하면, 여러 서비스 인스턴스 간에 빠르게 데이터를 동기화하고 접근할 수 있습니다.

다른 서비스와 연동

협업 서비스는 문서 서비스를 연동하여 문서 내용을 가져오고 수정할 수 있도록 합니다.
협업 세션이 시작되면 협업 서비스는 문서 서비스에서 문서 초기 상태를 불러옵니다.
사용자가 문서를 수정하면 협업 서비스는 업데이트된 내용을 문서 서비스로 보내 영구적으로 저장합니다.

오류 처리와 복원력

협업 서비스는 다양한 장애 상황을 감지하고 복구할 수 있도록 오류 처리 메커니즘을 갖추고 있습니다.
문제를 효과적으로 파악하고 진단할 수 있도록 적절한 오류 로깅과 모니터링 기능을 포함하며, 네트워크 장애나 서비스 오류가 발생하면 클라이언트와 다시 연결을 시도하고 문서 상태를 동기화합니다.

기타 보안 고려 사항

협업 서비스는 공동으로 문서를 편집하고 있는 세션의 기밀성과 무결성을 보호하려고 여러 가지 보안 조치를 적용합니다.
데이터 전송 과정에서 보안을 강화하려고 HTTPS와 WSS 같은 안전한 통신 프로토콜을 사용하여 데이터를 암호화합니다.
또 접근 제어 메커니즘을 적용하여 허용한 사용자만 협업 세션에 참여하고 문서 내용을 확인할 수 있도록 제한합니다.

13.6.3 접근 제어 서비스 설계

Figure 13.11: Access control service design

접근 제어 서비스의 API 엔드포인트

• POST /auth/login: 사용자 인증을 수행하고 액세스 토큰을 발급합니다.
  • 요청 본문: 사용자 인증 정보(예 아이디, 비밀번호)
  • 응답: 인증이 성공하면 액세스 토큰과 사용자 정보 반환
• POST /auth/logout: 사용자의 액세스 토큰을 무효화하고 로그아웃합니다.
  • 요청 본문: 액세스 토큰
  • 응답: 성공 또는 오류 메시지
• GET /permissions/{documentId}: 특정 문서에 대한 접근 권한을 가져옵니다.
  • 요청 매개변수: 문서 ID
  • 응답: 해당 문서에 대한 사용자 권한 목록 반환
• POST /permissions/{documentId}: 특정 문서에 대한 사용자의 접근 권한을 부여하거나 수정합니다.
  • 요청 본문: 사용자 ID, 문서 ID, 권한 수준(예 읽기, 쓰기, 소유자)
  • 응답: 성공 또는 오류 메시지
• DELETE /permissions/{documentId}/{userId}: 특정 문서에서 사용자의 접근 권한을 제거합니다.
  • 요청 매개변수: 문서 ID, 사용자 ID
  • 응답: 성공 또는 오류 메시지

사용자 인증 과정

Figure 13.12: An authentication flow sequence

사용자 인가 과정

Figure 13.13: An authorization flow sequence

권한 관리

Figure 13.14: A permission management sequence

권한 철회

Figure 13.15: A revoking permissions sequence

데이터베이스 설계

Figure 13.16: An entity-relationship diagram for an Access Control Service database

캐싱 및 성능 최적화

레디스 같은 캐싱 시스템에 자주 조회하는 권한 정보 및 사용자 정보를 저장하면 접근 제어 서비스의 성능을 높일 수 있습니다.

13.7 기타 검토 사항 및 모범 사례

성능 최적화

• 서비스 여러 계층에서 캐싱 메커니즘 구현
• CDN 사용
• DB 쿼리 및 인덱스 최적화
• Lazy loading 기법 적용
• API 엔드 포인트 반환 개수를 제한해 페이지네이션 구현

데이터 일관성 및 동시성

• 동시 편집, 실시간 협업 환경에서는 중요
• 버전 번호, 타임스탬프를 활용한 낙관적 동시성 제어 기법 적용 => 동시 편집 시 발생하는 충돌 감지 및 해결
• 데이터 불일치 방지를 위해 분산 잠금이나 동기화 기법 활용
• 높은 가용성과 성능 유지를 위해 최종 일관성 모델을 적용하는 것을 고려

장애 내성과 복원력

• 로깅 시스템 구축
• 일시 장애를 위해 서킷 브레이커 패턴과 재시도 매커니즘 적용
• 이중화 및 복제 기술을 써서 서비스 가용성 유지
• 데이터 정기적 백업을 통해 장애 복구 절차 마련

확장성과 탄력성

• 수평 확장이 가능하도록 설계
• 자동 스케일 기법을 사용해 서비스 인스턴스 수를 자동으로 조절
• 로드 밸런싱을 적용해 서버 과부하 방지
• 메시지 큐와 비동기 처리 방식을 써서 서비스간 결합도를 낮춤

지속적 통합 및 지속적 배포

• 파일 공유 서비스 내에서 CI/CD 파이프라인 구축
• GIt 버전 관리 시스템 활용
• 단위, 통합, E2E 테스트를 자동화해 시스템 안정성 높임
• 도커와 쿠버네티스 오케스트레이션 플랫폼을 사용해 배포 및 서비스 운영을 효율적으로 함
• 배포 과정에서 서버 다운타임과 장애를 최소화 하기 위해 블루-그린 배포, 카나리 배포, 롤링 업데이트 같은 전략 사용