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

• 전체 읽기 (QPS, 데이터 볼륨)
  • 하루 평균 초당 60건
  • 하루중 최대 QPS
    • 점심시간 12시 ~ 13시 : 초당 1000건 (평균치의 20배)
    • 저녁시간 18시 ~ 19시 : 초당 1000건 (평균치의 20배)
    • 특정한 이벤트는 고려하지 않는다. (크리스마스, 말복)
• 전체 쓰기 (QPS, 데이터 볼륨)
  • 하루 평균 초당 0.5건
  • 하루중 최대 QPS
    • 서비스 오픈시 대량 등록후 시작하므로 운영중에 대량 등록할 일이 없다고 가정
    • 대량 등록의 기준은 초당 100건 이상
    • 대량 등록은 별도의 API를 이용하겠지만 여기선 생략
• 해당시스템은 하루 패턴이 정해져있다.
  • 평시 100 QPS를 목표로 서비스 한다.
  • 점심시간 저녁시간대 1,000 QPS를 목표로 서비스 한다.
  • 한국서비스이므로 새벽시간대 10 QPS를 목표로 서비스 한다.
• 처리량에 근거하여 Auto-Scaling 되는 아키텍쳐를 구성한다.

(2) 일관성 vs 가용성

• 일관성 필요여부, 일관성 구현 (Weak/strong/eventual)
  • 단순 검색 시스템이므로 평소 알관성에 문제는 없다.
  • 사업장 정보가 변경될경우 mongoDB upsert 후 즉시 redis를 Expire 하므로 일관성 문제는 없다.
• 가용성 필요여부, 가용성 구현 (Failover/replication)
  • 모든 구간의 이중화로 가용성 문제도 없다.

(3) 중요한 구성 요소에 대한 읽기/쓰기 시나리오를 위한 API

• 생략

(4) 데이터베이스 스키마

• 메인 스토리지로 mongoDB를 사용하므로 별도의 스키마는 없다.

(5) 활용하는 주요 알고리즘

• GeoHash

  • https://itlamp.tistory.com/14

• 직접 구현하지는 않고 mongoDB에 구현된 geometry 쿼리를 활용한다.

  • https://www.mongodb.com/ko-kr/docs/manual/tutorial/geospatial-tutorial/

  var neighborhood = db.neighborhoods.findOne( { geometry: { $geoIntersects: { $geometry: { type: "Point", coordinates: [ -73.93414657, 40.82302903 ] } } } } )
  db.restaurants.find( { location: { $geoWithin: { $geometry: neighborhood.geometry } } } ).count()