대규모 음악 데이터 검색 기능을 위한 Elasticsearch 구성 및 속도 개선 방법
- DAY2 14:40-15:00 KST
- Youtube link
배경
- 라인 뮤직에서는 곡 정보를 웹 UI로 접근하거나 API를 통해 메타데이터를 취득할 수 있음.
- Meta Search API 서버를 만들어 리퀘스트 발생시 Elasticsearch 로 검색함.
검색 기능 개선
-
곡 이름으로 검색하는 것만 지원했으나, 앨범 선정 혹은 아티스트 곡을 찾는 요구 등을 충족할 수 없었음.
-
트랙명, 앨범명 등등으로도 검색 가능하도록 추가하였으나, 검색 시간이 1초에서 5~6초로 느려짐
-
느렸던 이유는 wildcard 를 이용한 term level query 를 사용하였기 때문
- -> 공식 레퍼런스에도 기재되어있듯 backwoard match (* 로 시작하는 검색)은 느림.
-
키워드 타입 - ES 의 고속 검색을 가능케하는 텍스트 타입
-
하지만 wildcard 로 검색하니 너무 느림
-
말뭉치로 분리하는 토크나이즈가 필요하고, 아티스트나 앨범명 등에는 사전에는 없는 신조어 등도 많이 쓰이기 때문에 일반적으로 사용하는 토크나이즈가 유효하지 않음.
-
데이터타입을 키워드에서 text 로 바꾸고, analyzed field 를 사용
-
쿼리는 와일드카드에서 match로 변경함
-
사전 대신 n-gram 을 이용한 토크나이즈를 수행함.
-
쿼리는 full text query 로 match 하도록 함.
-
검색 문자열 길이에 따라 n-gram 의 n 값을 동적으로 변경함
-
필드 개수가 늘어남에 따라 match 쿼리 속도가 매우 크게 차이남
- 11개 기준 wildcard 4.6초, match 0.2초
요약
-
와일드카드 backward 쿼리는 느리므로 큰 데이터에서 유용하지 않음
-
고유명사가 많이 들어간 경우 사전을 이용한 토크나이즈는 부적합하므로 n-gram 토크나이즈가 유용
-
레코드 라벨에 대한 API 를 추가하였으나, 곡 수가 많아 ES 가 병목 현상이 나와 인프라 확장을 시도함
-
Master Node 와 DataNode 중 Data Node 를 늘려 부하를 분산하여 검색 성능 향상 시도. -> 비용 증가.
-
사내 ES에 노드수 제한이 있어 곡 수와 서비스 품질, 비용을 비교하여 증설하는 것으로 결론냄.
한정된 수의 노드로 효율높게 쓰기.
-
샤드는 데이터를 수평 분할한 단위.
-
샤드가 셋이면 셋으로 분할하여 분산하는 단위.
-
레플리카는 복제 단위. -> 가용성 증가
-
데이터노드 수와 샤드 배치에 따라 부하 성능 개선에 공헌 가능.
-
Data Node 수가 Shards * (replicas +1 ) 보다 크면 데이터 노드가 쓰이지 않고 남게됨.
-
Data Nodes <= Shards * (replicas +1 )이어야함.
부하 시험 결과
-
Data Node 18, shards 6, replicas 2 로 결정함
-
replicas 2로 충분히 가용성이 확보되어 3은 고려하고 있지 않음.
-
데이터 수에 따라 최적 샤드 수가 변경되므로 수시로 정비 및 변경이 필요함.
-
부하 시험을 할 수 있는 정비 환경이 마련된 것이 큰 수확.
요약
-
backward wildcard 쿼리는 느리기 떄문에 text형 match 쿼리로 변경.
-
단문이면서 고유명사가 많으면 사전을 이용한 토크나이즈가 어려우니 n-gram 으로 토크나이즈 보장.
-
api 개방 사례에선 부하를 ES가 견딜 수 없어 데이터노드를 증설
-
한정된 데이터노드 수를 화룡하기 위해 샤드 수, 레플리카수를 최적화 시도.
-
샤드수는 데이터량에 따라 성능에 차이가 있기 때문에 실제 성능 측정이 필요함. 부하 측정이 필요.
