회사 업무 중 고객측에서 역색인만 저장 하고 원본은 저장 안했으면 한다는 이야기를 들었다. 

예전에 루신 라이브러리 테스트할때 검색에는 걸리는데 원본은 없이 연관 Document만 띄우는 기능을 테스트 해본적이 있는데 그때는 그런가보다 하고 신경안썻었다 (주 사용용도가 로그 분석이다 보니 굳이 끌일이 없기에)

그러다 보니 약간 제대로 못알아들은 것도 있고 엘라스틱에서 적용 여부와 어떻게 동작이 변경 될지 몰라 다시 논의 하기로 하고 끝냈다.

루신 기반이니 어찌보면 당연한데 끄는 기능이 있다. _source 에서 지정필드만 오프 하는것(고객이 다르게 설명해서 _source off 인지 인덱싱 false인지 해깔렷다 -_-....)

루신으로 생각해보면 store 영역만 저장하는 (역색인 검색키만 저장) 기능이다.

여하간 이렇게 하면 장점은 메모리 부하나 스토리지 절감(원본을 저장 안하니 당연한) 되게 된다.

다만 그동안 굳이 끌일이 없었던 터라... 단점을 찾아보고 테스트 해본결과 무시무시한 단점이 존재 한다.

아래와 같은 단점이 있다고 한다. 번역기 돌려보면 사실상 왜 끄냐 식이다. ㅎㅎ....

사용자는 종종 결과를 생각하지 않고 _source 필드를 비활성화했다가 후회하는 경우가 많습니다. source 필드를 사용할 수 없는 경우 여러 기능이 지원되지 않습니다:

일단 심각한건 업데이트와 리인덱싱이 안된다는 것이다. 리인덱싱이야 사실 원본이 없으니 당연히 안되고 업데이트 역시 안된다고 한다. 

하이라이팅의 경우도 역시 원본이 없으니 당연히 불가능 하고 버전업이나 원본 데이터 기준 집계기능(원본이 없으니뭐...) 사용 불가능 제약이 엄청 나다.

버전업 안되는건 정말 치명적인데 거대한 인덱싱을 요하는 경우 버전업시 정신이 아득해질듯 하다.

Think before disabling the _source field

여하간 중요한건 업데이트 역시 안된다는 것이다. 엘라스틱의 기본 업데이트 구조를 생각해봤을때 당연하긴 하다.

업데이트 절차를 보면 위와 같다. 말이 업데이트지 실제는 삭제 > 인서트 이다. 이러다 보니 _id가 변경이 발생할텐데 원본색인 데이터가 없다보니 반영이 불가능 하여 검색이 되지 않는다. 

다행히 최종 미팅에서    "어떻게 동작이 변경 될지 몰라 다시 논의 하기"  로 하여 대참사는 막았으나 영업이나 상위 기술쪽에서 다된다고 이미 해논거 같다. 음........

간단히 테스트 해본 자료 남겨 둔다.

(정말 간단한 테스트 이므로 복붙이 필요 없을듯 하여 스샷으로 한다.)

1. 맵핑 작업을 통해 _source에 저장 하지 않을 필드를 지정한다. (맵핑 타입은 테스트 목적상 생략했으나 text keyword등 타입은 다양하게 설정 가능 하다)

2. 가라 데이터를 넣는다.

3. 검색을 해본다. _source에서 article_content를 꺼놔서 원본은 보이지 않고 해당 document는 잘나오는걸 볼 수 있다. 

역색인(Inverted Index) 에 대충 아래 표처럼 등록되어 있을 것이다. 

4. 문서하나를 업데이트 하고 검색을 해보자. test 필드 값을 변경 한뒤 검색을 진행해봤더니 

"_id : TBmBhYcB1G_oFdaO64ES"  가 검색결과에서 없어졌다.

5. 물론 단순 전체 검색을 하면 동일한 아이디로 아래와 같이 보이게 된다. 하지만 역색인에서 해당 아이디는 빠지게 된다. 왜냐 위의 그림을 재탕 해보면 루씬에서 업데이트는 없다 삭제 > 생성(재생성) 이다.  삭제가 발생 했으니 역색인에서 빠지게 될 것이고 다시 재생성 할 때는 _source에 원본 텍스트가 없으니 역색인 테이블에 반영이 안되는 것이다.

