[개발일지04] API 호출 검색 기능을 엘라스틱 서치로 변경하기 #1

250219

250226

250304

 

약 3주동안 항상 해왔던 소리

엘라스틱 서치와 친해지고 오겠다. . .

를 드디어 실행하는,,

그래도 나름 백엔드 지망생으로서

코드를 쳐보고 싶었으니깐요

기대된다 ! ! ! ! 

 

---

요구사항

기존 Rest API를 사용하였던 각종 검색 기능을 Elastic Search로 변환하기.

 

예상 적용 범위

	이름	URI	MEMO
1	회원 목록 조회 API	/api/v1/members/search?keyword={keyword}	‘나의 앨범’ 태그 검색 or 앨범 생성시 사용자 검색 시에 사용 닉네임 검색시, 포함하는 닉네임 목록 반환
2	앨범 검색 API	/api/v1/albums/search?keyword={keyword}	사용자가 포함된 앨범을 키워드 검색하여, 최신순 조회 앨범명, 포함된 사용자 검색
3	태그 내 앨범 검색 API	/api/v1/albums/tag?keyword={keyword}	태그에서 검색 시 앨범 조회 기능입니다. keyword로 검색이 가능합니다.

 

• 추가로 담당자와 논의 필요
• 아마 3번만 바꾸면 될 것 같음

 

예상 Flow

• Spring Data Elasticsearch 의존성을 주입
• @ElasticsearchDocument class 생성
  • 앨범 field값: id, 앨범 명, 구성 인원
  • 멤버 field값: id, 이름
• EntityListeners를 통한 MySQL 업데이트 - 엘라스틱 서치 동기화

 

고려 사항

ElasticsearchDocument 내 저장할 field 값들

후 유지보수를 위해, 최소한의 구별 값들만 저장 후 일반 서비스단에서 returnDto로 변환하는 과정 적용

 

MySQL과 Elasticsearch 동기화 작업: 이중 작성, 이벤트 리스너, 메시지 큐

• 이중 작성
  • MySQL 및 Elasticsearch 내 crud 작업 코드 추가
  • 일관성 문제 발생 가능
  • 불편함
• 이벤트 리스너
  • 비교적 간단하게 구현 가능
  • 비동기 처리
• 메시지 큐(RabbitMQ, Kafka)
  • 어떻게 보면 결합도를 낮추고 응집도를 높이는,, 가장 이상적인,,
  • 후에 플젝 확장성을 본다면 가장 이상적인 선택
  • 서버 남은 공간이 많지 않음
  • 대공사(살짝 과할수도)
• 나머지(배치, CDC)
  • 프로젝트나 팀에 상황과 맞지 않음

그래서 JPA 이벤트 리스너를 사용하고자 합니다..