가상 면접 사례로 배우는 대규모 시스템 설계 기초 2편 정리 (1~4장)

1편 정리에 이어서 2편을 읽고 있습니다. 2편은 위치 기반 서비스가 연달아 나와서, 1장에서 배운 개념이 뒤 장에서 계속 재활용되는 게 재미있었어요.

2장부터는 그림과 예시를 곁들인 학습 노트를 따로 만들어서, 각 장 요약 아래 링크로 달아뒀습니다.

1장. 근접성 서비스

주변 식당·가게를 찾는 서비스를 어떻게 설계할지에 대한 장입니다. 핵심은 위치를 어떻게 색인하느냐입니다.

지오해시

• 비트를 하나씩 늘려가며 세계를 재귀적으로 더 작은 격자로 나눈다. 전 세계를 사분면으로 나누고, 각 격자를 다시 사분면으로 나누는 걸 원하는 정밀도가 나올 때까지 반복한다.
• 격자 가장자리 이슈
  1. 가까운 위치인데도 접두어가 다를 수 있다.
  2. 접두어 길이는 같아도 서로 다른 격자에 놓일 수 있다.
  • 해결: 현재 격자와 인접한 모든 격자의 사업장 정보를 함께 가져온다.
• 사업장 수가 부족할 때: 그냥 있는 것만 반환하거나, 검색 반경을 키운다.

쿼드트리

• 격자 안의 사업장 수가 특정 기준(예: 100개 이하)을 만족할 때까지 사분면으로 분할한다.
• 질의에 쓸 트리 구조를 메모리 안에 만드는 방식이다.
  • 말단 노드: 꼭짓점 좌표(좌상단, 우하단), 격자 안 사업장 ID 목록
  • 내부 노드: 꼭짓점 좌표, 하위 노드 4개를 가리키는 포인터
• 검색 시에는 루트부터 내려가며 검색 시작점이 포함된 말단 노드를 찾는다.
• 고려사항: 트리를 구축하는 데 몇 분이 걸리고, 그동안은 트래픽을 처리할 수 없다.
  • 해결책으로 블루-그린 배포, 또는 점진적 갱신(가장 쉬움)이 있다. 점진적 갱신은 "새로 추가된 사업장은 다음 날 반영"처럼 정책으로 풀 수 있지만, 많은 키가 한꺼번에 무효화되면 캐시 서버에 큰 부하가 갈 수 있다.

구글 S2

• 지오펜스 구현에 좋다.
• 임의 지역에 다양한 수준의 영역을 지정할 수 있어서, 스쿨존이나 동네 경계처럼 이미 있는 경계선을 묶어 설정할 수도 있다.

지오해시 vs 쿼드트리

고가용성을 확보하고 대륙을 넘나드는 전송 지연을 줄이려면, Redis 클러스터를 지역별로 두고 같은 데이터를 각 지역에 중복 저장해야 합니다.

아직 이해 못 한 부분: "지금 영업 중인 곳만 보고 싶다"면, 지오해시나 쿼드트리로 얻는 사업장 수가 상대적으로 적으니 근처 사업장 ID를 전부 가져온 뒤 정보를 꺼내 필터링한다고 합니다. 색인으로 후보를 먼저 좁히고 그 안에서 조건을 거르는 건지, 스터디에서 더 이야기해보고 싶어요.

2장. 주변 친구

1장이 "움직이지 않는 가게"를 찾는 문제였다면, 2장은 계속 움직이는 친구의 위치를 실시간으로 보여주는 문제입니다.

• 활성 친구의 최근 위치는 DB가 아니라 Redis 캐시에 둔다. 현재 위치 하나만 있으면 되고, TTL로 비활성 사용자를 자동 정리할 수 있다.
• 위치 변경은 Redis Pub/Sub으로 친구들에게 전파한다.
• 웹소켓 서버와 Pub/Sub 클러스터는 유상태(stateful) 라서 서버를 늘리고 줄일 때 신중해야 한다.
• 주변의 임의 사용자까지 보여주려면 지오해시별 채널을 만들고, 격자 경계 문제를 피하려고 주변 격자까지 총 9개 채널을 구독한다.

👉 주변 친구 학습 노트 전체 보기

3장. 구글 맵 · 4장. 분산 메시지 큐

• 구글 맵: 무거운 건 미리 계산해서 CDN·객체 저장소에 두고, 실시간성이 필요한 부분만 스트리밍으로 처리한다. 지도 타일과 라우팅 타일, 최단 경로(캐시 가능)와 ETA(실시간)를 분리하는 이유가 핵심.
• 분산 메시지 큐: 카프카 스타일 이벤트 스트리밍 플랫폼. 파티션이 순서와 병렬성의 단위이고, WAL과 세그먼트로 순차 I/O를 얻고, ISR과 ACK 설정으로 지연과 지속성 사이의 균형을 잡는다.

두 장 모두 "일괄 처리로 쓰기를 줄이고, 적절한 단위로 쪼갠다"는 1편의 원칙이 그대로 이어져서, 한 페이지에 비교하며 정리했습니다.

👉 구글 맵 / 분산 메시지 큐 학습 노트 전체 보기