<aside> 💡 12만여개의 링크와 링크를 담고 있는 컨텐츠, 회원을 한번에 검색하고, 항목별로 나누어볼 수 있는 검색 API를 개발하였습니다. ElasticSearch를 활용하여 개발하였습니다.

이후 데이터가 커지면서 AWS Opensearch Service에서 발생한 indexing 과정의 부하를 해결하였습니다.

</aside>

구현된 형태

기존 프로덕트와의 비교

기존 프로덕트의 문제점

• 검색된 컨텐츠가 항목별로 분리되지 않아, 링크, 카테고리, 픽 컨텐츠를 모두 한 곳에서 보아야 함
  • 컨텐츠가 소속된 경로를 알 수 없음
• single-node를 활용하여 안정성이 낮음
• 픽 index에서 카테고리, 링크를 nested하고 있어 한 index의 용량이 지나치게 큼
  • 한 index에 대해 update가 자주 발생함
• 검색의 영역이 '자신의 컨텐츠'로 한정되어 있음
• 띄어쓰기가 포함된 단어 검색 시 OR 검색이 되어 기획과 맞지 않음
  • ex: "개발자 취업" 검색 시 "개발자", "취업" 모두 포함한 컨텐츠가 검색되도록 하는 것이 기획 의도였으나, 두 단어 중 하나만 포함한 컨텐츠도 함께 검색되는 문제

개선된 방향

• 컨텐츠 항목별로 index를 나누어서 관리

  • 항목별 view가 가능하도록 수정됨

    • 항목별 검색결과 count api 개발

  • 컨텐츠 경로를 함께 보여주는 것이 가능해짐

    

  • update가 한 index에 몰려서 발생하지 않음

  • 각 index로 데이터가 분산되어, 지나치게 큰 index가 없음

  • index를 나눔으로써 발생한 index 간 relation으로 인한 update 문제는 signal, celery를 활용하여 비동기처리로 해결

• multi-node로 확장
  • 안정성을 높임
• 검색의 영역을 전체 데이터로 확장
• 검색 기록, 자동완성 기능 추가
  • 검색 시 사용하는 analyzer와는 별개로 ngram-analyzer를 생성하여 검색어 history, 자동완성에 활용
• AND operator를 사용하도록 수정
  • **사용 중인 패키지의 소스를 상속받아온 class를 수정하여 custom**, search에서 사용하는 operator 수정
  • 기획 의도에 맞도록 analyzer 코드 수정
    • 캐릭터 필터, 토크나이저, 토큰 필터 변경
• AWS Opensearch service의 용량 문제 해결
  • RAM, disk 용량 관리

관련 자료