[03일차] | 대규모 시스템 설계 기초2 | 책너두

2장 주변 친구

• 어떻게 보면 1장의 근접성 서비스와 굉장히 유사해 보일 수 있음.
  • 그러나 큰 차이가 하나 있는데, 사업장의 위치 정보는 정적이지만 친구의 위치 정보는 동적이라는 것이다.

1단계: 문제 이해 및 설계 범위 확정

• '주변'의 정의 - 얼마나 가까워야 '주변'인가?: 5mile
• 예상되는 사용자의 수: 1억명
• 사용자의 이동 이력을 저장할 수 있어야 함. 저장 기간은 미정
• 특정 시간이상 비활성 상태이면 주변 친구 목록에서 사라져야 함.
• 복잡도 조정을 위해 사생활 및 데이터보호 등 고려사항은 생략한다.

기능 요구사항

• 사용자는 모바일 앱에서 주변 친구를 확인 할 수 있어야 한다.
  • 친구와의 거리, 마지막으로 업데이트된 시간이 표기되어야 한다.
• 이 친구 목록은 실시간성으로, 일정 주기마다 업데이트 되어야 한다.

비기능 요구사항

• 낮은 지연시간
• 안정성: 전반적으로 안정적이어야 한다. 다만 몇개의 데이터 손실은 허용된다.
• 결과적 일관성(eventual consistency)
  • 사용자의 위치 정보는 실시간으로 업데이트 되지 않아도 된다.
  • 복제본 간의 동기화는 일정 시간 이후에 이루어져도 된다.

Q? 일관성의 종류에도 여러가지가 있는 것으로 기억한다. 어떤게 있나?

A. 일관성의 종류는 크게 세가지로 나뉜다.

• 강한 일관성(Strong Consistency): 모든 복제본이 동일한 시점의 데이터를 가지는 것
• 약한 일관성(Weak Consistency): 모든 복제본이 동일한 시점의 데이터를 가지지 않아도 되는 것
• 결과적 일관성(Eventual Consistency): 시스템에 더 이상의 업데이트가 없을 때, 결과적으로 모든 복제본이 최종적으로 동일한 데이터를 가지게 되는 것을 보장하는 일관성 모델

개략적 규모 추정

• 시스템의 규모 결정과, 주요 과제를 결정하기 위해 제약사항과 가정을 설정한다.
  • 주변친구의 범위는 5마일로, 약 8km이다.
  • 친구 정보는 30초마다 갱신되어야 한다.
    • 사람들은 걸어다닌다고 가정한다.
    • 걷는 속도로는 30초 미만에서는 의미있는 이동이 없기 때문이다.
• 평균적으로 이 기능을 활용하는 유저는 매일 1억명으로 가정한다. (DAU 1억명)
• 동시 접속 사용자는 이 10%인 1천만명으로 가정한다.
• 한명의 사용자는 평균적으로 400명의 친구를 가지고 있다고 가정한다.
  • 편의상 친구로 등록된 모든 사용자는 주변 친구 서비스를 사용한다고 가정한다.
• 이에 따르면 QPS는 약 10,000,000 / 30s = 333,333(약 33만)이다.

⚠️ 이 QPS는 오직 주변친구를 조회하는 요청만을 의미한다.

2단계: 개략적 설계안 제시 및 동의 구하기

• 주변친구 기능에서는 실시간성이 중요하므로 데이터 구조보다는 이 통신방법을 먼저 결정하는 것이 중요하다.
  • 이는 일반적인 서비스와는 다르게 단순한 HTTP 프로토콜을 사용할 수 없을 수 있기 때문이다.

❗ 이 책에서는 일종의 '판단 템플릿'을 제시하지만 위 사례와 같이, 때로는 기능의 특성에 따른 융통성있는 판단이 필요함을 보여준다.

개략적 설계안

• P2P 통신을 사용: 이론상으로 가능하기야 하겠지만, 일반적인 서비스 구현에는 어려움이 많다.

• 공통 백엔드 서버 사용

  • 이는 일반적인 서비스 구현에 가장 적합한 방법이다.
  • 하지만 1천만명이 각각 4백명에게 정보를 30초마다 갱신 요청한다면 이는 일반적으로 처리하기 어렵다.

• Pub/Sub 시스템과 웹소켓을 활용한 설계

  • Pub/Sub 시스템을 통해 위치 정보 업데이트를 효율적으로 처리
    • 사용자의 위치 변경을 이벤트로 발행
    • 친구들이 해당 이벤트를 구독하여 실시간 업데이트 수신
  • 웹소켓 서버를 통해 클라이언트와의 실시간 통신 구현
  • RESTful API 서버는 친구 관리 등 기타 기능을 제공
  • TTL을 사용한 위치정보 캐시로, 일정시간 이상 비활성인 사용자를 제거
  • 위치 이동 이력은 별도의 DB에 저장