Elaticsearch 시작

시작하자 ! ...... 그전에 먼저...

 

 일단 가볍게 도커로 Elaticsearch 를 설치 하였다. 도커의 위대함(?) 을 느낀건 생각보다 아주 손쉽게 사용이 가능했다 이미지를 받아서 사용하면 끝!! ( docker composer 를 사용하였기때문에 설정도 쉬월했다. )  

서비스가 제대로 실행되고 Elaticsearch API 가 잘 동작하는것도 확인했다.  이제 사용에 앞서서 개인적으로 먼저 확인 해야할거 같다고 생각이 든건 딱 세가지였다. 

1. document 구성은 어떻게 짜야 하는것인가 ? 

2. 내가 너무 RDBMS 스럽게 생각하여 Elaticsearch 스럽지 못하게 오해하고있는 개념은 없는가?

3. 시행착오를 겪는 부분은 대체로 어디인가 ?

바로 구글링을 시작했고 역시나 우려했던 부분 몇가지가 보였다. 

 

- 바람직한 인덱스 디자인

  1. 쿼리에 filter가 들어가고 그랎이 Enumerable 할때는 인덱스를 나눠서 설계 하라 

     - 데이터중 지역별로 나눠서 데이터를 검색할경우 , 지역별로 인덱스를 구분하면 효율이 더 좋다고 한다. 

  2. 값이 enumerable 하지 않다면 routing key 를 사용하라.

     - 주문 데이터가 구매자별로 저장될 경우 , 인덱스를 구분하면 과도한 인덱스가 구분되어야 한다. 이때 filter 로 사용되는 필드를 routing key 로 사용하여 인덱스를 여러 shard 로 쪼갤수 있고 , 이럴경우 동일한 구매 아이디를 가지고있는 테이더를 동일한 shard 에 모여서 저장하면 구매아이디 = routing key 를 가지고 한번에 조회가 가능하여 더 효율 적이다. 

  3. 기간이 정해져 있는 데이터들의 경우 인덱스를 구성하여 사용하라. 

     - 로깅을 할경우 일,주,월 별 데이터를 모을수 있는데 날짜별로 데이터를 모으면 더 빠르게 접근이가능하다. 

  4.  mapping 을 효율적으로 지정하라 . 

     - 인덱스에서 필드별로 mapping 을 지정해줘야 해당 필드에서 검색이 가능하다. 기본적으로 데이터가 인덱스에 들어가면 기본적으로 매핑은 해주지만 효율적이지 않다고 한다. 효율적이기 위해선 인덱스 재설계가 필요하고 자동매핑을 사용하지 않는게 좋다고 한다. 주의 사항은 문자열 경우 text, keyword 모두 적용하는경우가 있는데 이경우는 안좋은 예라고 한다. 

  5. 사용자 정의 id 를 사용할경우 불균형 샤딩에 대해 조심하라 .

     - 보통 자동으로 아이디를 생성하는데 이 아이디를 이용해서 적절하게 샤딩을 수행한다고 한다. 만일 임의 지정 아이디를 사용하거나 임의 routing key 를 랜덤하지 않게 부여를 하면 특정 shard 에 데이터가 많이 지는 무제가 발생하고 그로 인해 느려지게 되기 때문에 주의 해야 한다. 

  6. 여러노드에 고르게 샤드를 만들어라 

    - 아마 5번의 이야기의 연장선인거 같다. coordinator 노드가  존재하는데 이노드가 분배 역할을 하고 마스터 노드들은 데이터 적재를 담당하는데 coordinator 가 잘 분배 하도록 해줘야 한다는 이야기 같다. 

  7. bulk request 를 높이고 refresh 기간을 올려라 .

     - 이벤트가 발생할때마다 새로운 lucene segment 를 만들고 이것을 합치는 작업을 진행 한다고 하다. 보통 refresh 가 발생할경우 이작업을 진행한다고 하는데 이런 문제를 줄이기 위해서 interval 를 길게 잡아놓는게 좋다고 한다. 하지만 너무 길경우에는 변경된 데이터가 검색이 안된다고 한다. 이유는 index 자체가 refresh 가 종료 되는순간 변경, 추가 된다고 한다.  적절한 interval 설정을 해줘야 할거 같다. 

  8. replica 수를 줄여라 

     - 주요 노드에 기록되고 모든 replica shard 들에 인덱싱 요청이 발생하는데 replica shard 수가 많을 수록 인덱싱 속도가 느려진다고한다. 개인적으로 확인한 구성중에는 보통 replica 를 하나만 두는곳이 많았는데 이런이유가 아닌가 싶다. 

