Design Facebook - 뉴스피드를 단순 게시판으로 설계하면 왜 Meta 면접에서 탈락하는가
근처 친구들을 찾는 페이스북 시스템을 디자인합니다.
Step 1 - 문제 이해와 설계 범위 정하기
페이스북 규모의 어떤 백엔드 시스템이든 설계는 복잡하다. 따라서 설계를 시작하기 전에 범위를 좁히기 위한 명확화 질문을 먼저 해야 한다.
지원자
지리적으로 얼마나 가까워야 “nearby”라고 보나요?
면접관
5마일입니다. 이 수치는 설정 가능해야 합니다.
지원자
두 사용자 사이의 거리는 직선 거리로 계산한다고 가정해도 될까요? 현실에서는 예를 들어 두 사용자 사이에 강이 있어서 실제 이동 거리가 더 길 수도 있습니다.
면접관
네, 그건 합리적인 가정입니다.
지원자
이 앱은 사용자가 몇 명인가요? 10억 명의 사용자가 있고, 그중 10%가 nearby friends 기능을 사용한다고 가정해도 될까요?
면접관
네, 그건 합리적인 가정입니다.
지원자
위치 이력을 저장해야 하나요?
면접관
네, 위치 이력은 머신러닝 같은 여러 목적에 유용할 수 있습니다.
지원자
친구가 10분 이상 비활성 상태이면 nearby friend 목록에서 사라진다고 가정할 수 있을까요? 아니면 마지막으로 알려진 위치를 보여줘야 하나요?
면접관
비활성 친구는 더 이상 표시되지 않는다고 가정합시다.
지원자
GDPR이나 CCPA 같은 프라이버시 및 데이터 법률을 걱정해야 하나요?
면접관
좋은 질문입니다. 단순화를 위해 지금은 신경 쓰지 않아도 됩니다.
Functional Requirements 기능 요구사항
사용자는 모바일 앱에서 근처 친구를 볼 수 있어야 한다.
nearby friend 근처 친구 목록의 각 항목에는 거리와, 그 거리가 마지막으로 업데이트된 시점을 나타내는 타임스탬프가 포함되어야 한다.
nearby friend 근처 친구 목록은 몇 초마다 갱신되어야 한다.
Non Functional Requirements 비기능 요구사항
지연 시간이 낮아야 한다.
친구의 위치 업데이트를 너무 큰 지연 없이 받아볼 수 있어야 한다.
신뢰성이 있어야 한다. 시스템 전반은 신뢰할 수 있어야 하지만, 가끔 데이터 포인트가 유실되는 정도는 허용 가능하다.
최종 일관성(eventual consistency)을 허용한다. 위치 데이터 저장소는 강한 일관성을 가질 필요가 없다. 서로 다른 복제본들이 위치 데이터를 받는 데 몇 초 정도 지연이 있는 것은 허용 가능하다.
대략적 규모 추정 - Back-of-the-envelope estimation
우리 솔루션이 다뤄야 할 잠재적 규모와 과제를 알아보기 위해 대략적인 계산을 해보자. 몇 가지 제약과 가정은 다음과 같다.
nearby friends는 반경 5마일 안에 있는 친구들로 정의한다.
위치 갱신 주기는 30초이다. 그 이유는 사람의 걷는 속도가 느리기 때문인데(평균 시속 3~4마일), 30초 동안 이동한 거리는 nearby friends 기능에서 큰 차이를 만들지 않기 때문이다.
평균적으로 1억 명의 사용자가 매일 nearby friends 기능을 사용한다.
동시 접속 사용자 수는 DAU(Daily Active Users)의 10%라고 가정한다. 따라서 동시 사용자 수는 1천만 명이다.
평균적으로 한 사용자는 400명의 친구를 가진다고 가정한다. 그리고 그 친구들 모두가 nearby friends 기능을 사용한다고 가정한다.
앱은 한 페이지에 20명의 nearby friends를 표시하며, 요청이 있을 경우 더 많은 nearby friends를 로드할 수 있다.
QPS 계산
1억 DAU
동시 사용자: 10% × 1억 = 1천만
사용자들은 30초마다 자신의 위치를 보고한다.
위치 업데이트 QPS = 1천만 / 30 ≈ 334,000
2. High-level Design 고수준 시스템 디자인 제안 및 합의 받기
High-level design
API design
Data model
다른 장들에서는 보통 high-level design 전에 API design과 data model을 먼저 논의한다. 하지만 이 문제에서는 클라이언트와 서버 사이의 통신 프로토콜이 단순한 HTTP가 아닐 수 있다. 왜냐하면 근처 친구 모두에게 위치 데이터를 push해야 하기 때문이다. High-level design을 이해하지 못하면 API가 어떤 형태여야 하는지 알기 어렵다. 따라서 여기서는 먼저 high-level design을 다룬다.
High-level design
고수준에서 보면, 이 문제는 효율적인 메시지 전달(message passing)이 가능한 설계를 요구한다. 개념적으로, 사용자는 근처의 모든 활성 친구로부터 위치 업데이트를 받고 싶어 한다. 이론적으로는 이것을 순수한 peer-to-peer 방식으로 구현할 수 있다. 즉, 사용자가 근처의 다른 활성 친구 각각과 지속 연결을 유지하는 것이다.
Peer-to-peer
하지만 이 설계는 연결이 종종 불안정하고 전력 소비 예산이 빡빡한 모바일 기기에는 실용적이지 않다. 다만, 이 아이디어는 전체 설계 방향에 대한 통찰을 줄 수 있다.
좀 더 실용적인 설계는 공유 백엔드를 두는 방식이며, 형태는 다음과 같다.
