[MSA 경험기] 모아 구독 (6) 검색 히스토리 서비스 (by. NoSQL, Singleton)

지난 글

이전 글 에서는 Query Profiling을 통한 Query 시간 최적화에 대해 작성하였었다.

https://yubi5050.tistory.com/223

[MSA 경험기] 모아 구독 (5) Query Profiling을 통한 최적화

 

이번 글 에서는 '검색 히스토리 서비스 - 최근 검색어, 추천 검색어'를 구현하면서 고민하였던 부분들에 대해 작성해 보려고 한다.

 

BE에서는 검색 결과에 대한 구독 상품 조회 API와 검색 히스토리 API를 

 

고민한 부분은 아래 두 가지이다.

• 검색 히스토리 DB를 RDB와 NoSQL 중 어떤 DB를 사용할 것인지
• DB에 Connection 객체를 싱글톤 패턴으로 재사용 하기

 

RDB vs NoSQL 

우선 '모아구독' 서비스에서 구현할 기능인 최근 검색어, 추천 검색어의 특징에 대해 정리해보면 다음과 같았다.

• 조회 (검색어 목록 조회), 삽입(검색어 저장)이 빈번하게 발생
• 저장되는 Schema 정보가 단순함
• 검색어가 영구적으로 저장되어야 함
• 검색어 조회시 일정 갯수의 값만 응답

 

검색 DB는 최종 NoSQL의 MongoDB를 선택 하기로 했고, 그 근거는 다음과 같다

 

📌 1. 저장될 Schema가 다른 테이블과의 연관도가 적었다.

검색 히스토리에 대한 Schema는 '유저id', '검색단어', '검색 시간' 정도로 구성하였고, 다른 Table, Collection과의 관계가 없어, 독립적으로 저장되고 유지되는 것이 MSA의 취지에 맞다고 생각했다.

 

검색 저장 정보

 

📌 2. 최근 검색어와 추천 검색어는 읽기가 빈번한 기능이다.

검색 화면에서 ①, ② 기능의 경우 내가 검색한 검색어나, 남들이 검색한 검색어를 읽어오는 읽기가 빈번한 기능이라고 생각했다. (ex. 검색 화면 접근시 마다, 자동으로 추천 검색어가 바뀜)

'모아 구독' 검색 화면

 

📌 3. 검색 히스토리를 저장하는 것이 이후 기능 확장에 좋고, Redis의 Caching을 활용하기 어렵다.

NoSQL로 방향을 정하고서 Redis(In-memory-db) vs MongoDB(Disk DB)중에 고민하였는데,

 

최근 검색어나 추천 검색어는 빈번하게 Read 해오는 값이 바뀌기 때문에, In-memory DB로 캐시를 통해 성능을 높이는데 활용되는 Redis는 해당 장점을 발휘하기 어렵다고 생각했고, 

 

추가로 물리적인 디스크에 검색 로그를 저장하여, 향후 추가적인 기능 확장의 가능성을 위해서라도 MongoDB가 더 적절하다고 판단했다.

 

싱글톤 패턴 적용하기

DB를 연결할 때마다, Connector 객체가 호출되는데, 빈번한 호출에 매번 객체가 생성되면 비효율적일 것 이라고 생각했다.

대표적인 개선 방법이 싱글톤 패턴을 활용해 최초 생성된 인스턴스를 재사용 하는 것이였고, 일전에 싱글톤 패턴을 공부해본 적이 있어 적용해 보았다.

 

https://yubi5050.tistory.com/187

[디자인패턴] Singleton Pattern (+객체의 생성과 초기화)

 

📌 싱글톤 패턴 코드 적용

아래 왼쪽 코드에서 작성된 __new__와 __init__의 차이는 다음과 같다.

• __new__ : 객체의 생성 과정시 호출
• __init__ : 생성된 객체에 속성(property)를 초기화시 호출

 

따라서 기존 Object의 __new__ 메소드를 오버라이딩 하여, 인스턴스가 한번만 생성 되게 작성하면, 이후 오른쪽 코드를 통해 여러번 인스턴스를 생성하는 메소드를 호출해도 기존의 인스턴스가 활용되게 되는 것이다.

 

싱글톤 패턴 코드 작성

 

📌 싱글톤 API 호출 테스트

첫번째 API를 호출하면, __new__ 메소드와 __init__ 메소드가 최초로 실행되며, 객체가 만들어지고

두번째 API 호출부터는 __new__ 메소드와 __init__ 메소드가 호출되지 않고, 인스턴스 값도 기존 인스턴스 값이 출력 되는 것을 알 수 있다.

 

싱글톤 패턴 API 테스트