역색인 테이블 활용 간단히 설명 하자면

1) 업데이트  발생시 삭제 마킹 시전 forcemerge가 발생하지 않으면 해당 상태로 둔다

2) _source 에 없으므로 forcemerge 후 최종적으로 빠지게 될것이다.

업데이트시에는 그냥 역색인 살려둔 상태로 하면 되지 않냐 라고 할 수 있지만... (나도 그랬음 좋겠다)

루씬의 대전제가 깨지기도 하고 해당 방법으로 하면 가득이나 느린 업데이트가 더 느릴수도 있을거같다.

비정상적(업데이트 도중 에러 등등) 상황이 나왔을때 무결성(immtable)에 문제가 발생 할수도 있어서 해당과 같은 상황이 나오는거 같다.

그동안 대에충 알고 있었는데 검증겸 테스트를 통해 명확하게 알아봤다. 언제나 그렇듯 레퍼넌스 링크는 아래에 남겨둔다. 

https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-source-field.html

회사에서 일하다가 용도를 해깔려 하는 사람들이 있길래 내가 만든건 아니고 회사 후배가 주로 작성 했다.

기록용으로 남겨둔다.

예정 데이터 쓰기 관점에서 최적화 갯수에 관한 포스팅을 한적이 있다.

검색의 경우 이전회사의 주요 이슈도 아니였고 서버 상태 등등 적재 대비 정밀하게 테스트하기가 어려워 패스한적이 있다.

https://www.youtube.com/watch?v=xP1QFpxhYi4&t=810s 

예전 부터 알던 영상인데 일본 라인쪽 영상으로 보인다.

이 친구의 테스트 수치를 보면 샤드6개 레플1일때 가장 검색이 빠르게 리스폰이 온다 라고 나온다.

적재와 아주 큰 차이는 아닌듯 하다. 

상세한건 해당 영상을 보는걸 추천한다.

오늘의 포스팅은 별다른건 없고 스냅샷 명령어 기록용 즉 불친절한 포스팅이다.

shared file 방식 스냅샷 이다. 뭐 사실 다른 타입이라고 해서 크게 다르진 않다. 

일단 사전에 NFS나 NAS 마운트 등이 필요 하지만 이런건 패스 하고 스냅샷 하는 명령어 기준으로 작성.

Elasticsearch.yml 에서 mount한 영역으로 repo 설정 한다.

아래와 같이 복수 영역 지정이 가능 하다. 단 모든 노드가 동일영역을 정확하게 바라보고 있어야 된다.

마운트가 정상적으로 안되있을시 repo설정시 에러 발생

아래와 같이 사전에 설정이 필요 하다.

Path:
  repo:
    - /hanu
    - /mount/hanu

path.repo:
            -/hanu
            -/mount/hanu

참고 해야 될점은 최초 언급한거 처럼 하나의 타겟을 바라보게 노드를 셋팅 해야 한다.

PUT _snapshot/hanurepo
{
  "type": "fs",        #스냅샷 타입 지정의미 fs(shared file), s3, hdfs 등등 존재
  "settings": {
    "location": "/hanu"
  }
}

일단 위와 같이 repo 저장소 지정 커맨드가 필요 하다.

PUT /_snapshot/hanurepo”리포네임”/hanuking”스냅샷이름”?wait_for_completion=false
{
  "indices": "index_1,index_2", # 백업할 인덱스 *아스테리크 형태로 인덱스 지정 가능
  ＂ignore_unavailable＂: true,     #그대로 진행
  ＂include_global_state＂: false, #그대로 진행
  ＂metadata＂: {
    ＂taken_by＂: “hanu", #아무말 사용
    "taken_because": “hanu sa ju sae yo“#아무말 사용
  }
}

리포 생성이 정상적으로 되면 해당 명령어를 통해 스냅샷을 생성 한다. 인덱스용량이 미미 하다면 기다려도 되나 굳이 그럴필요 없으니 wait_for_completion=false 으로  셋팅 한다.

GET /_snapshot/hanurepo/hanuking 결과확인 명령
DELETE /_snapshot/hanurepo/hanuking  스냅샷삭제

생성 후 확인은 위와 같이 하면된다.

공홈에 있는 내용 이지만 첨부해본다. 버전별 스냅샷 호환표