9. 가능하면 자동으로 생성되는 ID 사용하라 .

   - 이 내용은 shard 몇개에 데이터가 몰리는걸 방지 하기 위한 이야기 같다. 단지, 랜덤한 자동생성 값을 사용할때 uuid-1 , nono time 을 사용하는게 좋다고 한다. 

 

10. 가능하면 query context 에 filter 를 사용해라 . 

 쿼리에 대해서 아직 조사가 덜되서 이해를 완전히 하지 못했지만 쿼리에서 찾고자하는 값과 일치하는것 찾을때 대부분은 yes or no 로 찾을수 있다고 한다.  match 등을 통해서 찾으면 scoring 이 들어가기때문에 성능적으로 어느정도 포기하는 부분이생기게 된다. filter 를 사용하면 결과가 캐시도 되기 때문에 좀더 이점이 있다. 

 

11. shard 노드를 효율적으로 관리하라 

개인적으로 많이 찾아봤던 내용이다. 인덱스에 어느정도의 shard 를 설정하는것이 좋은가 ? 그러나 개인적인 예상과 별반 다르지 않게 상황에 따라 다르다가 일반적은 답변이 였다. 너무 작으면 scale out 이 되지 않고 너무 많으면 성능적으로 문제가 생긴다. 조사를 해보니 모든 쿼리를 shard 에 실행시키기 때문에 request 안에 routing key 를 넣어서 요청을 보내도 별반 영향이 없다고 한다. 그래도 나름 기준으로 나온게 index 가 1gB 보다 작으면 shard 는 1개가 적당하다고 한다. 그리고 shard 를 5개를 기본 운영하는게 좋다고 하는데 역시 아무리봐도 상황에 맞게 가는게 맞는거 같다. 

index 의 chard 수를 조정하려면 reindex 를 해야하기때문에 Risk 가 큰 작업을 하지 않기 위해선 초반에 설정이 중요할거 같다. 

 

12. stop word 를 사용한 검색을 자제하라 . 

 stop word 는 a, the 와 같이 검색 결과를 증가 시키는 단어라고 한다. 만약 fox 라고 검색해서 10건이 나온다고하면 the fox 라고하면 the 와 가까운 데이터가 출력되면서 대부분의 document가 출력 된다고 한다. 기본적으로 모든 결과를 score 별로 정렬하기 때문에 the fox 와 같은 것들은 시스템을 느리게 만든다. 좋은 방법은 미리 token filter 를 만들어서 stop word 를 제거하고 검색하는게 가장 좋다고 한다. 

 

위에 내용은 구글링을 하다가 어느분이 ebay 에서 올린 글을 보고 정리 한 내용이라고한다. 아직 ebay 글까진 못봤는데 시간날때 한번 정주행 해봐야 할거 같다.

 참고 사이트 : https://tech.ebayinc.com/engineering/elasticsearch-performance-tuning-practice-at-ebay/  https://wedul.site/613 

Elasticsearch Performance Tuning Practice at eBay

- index, type 에 대한 오해 

 index 는 데이터베이스 , type 은 테이블로 이해하고있었다. 그러다보니 type 이 여러개 생긴다는게 당연하다고 생각했다. 하지만 찾아보니 2개이상 type 을 생성하면 에러가 난다는 사실을 알았고 실제로 6.x 버전부터 멀티 type 은 사용 하지 못하게 되었다고 한다. 현재 7.x 버전으로 진행하려하는데 아마 동일 현상이 일어 날것으로 보인다. 단순하게 테이블과 동일하다고 생각했던게 아주 큰 오산이였다.

