반응형

엘라스틱서치

    Line 세미나. 대규모 음악 데이터 검색 기능을 위한 Elasticsearch 구성 및 속도 개선 방법 - 2. 클러스터 튜닝

    문제상황 - cms 이외에도 외부에 api server를 열어서 데이터를 저장할 수 있도록 열어줬는데 데이터 부하가 되면서 elasticsearch에 부하가 오고 data node가 100프로 되는 등 문제가 발생된다. - 처음에는 쿼리 튜닝등의 방식으로 문제를 해결하였으나 data node의 cpu가 100프로가 되는등의 문제가 계속 유지되었다. - 데이터 노드를 늘림으로서 검색을 여러 서버로 분산하기 때문에 검색 속도를 늘릴 수 있었다. 하지만 비용이 너무 많이 들었다. - 어느 회사든지 간에 끊임 없는 수평확장은 어렵다. 해결방안 - shard와 replica를 구성하여 부하를 여러 노드로 분산하고 가용성을 늘림 - shard와 replica는 일반적인 규칙이 없다. - 상황에 따라 어떤 shard..

    Line 세미나. 대규모 음악 데이터 검색 기능을 위한 Elasticsearch 구성 및 속도 개선 방법 - 1. 검색 쿼리 개선

    - 발표자 : Taku Tada 시스템 상황 - 유저가 곡을 검색 할 시 meta search api server에 요청이 들어오고 Elasticsearch에 검색을 요청한다. - 8천 500만건의 데이터가 엘라스틱 서치에 들어가 있다. - 지금 발표하는 내용은 음악에 대한 검색과 책 데이터등에서 활용될 수 있다고 생각한다. - 기존에 검색에 사용되던 플드는 오직 Track Name 하나 뿐이었는데 추후 기능 피처로 트랙이름, 부가적인 트랙정보, 앨범이름, 아티스트 이름, 레이블 프로덕트 코드, ISRC와 같응ㄴ 데이터를 조회 조건으로 같이 걸어야했다. 이로인해 기존에 1초 걸리던 검색이 5초 정도의 시간으로 증가하게 되었다. 느렸던 이유 - 기존에는 keyword 타입으로 와일드 카드를 이용해서 조회를..

    Nested field에 대한 대체 필드 flattened type

    일반적으로 하나의 공통 Document내에 서로 다른 속성을 가지고 있어서 별도의 Document인 것 처럼 저장하고 query하기 위해서 우리는 nested obejct 타입을 많이 사용한다. 사용했었던 예로는 가게 - 메뉴, 상품 - 아이템 정도이다. 하지만 nested 필드의 개수만큼 내부적으로 별도의 도큐먼트로 분리되어 저장이 되고 쿼리 시 상위 도큐먼트와 합쳐져서 보여줘야하는 등에 여러 이유로 nested 필드는 많이 느리다. Elasticsearch nested type설명에도 flattened type을 고려해보라고 써있는거 보면 얼마나 좋지 못한지 사용해보지 않아도 가늠해 볼 수 있다. (실사용에서도 퍼포먼스를 극대화 해도 쉽지 않았다.) 그래서 성능이슈를 해결해보고자 찾던 중 7.3 버전..

    Elasticsearch의 Translog 설명

    Lucene을 공부하면서 실제 세그먼트를 조작 하고 인덱싱을 반영 하는 부분을 보면서 Lucene에 commit에 대해서 공부했었다. wedul.site/678 Lucene의 commit과 flush의 차이 Lucene에서 데이터 색인을 위해서 사용하는 IndexWriter의 flush와 commit 두 가지 command의 차이를 정리해보자. 두 개의 operation 이름만 보게되면 동일한 동작을 수행할 것 같지만 실질적으로 다른 동작을 wedul.site 그럼 실제로 Elasticsearch에서 이 Lucene commit에 영향을 받는 부분이 어디인지 알아보게 되면서 translog에 대해 공부해봤다. 우선 translog는 양 자체가 워낙 방대하기 때문에 성능을 위해서는 이 부분에 대한 튜닝이 ..

    Elasticsearch 7.7 feature와 heap 메모리 사용량의 두드러진 감소량

    줄어든 heap 사용량Elasticsearch 사용자들은 Elasticsearch 노드에 저장이 가능한 만큼 데이터를 집어 넣지만, 가끔 disk에 저장되기 전에 heap memory 사용량이 초과되는 것을 경험한다. 이는 비용을 줄이기 위해 가능한 노드당 많은 양의 데이터를 넣고 싶은 사용자들에게 문제를 일으킨다. (실제로 현재 운영중인 es에서도 대량의 데이터 삽입 시 가끔 발생함) 왜 Elasticsearch에는 데이터를 저장하기 위해 heap memory 영역이 필요한걸까? 왜 디스크 공간만으로 충분하지 않은걸까?? 거기에는 여러 이유가 존재하지만 가장 중요한 이유는 루씬은 디스크 상에 데이터를 찾을 수 있는 위치를 찾아내기 위해서 일부 정보를 메모리에 저장해야 한다. 예를 들어 루씬의 inver..

    Elasticsearch version conflict 에러

    배치를 이용해서 Elasticsearch에 데이터를 삽입하던 중 version conflict라는 오류가 자주 발생했다. 처음에는 Elasticsearch 버전이 동일한데 왜? 오류가 나는지 몰랐다. 그래서 검색해보니 인덱스안에 document에는 각자 관리하는 version이 존재한다. 이 version은 document가 수정될 때 하나씩 올라가게 되는데 version이 10인 상태에 document에 여러 서버 모듈에서 해당 document에 업데이트를 하려고 하니 문제가 발생하였다. 그 이유는 version 10인 상태에서 작업에 들어간 두 모듈은 한 모듈이 먼저 11로 업데이트를 시키고 다음 모듈이 작업을 진행하려고 할 때 자기가 알고 있던 마지막 version인 10이 아니라 11로 바껴있는것..

    Elasticsearch reindex시 alias를 사용하여 무중단으로 진행하기 & big index 리인덱싱 시 비동기 처리 방법

    Elasticsearch reindex를 진행할 때, 단순하게 새로운 인덱스를 만들고 reindex api를 진행하고 기존 인덱스를 지우고 새로 만들어서 다시 reindex를 해줬다. (이전글: https://wedul.site/611?category=680504) 하지만 그것은 해당 인덱스의 document의 수가 적어서 금방 진행이 되었었고 만약 document수가 10만가지만 넘어도 생각보다 오래걸려서 서비스의 흐름이 끊어지게 된다는걸 인지하지 못했다. 같은 회사 동료분께서 해당 부분에 대해서 말씀해주셨고, 그 분이 가이드 해주신대로 진행해서 reindex를 무중단하게 진행하는 방법을 찾아봤다. Alias를 이용하여 reindex하기 기존 index wedul의 매핑구조이다. PUT wedul { ..

    Elasticsearch nori 형태소 분석기에서 readingform filter를 이용해서 한자 내용을 한글로 변환하기

    Elasticsearch filter에서 한자로 검색했을 때 일치하는 한글 결과로 tokenizing하게 해주는 filter가 있다. 해당 filter는 nori-readingform이다. 적용 방법은 기존에 synonmys나 speech필터 적용과 동일하다. 인덱스 생성 위에서 부터 사용했던 인덱스에 nori_readingform 필터를 추가해서 생성만 해주면 된다. PUT wedul_anaylyzer { "settings": { "index" : { "analysis" : { "tokenizer": { "nori_user_dict": { "type": "nori_tokenizer", "decompound_mode": "none", "user_dictionary": "dic/nori_userdict_k..

    Elasticsearch 특정 형태소 종류를 제외하여 검색하는 필터 nori_part_of_speech 적용

    Elasticsearch를 사용하여 analyze를 사용하다가 조사, 형용사 등등을 제외하고 형태소 토크나이즈가 되어야 했다. 그래서 정식 문서를 찾아보더니 nori_part_of_speech라는 필터가 있었다. 우선 저번 시간에 만들었던 wedul_analyzer 인덱스를 이용해서 토크나이즈를 해보자. { "tokens": [ { "token": "바보", "start_offset": 0, "end_offset": 2, "type": "word", "position": 0 }, { "token": "위들", "start_offset": 3, "end_offset": 5, "type": "word", "position": 1 }, { "token": "이", "start_offset": 5, "end_o..

    Elasticsearch에서 Dictionary 변경 시 analyzer와 인덱싱된 Document 갱신 방법

    Elasticsearch에서 Dictionary를 사용하여 analyzer를 만들고 그를 사용해서 index에 Document를 인덱싱할 수 있다. 근데 Dictionary가 변경되면 analyzer를 변경하고 indexing된 document를 갱신하려면 어떻게 해야하는지 정리해보자. Background 지식 Analyzer는 character filter, tokenizer, token filter 순서대로 적용한다. 기본적으로 anaylyzer는 indexing time과 search time에 적용된다. index time 분석 대상은 source data(원본 데이터)이고 search time 분석 대상은 query string이다. 그러므로 사전을 변경하는 것은 indexing, serchin..

반응형