마지막은 언제나 레퍼넌스 doc 링크로 마무리 

약간은 불친절한 포스팅이지만 실제 설명도 다있고 하니 이만

https://www.elastic.co/guide/en/elasticsearch/reference/7.5/snapshots-register-repository.html

회사 업무 도중 모싸이트에서 리인덱싱시 중간에 Task가 죽어서 리인덱싱이 제대로 되지 않는 다는 말을 들었다. 

서킷브레이크나 기타 고부하떄문에 죽나 했는데 데이터 사이즈나 이전회사 서버 상태 등등을 감안했을때 그럴거 같지 않

(인덱스 용량이 대략 30기가 정도 였는데 이전회사에서 훨씬큰 인덱스 리인덱싱 몇번 했는데 문제가 있었던 적은 없었다)

은 느낌이 들어서 주말에 심심해서 한번 내용을 찾아보았다.

역시 따로 이유가 있었다 

자세한 내용은 아래 링크에 있는데 모종의 사유로 특정 doc가 리인덱싱에 실패하면 발생 한다고 한다.

중단 사유중이 물론 부하가 심할시 그럴수도 있다고는 하지만 리인덱싱이 불가능한 doc에서 주로 생기는거 같다.

https://www.elastic.co/kr/blog/3-best-practices-for-using-and-troubleshooting-the-reindex-api

에러가 생기는 문서를 만나도 중단하지 않고 넘기고 계속 진행하는 옵션이다. 기타 자세한건 위의 링크에 너무 상세하게 남아있어 자세하게 남길 필요는 없어 보인다. (저 링크 찾기가 힘들어서 기록용으로 포스팅)

상세한 내용은 링크를 참조 하시라.

POST _reindex
{
  "conflicts": "proceed",
  "source": {
    "index": "<source-index-name>"
  },
  "dest": {
    "index": "<dest-index-name>"
  }
}

#1에서 search를 알아봣다면 이번엔 write 이다.

search야 조회이기 때문에 동일 alias로만 묶어주면 편리하게 검색 사용이 가능 하다.

하지만 쓰기라면 어디 인덱스로 쓰라는 것인지 모호성이 발생하게 된다.

이럴떄를 위해서 추가적으로 해주는 flag 값이 있다.

"is_write_index" 라는 값으로서 아래와 같이 사용이 가능 하다.

hanualias로 묶인 인덱스 중 hanudata라는 인덱스에 적재 하라고 명시 해주는 flag값이다 alias묶인 인덱스 중 한개의 인덱스에만 true 가능 하다. (중복 인덱스 true 불가능)

해제시에는 false로 해주면 된다.

POST /_aliases
{
    "actions" : [
        {
            "add" : {
                "index" : "hanudata",
                "alias" : "hanualias",
                "is_write_index" : true
            }
        }
    ]
}

상세한 설명은 search #1에서 했으므로 생략 하기로 한다. 원리상 동일 하므로 명령어만 잘 이해하면 되고 최신 버전의 경우 data streams 이란 이름으로 해당 기능을 자동화 해서 사용이 가능 하다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html

아 물론 oss 버전 등 사용시 위의 개념으로 플러그인을 만들든 매니지먼트 앱을 만들든 하여 사용하여야 한다.

alias 설정 관련 연재 1호

Elastic 사용시 본용도인 검색용으로도 많이 사용 하지만 Log적재/분석 용도로도 많이 사용 하게 된다.

특히 보안용도 SIEM이나 AI 예측 데이터 저장시 사실상 동일 구조의 데이터를 정말 미친듯이 저장 하게 된다. 

뭐 샤드를 30~40개 설정해서 (단일 인덱스 저렇게되나? 사실 저런짓까진 안해봤다) 한개의 인덱스에 때려 넣을 수도 있으나 일데이터 사이즈가 얼마일지도 모르고 엄청난 양의 샤드롤 설정한다고 한들 한계치를 벗어나게되면 결국 새인덱스를 생성 해야 된다. 

주 용도가 검색/분석인 엘라스틱인데 저렇게 인덱스가 나눠졌을때  여러 인덱스에 대해 한번의 질의로 검색을 해야될 일이 많다. 아니 사실 개인적으론 그게 주 용도 였다. (이전 회사에서 동일 용도 데이터를 300일치 일 데이터 300기가 이상 저장해서 사용 했다) 