- API 로 모든것이 다 가능하다. 

  API 로 모든 기능을 제공한다고 보통 작성해놓은곳이 많다. 그래서 별다른 신경을 쓰지 않았지만 내용을 좀 살펴보니 유사시에는 queryDSL 을 사용해야할 이유도 있을거 같았다. 생각보다 복잡한 요구사항이 생길경우 queryDSL 를 사용해야 할것으로보이고 개인적으로 queryDSL 을 공부한적이 없기 때문에 에상치못한 일정 차질이 생길수도 있을것을 감수 해야할거 같다.

- 인프라구성은 가볍게 ? 

 인프라구성부분도 많은 생각이 필요해 보였다. 단순하게 클러스터만 구성하고 리플리카와 몇대의 클러스터 노드만 있으면 괜찮지 않을가라고 생각햇는데 Elaticsearch 을 사용하는 많은 사람들이 인프라구성에 대해서 고심을 많이 한 흔적들이 보였다. 그렇다보니 아직은 기술성숙도가 그렇게 놓지 않은 도커를 이용하는것이 추후 운영시 스스로 대응하기 빠른지에 대한 의문이 생겼다. 그리고 Elaticsearch 설치도 따로 진행해 보았는데 생각보다 어렵지 않았다. 도커가 과도하게 쉽게되서 그렇지 비교하지 않고 보면 절대 난이도가 높지 않았다. 이부분은 팀원들가 토론을 좀 해봐야 할거 같다. 

 일반적은 인프라 구성은 L4 하나에 마스터+데이터노드 구성을 여러개 물려서 사용하는 경우가 많다고 한다. 

- 튜닝 ?

 Elaticsearch 경우 최초 설치시 디폴트로 사용은 가능하지만 실서비스에서는 어느정도 성능 튜닝이 필요하다고한다.

아직 제대로 확인 은 못했지만 샤딩을 사용할경우 검색시 모든 샤드들에게 질의를 던지고 조합하기때문에 성능이 느려질수 있다고 한다. 하지만 라우팅을 사용하면 굉장히 많은 시간을 줄일수 있다고 한다. 그래서 라우팅에 대한 부분도 확인이 필요해 보인다. 

 Elaticsearch  실행시에도 자원할당이 어느정도 필요 하다. Elaticsearch 커뮤니티에서 권한하는 설정은  Elaticsearch 메모리를 서버의 절반정도로 할당하는걸 권장하고 있다. 실제로 Elaticsearch  운영시 Out of memory error 가 많이 발생할수 있다고 이야기 하고 있다. 그렇기 때문에 메모리는 서버의 절반정도 할당한뒤 index,cache.field.type 설정값을 soft 로 바꾸어 주면 GC 를 먼저 실행하여 메모리를 확보하고 사용하기 때문에 어느정도 문제발생확률을 낮출수 있다고 한다. 

 데이터가 많아질 경우에 인덱스 파일갯수도 문제가 생길수 있는데  현재 구현하려는 시스템에서는 그렇게 많지 않을거같아서 고려하지 않고 있었다. MAX_OPEN 값을 unlimit 으로 바꾸는것으로 해결이 가능하다고 한다. 추후 문제가 생기면 참고해봄직 하다. 

 개인적으로 신기했던건데 인덱스 최적화 기능이 존재한다. API 로 _optimize 를 호출하면 된다고하는데 실행시 시스템에 부담이 많이 가는거 같다.  트래픽이 적은 시간대에 수행하는걸 권장한다고 나와있었다. 

 

성격이 참이상해서 시작하기전에 이것저것 알아보고 시작하는게 버릇이다. 덕분에 뭐하나 시작하려면 준비가 길다. 미리준비해도 하다보면 까먹고 할걸알면서 아직 이버릇을 못버리고 있다. 

 일단, 이정도 알아보고 다음엔 직접 데이터를 넣고 빼고 를 해봐야 할거 같다. 회사에서 저장할 데이터들이 아직 확실하게 구상이 나온게 아니라서 그게 좀 맘에 걸리는 상황이지만 일단 , 최대한 익숙하게 해놓은 상태에서 시작해보려고 한다. 확실한건 Elasticsearch 는 볼수록 매력이라는것이다.