[Line Music 발표영상 공부] 대규모 음악 데이터 검색 기능을 위한 Elasticsearch 구성 및 속도 개선 방법

 

- 2021 Korean version -

LINE MUSIC에서는 음악을 제공하는 음악 레이블에 특화된 음악 정보 전문 검색 기능을 제공하고 있습니다.
전문 검색에는 Elasticsearch를 활용하는데요.
음악 데이터가 워낙 방대해 응답 성능이 저하되는 것이 실용화하는 데 큰 걸림돌이었습니다.
이에 매핑 정의와 데이터 전처리, 검색 쿼리 등 다양한 검색 프로세스를 실용화하기 위한 연구가 필요했습니다.
이번 세션에서는 전문 검색 기능을 개발하면서 겪었던 검색 항목 확대에 따른 성능 저하와 API 공개에 따른 부하 증가 등의 문제점을 짚어본 뒤 그 해결 방법을 소개하고, 대규모 데이터를 다루는 Elasticsearch의 성능 개선 연구 결과에 대해 이야기하고자 합니다.

 

 

Case 1) search feature in CMS

 

곡정보를 갖는 Meta search api server -> Elasticsearch

 

Elasticsearch에는 8천6백만개의 곡이 들어있다. -> 방대함

 

Before

검색 결과 내용: 트랙명

After

검색 결과: 트랙명, 추가 트랙명, 앨범명, 아티스트명, 상품코드

-> 정보를 많이 제공하니까 검색 속도가 기존 1초에서 5초로 증가하게됨

 

<느려진 원인>

Before

• Data type: keyword. raw string
• Query: wildcad (term level query) ex) *bc* -> bc, abc, bcd, abcd 

After

• Data type: text, tockenize (n-gram)
• Query: match (full text query)

-> 데이터 타입과 쿼리를 바꾼 후 응답 속도가 개선됨.

 

Tokenize / N-gram & Dynamic query

 

Case 2) API for record labels

시스템 사용에 대한 증가로 Elasticsearch에 부하가 생겨 데이터를 증설했다.

 

<한정된 노드의 효과적인 사용을 위해>

• Shard and Replica 를 사용해야한다.
• Data Nodes <= Shards * (Replicas +1)

 

 

Benchmark 테스트를 통해서 Shard 6, Replica 1 일때가 최적의 성능이 나왔다고 한다.

-> 이를 기반으로 Data Node 18, Shard 6, Replica 1 로 세팅했다고 한다.