그럴때 사용하라고 있는게 오늘 소개할 alias 설정 이다.

그림을 만들다가 문득 공식홈에 보니 딱 좋은 그림이 있어서 아래 그림으로 대체 한다.

아래 처럼 여러 인덱스를 묶어 검색하는 일이 다반사이다.

아래 명령어를 사용 하여 묶어주면 된다. 인덱스명과 알리아스명을 동일하게 맞출 필요는 없다. 다만 비슷하게 해야 기억하기가 쉽겠지? 

이전회사의 경우 날짜별로 인덱스를 생성 했었다 그래서 hanu-20221214 요러한 형태가 되었는데 

alias의 경우 hanu로 하여 GET hanu/_search 형태로 검색질의를 하였다.

아래와 같이 묶어주면 GET hanu/_search 묶여있는 모든 인덱스가 검색이 가능 하다.

POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "hanuking01",
        "alias": "hanu"
      }
    }
  ]
}

기존에 미사용 중이라 대량으로 한번에 묶을 경우  * 활용하여 다중 인덱스에 한번에 부여 가능 하다. 크게 부하가 가는 작업이 아니므로 인덱스가 미친듯이 많은 경우가 아니라면 해당과 같이 진행 하면 된다.

POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "hanuking*",
        "alias": "hanu"
      }
    }
  ]
}

위의 개념을 응용 하면 특히 hot-warm-cold 아키텍쳐를 사용 하는 경우

위와 같이 한개의 alias로 묶어주면 관리적으로는 매우 편하지만 묶여있는 모든 인덱스에 검색 질의가 발생하여 의도치 않게 매검색시마다 시스템에 엄청난 부하를 주게 된다. 최악의 경우 out of memory 서킷을 건너뛰고 발생 할 수 있다. 

(개인적으로 서킷이 무조건 먼저다라고 생각하고 운영 했었는데 충격적인 경험 이였다)

한개의 인덱스에 멀티 alias설정이 가능 하다 즉 위의 hanu이외 hanuhot hanuwarm 등 추가 지정이 가능 하다.

이개념을 사용 하여 hanuhot을 지정할 경우 보통 대부분의 검색 질의에도 기간이 포함되는데 hot존 영역이내의 range의 경우 GET hanuhot/_search 형태로 이뤄지게 지정하여 불필요 하게 warm이나 cold에 부하가 가지 않게 조절이 가능 하다. 

당연한 이야기 이지만 검색범위가 좁아져 질의 응답도 빨라지게 된다.

POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "hanuking*",
        "alias": "hanuhot"
      }
    }
  ]
}

콜드는 귀찮아서 제외 하고 그림과 함께 설명 

위의 alias설정 대로 hanu로 조회시 모든 노드의 인덱스에 대해 조회가 된다. 물론 전체 데이터 조회가 필요한 경우라면 상관없지만 특정 영역 특히 날짜 최근날짜면 조회한다고 한다면 warm 데이터는 상대적으로 오래된 데이터 이다. 불필요한 조회가 발생하여 시스템 자원을 사용 하게 된다.

alias를 hot전용을 지정하게 되면 아래와 같이 hot존 데이터만 조회 하게 된다. 시스템 자원 사용도 덜 사용 하고 위의 언급 처럼 질의 응답 역시 빨라 지게 되는 장점이 있다.

위와 같이 alias를 좀더 스마트 하게 사용 하면 부하를 좀더 세심하게 조절 할 수 있다. 단점은 각각 인덱스 hot-warm-cold 지정시 세밀하게 alias 설정 변경이 필요 하고 역시 검색 질의시 날짜 레인지등을 판단 하여 검색질의가 들어 갈 수 있게 개발이 필요하다.

엘라스틱에서 기본 제공하는 ILM (Index Life Cycle Management) 가 저렇게 자동으로 해주는지는 모르겠다. 

어디까지나 OSS 또는 기본제공 ILM 사용이 아닌 자체 관리의 경우에 해당 하는 내용 이다.

아 빼먹을뻔 했는데 alias 삭제의 경우는 아래 명령어와 같다. 삭제 역시 * 사용이 가능 

