[1단계] 시스템 사용량 추정

(1) 처리량 (읽기/쓰기 쿼리에 대한 QPS)

• 내 주변 숙박업소를 검색하는 시스템을 검색하는 시스템을 만든다고 가정

  • 실제 데이터는 약 90만개 → 100만개로 가정

  

  • 가입자는 500만명
  • 서비스 대상은 국내 가정

• QPS 계산

  • 하루에 시스템을 사용하는 능동 사용자 (DAU)는 50만명 (전체 가입자의 10%)
  • 한 사용자는 하루에 평균 5번을 조회
  • 50만 * 5 = 하루에 250만건 조회
  • 250만건 / 10^5 = 초당 약 25건

(2) 시스템에서 예상되는 지연시간(읽기/쓰기 쿼리)

• 특정 조건 숙박업소 찾기
  • 하루 평균 초당 약 20건
  • 평균 응답 속도 400ms
• 내 주변 숙박업소 찾기
  • 하루 평균 초당 약 5건
  • 평균 응답속도 200ms
• 숙박 업소 상세 정보조회
  • 숙박업소 찾기의 절반정도의 빈도
  • 평균 응답속도 약 200ms
• 사업장 정보 등록/수정 (쓰기)
  • 일평균 QPS 5 미만
  • 숙박업소의 객실 상태를 주기적으로 갱신
  • 평균 응답 속도 1000ms

(3) 읽기/쓰기 비율

• 읽기:쓰기 = 100:1
• 특정 조건 숙박업소 찾기 API (읽기)
• 내 주변 숙박업소 찾기 API (읽기)
• 객실 정보조회 API (읽기)
• 객실 상태 등록/수정 (쓰기)

(4) 트래픽 추정치

• 전체 쓰기(QPS, 데이터 볼륨)
  • 5 QPS
• 전체 읽기(QPS, 데이터 볼륨)
  • 25 QPS

(5) 스토리지 추정치

• 객실 정보
  • 개당 데이터 사이즈 : 100KB
  • 전체 데이터 사이즈 : 50만개 * 100KB = 50GB
• 메인 스토리지
  • Postgres DB

    • 객실에 대한 다양한 쿼리 및 전체 데이터 증가 추세 및 AP의 단순성을 유지 하기 위해서 PG 선택

    • 객실에 대한 메타정보(스키마가) 수시로 변경될것으로 예상되지 않기에 RDB로 선택함

    • 또한 PG 자체적으로 PostGIS 라는 강력한 GIS 도구를 지원하여 GeoHash 이상의 기능을 사용할수 있음

      Geohash vs. PostGIS

    • HA 구성시 Hot Standby Mode 를 사용하여 Standby Server 를 read only query를 이용할수 있도록 구성

  • 하드웨어 구성 (2식)
    • 4Core
    • 16G RAM
    • 300GB SSD Disk (70% 사용시 2배수로 증설)

(6) 메모리 추정치

• geohash를 사용하지않고 postGIS의 GIST 인덱스만으로도 충분히 활용이 가능할것으로 판단되어 별도의 캐싱 레이어는 도입하지 않음

[2단계] 높은 수준의 디자인

(1) 지연시간 및 처리량에 대한 명확한 요구사항

• 전체 읽기 (QPS, 데이터볼륨)
  • 일 평균 25QPS
  • 피크타임 QPS
    • 1800 ~ 200 : 250 QPS 평균 10배
    • 특정 이벤트는 고려하지 않음
• 전체 쓰기 (QPS, 데이터볼륨)
  • 일 평균 5 QPS
  • 피크타임 QPS
    • 1800 ~ 200 : 50 QPS 평균 10배