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

3단계: 상세 설계

• 주요 관심사
  • 데이터베이스 규모 확장
  • 지리정보 색인의 규모 확장
  • 캐시
  • 지역 및 가용성 구현
  • 시간대, 사업장 유형에 따른 검색
  • 최종 아키텍처 다이어그램

데이터베이스 규모 확장

• 위치 기반 서비스를 이전 단계에서 LBS 서비스와 사업장 서비스, 두 개로 나누었다.

  • LBS 서비스
  • 사업장 서비스

• 즉, 각 위치정보(지오해시)에 속한 사업장 ID를 관리할 방법을 마련해야 한다.

  • 방안 1: 각 지오해시에 모든 사업장 ID를 JSON 형태로 저장한다.
    • 관리가 어렵고, 확장도 어렵다.
  • 방안 2: 지오해시와 사업장 ID 각각을 묶어 하나의 row로 저장한다.

지리정보 색인의 규모 확장

• 앞서 2억건의 지리정보라고 할지라도, 하나의 서버에 저장할 수 있는 수준임을 확인했다.
  • 따라서 샤딩 등의 분할 저장은 필수적이지 않다.
  • 또한 지오해시는 샤딩 로직을 어플리케이션에서 직접 구현해야 하기 때문에, 까다롭다.

Q? 지오해시의 샤딩 로직은 왜 까다롭다고 하는것일까?

A. 앞서 다루었듯, 연속적이지 않은 구간이 있다는 면에서도 까다롭고, 각 구획별로 데이터의 양이 균일하지 않기에 핫스팟 문제가 발생할 수 있다.

• 결과적으로 데이터베이스를 다중화 하는것으로 충분하다.

캐시

• 캐싱에서 가장 중요한 질문은 '정말 필요한가?'이다.

  • 캐싱은 복잡도를 높이고, 유지보수를 매우 어렵게 만든다.

• 캐싱을 사용함에 있어서 중요한 또다른 요건은 명확한 캐싱키를 정의하는 것이다.

  • 사용자의 위/경도가 가장 먼저 떠오르지만, 아래와 같은 문제가 있다.
    • 사용자의 위치는 정확하지 않다: 위경도는 소수점 6자리 이하까지도 표기되며, 움직이지 않아도 수시로 변화한다.
  • 지오해시나 쿼드트리의 결과를 캐싱키로 사용하는 것이 더 나을 수 있다.

Q? 또 다른 캐싱키는 어떤게 있을까?

A. 위경도를 특정 단위로 반올림하여 사용하는 것도 좋을 것 같다.
명확한 비즈니스 목표가 있는것이 아니라면, 지오해시나 쿼드트리의 결과 자체를 캐싱키로 사용하는 것이 가장 효과적일 것으로 보인다.

• 캐시할 데이터의 유형은 다음과 같다.
  • 지오해시(혹은 다른 캐싱키)에 속한 사업장 ID
  • 사업장 ID에 대한 상세 정보

지역 및 가용성 구현

• 지역 및 가용성을 고려할 때 기대할 수 있는 이점은 다음과 같다.
  • 실사용자와 시스템 사이의 물리적 거리를 줄일 수 있다.
    • 이는 지연시간을 줄이고, 사용자 경험을 향상시킨다.
  • 트래픽을 주변 인구에 따라 분산시킬 수 있다.
    • 이를 통해 보다 융통성 있는 서비스를 제공할 수 있다.
  • 지역별로 다른 규제와 법률을 준수할 수 있다.

❗ 지역별로 다른 규제와 법률을 준수하기 위한 분리라는 관점은 생각해보지 못했던 부분이다.

시간대, 사업장 유형에 따른 검색

• 한 번 지역별로 쿼리된 결과는 상당히 소규모이다.
• 따라서 시간대, 혹은 사업장 유형별 검색 등의 기능은 쿼리 후 필터링하는 것으로 충분하다.

최종 아키텍처 다이어그램

• 생략

4단계: 마무리

• 이번 장에서 다룬 주요한 개념들은 아래와 같다.
  • 지오해시, 쿼드트리, 구글 S2 등의 지리정보 색인 방법
  • 데이터베이스 규모 확장
  • 지역 및 가용성 구현