POST _aliases
{
  "actions": [
    {
      "remove": {
        "index": "logs-nginx.access-prod",
        "alias": "logs"
      }
    }
  ]

https://opensearch.org/

엘라스틱을 사용사는 엔지니어들이라면 대부분 이미 아는 사실이다. 작년 아마존과 엘라스틱의 분쟁 결과 엘라스틱 7.11 이후 버전 부터 SSPL 이라는 라이선스를 도입 MSP (Managed Service Provider) 즉 클라우드 사업자 사실 아마존 타깃이지 무료 사용을 금지 시켯다. 

이후 반발한 아마존의 경우 7.11버전 부터 Fork 하여 예전에 Open distro for Elasticsearch의 이름을 바꿔 OpenSearch로 개명하여 해당 서비스를 제공 중이다. 

 장점은 역시 apache2.0  라이선스 이다. 즉 사실상 무료 서비스 이다.  SSPL의 경우 자체 서비스를 제공 하는 회사의 경우나 이미 유료 라이선스를 사용 중인 회사의 경우 영향이 없으나 솔루션 제공(고객사 솔루션 판매/설치등), 클라우드 사업자의 경우 기존과 같이 사용이 불가능 하다. 예전 회사에서 해당 문제(솔루션 판매 회사였다.) 관련 하여 괭장히 골치 아팠던 기억이 있는데 일단 구버전 OSS 로 진행 하는 것으로 결론이 났다. 

 이미 퇴사 해서 어떻게 보면 상관은 없지만 구버전을 사용하는 것이므로 차후에 다시 무언가 선택이 필요 하다. 개인적론 당시에 오픈써치가 정식 첫버전을 출시한 상태라 위험성은 있지만 Open distro for Elasticsearch 버전 선택 후 차후 업그레이드시 오픈써치 쪽이 맞지 않을까 싶었다. (엘라스틱 유료 라이선스를 전혀 살 생각이 수뇌부 입장에서 없었기 때문에 저거 말고 선택지가 있나 싶었는데 윗선에선 돈은 쓰지 않고 싶고 엘라스틱사의 버전을 고수 하고 싶어 했다.) 

뭐튼 잡썰이 길어졌는데 최근 오픈써치가 생각보다 엘라스틱 메인버전 개발 속도를 생각보다 잘 따라가고 있다고 하고 국내에선 느낌상 오픈써치쪽을 더 선호하게 될거같은 느낌이 든다. (일단 기본적으로 무료이고 aws 사용하는 업체도 많고 보통 유료 기술 지원 보단 자체 엔지니어를 갈아넣어 해결하는 국내 IT 특성상....)  거기다 클라우드 전문회사인 M모, B모 업체에서 굳이 추가 비용 지출이 필요한 엘라스틱사 버전을 선호할리도 없고 자기들 자체 기술 지원 형태로 컨설팅을 위해서라도 이쪽을 더 밀지 않을까 싶다.

아직 구글 검색해보면 국내엔 자료가 거이 없어 보인다. 영어를 잘못하는 나에겐 치명적이다....  공식 홈피를 찾아 들어가 대충 둘러본 결과 보통 엘라스틱 자체 사용에 필요한 대부분이 잘구현되있는듯 싶다. 물론 distro시절에도 그랬지만 말이다.  

흥미로운건 엘라스틱쪽에선 플레티넘(지금도 동일하겠지) 라이선스 이상에서만 지원하는 jdbc 클라이언트를 무료 제공하고 비동기 검색역시 무료 지원 한다. 버전 업그레이드 속도 역시 생각 보다 빠르게 대응 중이고 개인적으로 놀라웠던건 8버전때 와서 신규 지원하기 시작한  java client (high level 과 다르다) 또 한 비슷 하게 지원 중이다. ML 기능도 지원 하고 있고 기타 엘라스틱사의 엘라스틱 이외의 각종 제품 연동을 제외 하고 검색엔진 자체는 라이선스를 제약을 받지 않으니 유료 버전을 사용 하지 않는 회사의 엔지니어 입장에서는 오히려 사용하기 편한점도 있어 보인다. ( 유료 버전을 사용 하다 무료 버전 특히 oss 버전으로 내려오니 생각보다 큰 제약에 사용 하면서 불편함이 이만 저만 아니였다.)

그래서 업그레이드는 어떻게 하나 보니 업그레이드 절차도 지원하고 있다.

https://opensearch.org/docs/latest/upgrade-to/upgrade-to/

딱히 공개할일은 없지만 번외로 basic -> oss 전환은 정말 지옥과 같았다. 이것의 경우 그 어디에도 자료가 없어서 진짜 수많은 테스트, 데이터 백업, 성공의 불확실성 정말 무서웠다. 어쩌다 보니 총대매고 했는데 다시는 하고 싶지 않다.

당연한 이야기이지만 oss -> basic 은 메뉴얼이 제공되지만 반대의 경우 메뉴얼이 없다.

여하간 초기엔 아마존이 지원 제대로 안해줘서 엘라스틱사가 일방적으로 이길려나? 싶은 생각도 들었는데 지금 분위기 봐선 국내 한정 OpenSearch쪽이 유리해 보이는 느낌도 든다. 물론 회사마다 최신버전을 항상 업글하지는 않으니 어디가 이길지는 좀 더 길게 봐야 할듯 하다.

엘라스틱써치 신간이 나와서 구매해봤다. 보다시피 번역서 이고 가격은 비싸고 두껍다. 엘라스틱 엥간한 국내 발매서는 대부분 가지고 있는데 한참 정신없을때 출시해서 모르고 있다가 이번에 구입해보았다.

신간이라고 하기엔 8월말 출시라 조금 지나긴 했지만 가장 최신에 발간한 책이다. 단점은 아직 대충 봐서 자세히는 모르겠지만 7.0 초반 기준으로 만들어진책 같다. 원서 기준 꽤전에 나온듯 하다. 장점은 es-spark가 책에 나와 있다. 예전에 es-hive, es-spark 등 테스트 개념으로 써보긴 했는데 공식 사이트 보고 혼자서 했던지라 이게 맞나? 라는 생각을 좀 많이 하면서 했었다. 

예전 기억을 떠올리며 es-spark 연동을 다시 한번 해봐야 겠다. 예전 기억으론 특히 es-hive 연결시 인덱싱 속도가 미친듯한 속도가 나와서 뭐지? 싶었는데 연동 하면서 hive도 해봐야 겠다. 구형 노트북에 모든걸 다 켰더니 메모리가 고갈 상황이라 예전 처럼 미친속도가 나올지는 잘모르겠다. (평소 인덱싱 속도 2~30,000 eps 클러스터가 hive로 연결 적재하니 80,000 eps가 나와서 눈을 의심 했었다.)

여하간 두께가 두께인 만큼 내용은 많은듯 하다. 단점은 위에 지적했듯이 기준버전이 다소 옛날 버전이고 지금은 Deprecated in 7.15.0 된 highlevelclient 관련 내용이 있다. 해당내용을 참고해서 볼필요성이 있다. 

물론 책소개에도 상용화 이전버전을 쓰는... 형태의 소개글이 써있긴하다. 

오픈써치나 oss버전 언급등이 많은거 봐선 무료버전을 쓰는 회사에서 적합한 책으로 보인다. 

일단 주목적인 es-spark 부분을 보고 연동 공부를 좀 해봐야겠다.

그리고 제발 서점에서 검색할때 elastic elasticsearch ELK 엘라스틱 일래스틱 엘라스틱써치 일래스틱써치 좀 한방에 나왔으면 한다. 책 찾을 때마다 현기증이 좀 난다. 동의어 등록을 했으면 좋겠지만 뭐 몇권이나 팔린다고 할리가 없겠지... 

암튼 좀 보고 추천할만한 책이면 리뷰 다시 한번 해봐야 겠다. 

아마도 일반적인 이커머스 검색 등등 온리 검색 목적 또는 내부 단순 log분석의 경우 이런것에 크게 관심을 안가지는 것으로 알고 있다. 다만 내가 경험했던 H모, L모, I모 사 등 등 SIEM등 보안데이터 목적으로 사용 하는 경우 적재속도에 많은 관심을 가지고 있다. 예전 컨설팅 경험도 그렇고 적저속도에 대한 문의가 많이 들어 온다.

이전 회사에서도 주요 관심사가 적재속도 였었는데 가장 큰 문제는 돈을 쓰지 않고 해결할려는 것이 가장 어려웠다 쉽게 이야기 해서 서버 추가 구매 없이 속도 향상을 원했다. 사실 쉽지 않은 문제인데 어쨋든 엔지니어 입장에서 추가 구매 요청을 위해선 최대 최적화 후에 요청 하는 것도 하나의 의무라 생각해 최대한 최적화를 진행 하면서 썻던 기법 몇가지를 써볼까 한다. 

뭐 사실 크게 공개할만한건 없어서 그냥 기록의 의미로 대충 적어보자 한다.

일단 원서까지는 모르겠고 국내 서적 2022/6월이전 출시 책들의 경우 적재 속도 최적화 등 등 즉답을 좀 피하는 경향이 있다. 사실 이해는 간다. 쓰고자 하는 데이터 구조, 용량, 서버구조, 엘라스틱 버전(버전별로 약간 속도가 다른 경우가 있다), 용도(적재와 동시에 검색이 필요 유무등)에 따라 변수가 너무 많기 때문이다. 

여하간 몇가지(다는 안되고) 적어 둔다.

indices.memory.index_buffer_size (기본 10%)

신규 인덱싱 데이터를 메모리에 저장하는 버퍼 비율을 말한다(전체 heap 대비 10%)

이 설정은 사실 개인적으로 속도 보단 최적화 셋팅에 가까운데 공식내용도 그렇고 찾아보면 보통 위의 내용으로 써있는데 개인적 경험으로는 이게 어떤 영향을 주는지는 모르겠지만 이 수치가 낮으면 인덱스 새로 생성시 샤드 할당이 안되고 unassinged 미할당 되는 경우가 있다. 해당 문제 때문에 운영시스템에 큰위기가 올뻔했으나 해당 수치를 적당히 올리고 나니 문제가 없어졌다. 다소 신기한 경험이었다.

비동기 적재 or Bulk 사용

어찌보면 당연한 이야기다. 가장쩌는건 역시 비동기 벌크겠지만 이것도 주의 해야되는게 엘라스틱이 한계치를 벗어나면 최악의 경우 out of memory 또는 서킷브레이크가 발생해서 적재기쪽에 에러난 데이터에 대해 적절한 처리를 하지 않았다면 그대로 데이터 유실로 이어 진다. 사전에 엘라스틱 한계치 속도를 테스트 해보고 다소 보수적인 수치로 적재기를 셋팅 하는게 필요 하다. 

적정한 수의 Shard 개수 설정

가장 중요 하다. 샤드 갯수를 무작정 늘린다고 무조건 속도가 늘어나지 않는다. 개인적 테스트에선 샤드 16개(모두 다른 디스크 또는 노드) 까지 테스트 해보았는데 레플리카 제외 6개가 가장 이상적인 속도를 보여줬다. 아마도 검색 속도도 일정이상이 되면 빨라지지 않을거 같긴 한데 적재 이슈가 핵심이었던지라 검색까지 다양한 테스트는 해보지 않았다.  

SSD, HDD 등 다양한 저장매체 사용시 Hot, Worm, Cold ILM 사용

쉽지만 자주 놓치는 문제 인데 ssd, hdd 동시 사용시 인덱스를 구분없이 무작위 할당할경우 hdd속도에 적재속도가 맞춰져 속도가 느려지게 된다. 검색역시(동일한 검색 질의를 하면 메모리에 올라가 일정 횟수부턴 비슷하겠지만)  가장느린 디스크에 맞춰지기 때문에 느려 지게 된다. 가능 하면 동일한 속도를 가지는 디스크 끼리 묶어서 사용하는게 좋다.

Index.merge.scheduler.max_thread_count

대부분 ssd를 사용해 엘라스틱을 구축하기 때문에 크게 신경쓰지 않는 옵션이다. 물론 all ssd라면 몰라도 상관없으나 디스크를 사용할경우 1로 숫자를 줄여주는게 좋다. 개인적 경험으로는 모사이트에서 적재간 에러가 발생 하여 문의가 왔었는데 (서킷브레이크 다수 발동) 결국 적재 속도를 못따라가는 문제였어서 적재기 속도를 약간 조절 하였고 해당 셋팅을 1로 바꾼 이후 추가 문의가 없었다. 첫 적용 당시에는 반신 반의 하며 적용했으나 이후 다수 사이트에 적용 후 동일 내용 문의 횟수가 현격히 줄어 신기하기도 했다.

Index Mapping, refresh_interval 의 경우 내용도 많고 이전 언급 했던 적이 있으므로 패스