•
앱 사용자 중 본인 위치 정보 접근을 허락한 사용자에 한해 인근의 친구 목록을 보여주는 시스템이다.
1단계: 문제 이해 및 설계 범위 확정
•
요구사항 가정
◦
주변의 정의, 여기선 대략 5마일로 설정하며 수정이 가능
▪
그 거리의 정의, 직선 거리인지? 이동까지 걸리는 거리인지
⇒ 보통은 복잡도 때문에 직선 거리를 사용할 것 같음
◦
사용자의 수, 그리고 그 중 이 기능을 사용하는 사용자의 수
◦
사용자의 이동 이력 저장 여부
◦
활성, 비활성 등 상태에 따른 표시 여부
▪
10분 이상 비활성화 상태일 경우, 주변 친구 목록에서 제외
◦
규제 사항, GDPR, CCPA 등의 사생활 및 데이터 보호법 적용 여부
기능 요구사항
•
사용자는 주변 친구를 확인할 수 있어야 한다. 주변 친구는 해당 친구까지의 거리, 해당 정보가 마지막으로 갱신된 시각이 함께 표시
•
이 친구 목록은 일정 주기로 한 번씩 갱신
비기능 요구사항
•
낮은 지연 시간
•
안정성 : 어느정도의 유실은 감수
•
결과적 일관성 : 위치 데이터를 저장하기 위해 강한 일관성을 지원하는 데이터 저장소를 사용할 필요는 없음
개략적 규모 추정
•
개럊주변 친구는 5마일 반경 이내의 친구로 정의
•
친구 위치 정보는 30초를 주기로 갱신
◦
이 수치는 사람이 보통 걷는 속도를 기준으로 한다.
◦
데이터가 변경되지 않는 동안에는 조회를 반복적으로 수행할 필요가 없다.
•
평균적으로 이 기능을 사용하는 사용자는 1억 명으로 가정
◦
하루 앱 사용자 10억 중 10%가 이 기능을 사용한다고 가정한다.
•
사용자의 평균 친구 수는 400명으로 가정, 그리고 모두가 주변 친구 검색 기능을 활용
•
페이지 당 대략 20명의 주변 친구를 표시하고 무한 스크롤이 가능하다.
•
QPS 계산
◦
DAU : 100,000,000
◦
동시 접속 사용자 : 10,000,000
◦
사용자는 30초마다 자기 위치를 시스템에 전송
◦
위치 정보 갱신 QPS는 대략 10,000,000 / 30 = 334,000
2단계: 개략적 설계안 제시 및 동의 구하기
•
이번 절에서는 다음 내용을 구성
◦
개략적 설계
◦
API 설계
◦
데이터 모델
•
기능의 특성 상, 지속적으로 연결을 유지해주어야 하기 때문에 HTTP 프로토콜을 사용하지 못할 수 있음을 감안
개략적 설계안
•
개념적으로 사용자는 근방의 모든 활성 상태 친구의 위치 정보를 주기적으로 수신
•
1대1로 요청을 수행할 수도 있겠지만 위치 변화 내역을 구독 대상들에게 전달하는 형태의 pub-sub 구조가 더 적합
설계안
•
웹소켓 서버
◦
친구 위치 정보 변경을 거의 실시간에 가깝게 처리하는 유상태 서버 클러스터로 각 클라이언트는 최소 한 대와 웹소켓 연결을 지속적으로 유지
◦
검색 반경 내 친구 위치가 변경되는 경우, 해당 내역은 이 연결을 통해 클라이언트에 전달
•
위치 정보 캐시 레디스
◦
특정 활성 시간 동안 갱신되지 않는 사용자는 비활성 상태로 바뀔 수 있도록 상태를 확인하는 용도의 캐시
•
위치 이동 이력 데이터베이스
•
레디스 pub/sub 서버
3단계: 상세 설계
중요 구성요소별 규모 확장성
•
웹소켓 서버
◦
유상태 서버로 기존 서버를 제거 시에 주의가 필요, 노드 제거 전 기존 연결 종료가 필요
•
클라이언트 초기화
◦
앱 접속 시, 웹소켓 클러스터 내의 서버 가운데 하나와 지속성 웹소켓 연결을 맺음
4단계: 마무리
•
이 설계안의 핵심 컴포넌트는 다음과 같음
◦
웹소켓
◦
레디스
◦
레디스 pub/sub
