LSS 개념 설계 및 기술 스택 선정

[not-for-me]

Location Search Service 제공을 위한 개념 설계와 함께 이를 기반으로 구현에 사용할 기술 스택을 정리한다.

[not-for-me]

• LSS 특성상 사용자 검색 질의에 대한 결과를 응답하기 까지 sync하게 block될 필요가 없어 api 컴포넌트에서 netty 기반의 webflux를 사용하여 요청당 스레드 모델이 아닌 이벤트 루프 방식을 사용하기로 한다.
• 다만 이 때는 외부 서비스의 장애를 고려하여 fail safe할 수 있는 로직을 함께 고려한다.
• 사용자의 질의 결과의 인기 검색어를 제공하는 기능은 저장소를 2가지로 분리하여 설계한다.
  • search log: 사용자의 질의 검색 요청 한 건의 로그
  • ranking snapshot: 일정 주기로 raw log에서 인기 검색어 순위를 추출
• 위와 같이 write와 read를 분리하고 인기 검색어 추출은 scheduler를 통해서 백그라운드에서 갱신한다.
  • 이 구조는 추출 범위의 데이터 양에 따라 전체에서 월간, 주간등으로 집계 범위를 조절하는데 용이하다.
  • 또한 write용 저장소는 필요에 따라 rdb혹은 elasticsearch를 선택할 수 있다.

이 개념 설계를 바탕으로 LSS 서비스의 기술 스택은 다음으로 결정한다.

• JDK 8: latest 버전을 따라가도 되지만 특이사항이 없으므로 8로 결정
• 프레임워크: 스프링 부트를 사용하는데 다음 모듈을 사용하기로 한다.
  • security: 사용자 기본 인증/권한 관리용
  • webflux: 클라이어언트 요청 처리
  • spring-data-jpa: orm용
  • cache: 빈번한 키워드의 경우 local cache를 사용하여 불필요한 외부 호출을 줄이고 응답 속도를 높이기 위해 사용한다. LSS에서는 구현체로 caffein을 사용한다.
• h2db: 샘플 프로젝트로 간단히 인메모리 db를 사용한다. jpa를 사용할 예정이므로 필요한 경우 다른 db로 변경하면 된다.
• Vue.js: 클라이언트 웹 애플리케이션은 간단한 SPA 구성을 위해 Vue.js를 사용한다.
• testing 라이브러리: 테스팅을 위해 junit, mockito, assertj를 사용한다.

[not-for-me]

사용자 인증부는 jdbc 와 통신을 해야하기 때문에 구조적으로 synchronous한 부분이 있지만 본 서비스에서는 인증 자체가 제한적으로 사용되므로 reactive 스타일을 유지하기로 한다.