공부한 내용을 정리했습니다.

문제

  • 주변 친구의 기능을 가진 Application 설계
  • 사용자는 주변 친구의 목록을 받을 수 있음

요구사항

  • 사용자는 모바일에서 주변 친구 확인 가능 (거리, 시각 표시)
  • low latency - 주변 친구 위치 변화 반영이 너무 오래 걸리면 안됨
  • 일정 시간 지난 후, 사용하지 않으면 비활성화

설계

주변 친구 목록

  • 사용자의 위치를 매번 체크해야하는데 이것을 공통 백엔드 서버에서 받으면 처리가 힘들 수 있음
  • 웹소켓 서버를 세팅한 후, 사용자 별로 웹소켓에 연결시킴 -> 사용자 위치가 변경될 때, 웹소켓을 통해 Redis pub/sub 에 메시지를 전달 -> 특정 subscribe 에 연결된 다른 친구들의 웹소켓서버들은 그것을 받아 거리를 다시 계산
    • 여기서 Redis 를 선택한 이유는 비용이 적은 채널을 생성할 수 있기 때문
  • 시나리오
    • 클라이언트 위치 정보 웹소켓으로 전달 -> LB -> API 서버, 웹소켓 서버
      • LB -> API -> RDB (위치 정보 등)
      • LB -> 웹소켓 -> Redis pub/sub -> 친구 웹소켓에서 데이터를 가져가 거리, 시간 계산 -> 친구에게 전달

사용자 비활성화

  • 레디스에 위치 정보 캐시를 TTL 에 추가
  • TTL 이 지났다면 사용자 비활성화 처리

시스템 확장

웹소켓

  • 사용자 규모 늘어나면 웹소켓 서버를 늘리면 됨
  • 단, 기존 서버를 삭제할 때는 기존 연결이 종료된 후에 제거 필요
    • 신규 사용자가 삭제 대상인 웹소켓으로 연결이 될 수 있기 때문
    • 제거 예정인 기존 서버에 접근 못하도록 조치 필요

Redis

메모리 관점
  • 사용자 규모 늘어나면 위치 정보가 늘어날테고, 위치 갱신도 자주 일어날 것이다
  • Redis 를 클러스터로 구성하거나 특정 값을 기준으로 샤딩 처리를 하는 방안을 고민해볼 수 있음

기타

위치 정보 이력을 저장

  • 쓰기가 많이 일어날테니 쓰기에 적합한 데이터베이스 선택
  • 데이터가 늘어날수록 파티셔닝 or 샤딩 필요