'규모산정'에 해당되는 글 1건

  1. 2018.04.05 [Elasticsearch] 쉽게 Elasticsearch Estimation 하기

[Elasticsearch] 쉽게 Elasticsearch Estimation 하기

Elastic/Elasticsearch 2018. 4. 5. 15:44

Elasticsearch 를 이용해서 클러스터를 구성 하거나 인덱스를 구성 할 때 아는게 하나도 없는 상황에서 규모에 대한 평가를 하기 위한 기본 정보로 사용하시면 좋을 것 같아 공유 합니다.


기본 전제는 사용하는 환경에 맞게 테스트 및 최적화를 하셔야 합니다.


  • 1 shard around 20GB (max 50GB)


일반적인 서비스용 데이터에 대한 Shard 크기는 최대 20GB 를 넘지 않도록 설계 하시는게 좋으며, 로그 데이터의 경우 50GB 를 넘지 않도록 설계 하시면 됩니다.

이를 기준으로 사용 환경에 맞춰 성능 테스트를 하시고 크기를 최적화 하시면 됩니다.


  • Machine Spec
    • Master ( 1/2 of search ) < Search ( 1/2 of data ) <= Data
    • Minimum Master Node Spec ( m4.large )
      • CPU 2 cores
      • MEM 8GB


장비는 스펙이 좋으면 좋을 수록 좋습니다. 이건 다다익선이죠. 하지만 비용 문제가 있기 때문에 적절한 스펙 선정을 해야 합니다.

장비 하나에 인스턴스 하나를 띄운다고 가정 하고 일반적인 검색엔진 추천 스펙으로 정의 하면) 

장비 스펙이지 노드 스펙이 아닙니다.


  • CPU : 32 cores
  • MEM : 64GB


위 장비 스펙을 Data 노드라고 가정하면,
    • Search(Client) 노드의 장비 스펙은)
      • 32 cores X 32GB
      • 16 cores X 32GB


    • Master 노드의 장비 스펙은)
      • 8 cores X 16GB
      • 4 cores X 16GB


  • Primary Shards
    • CPU core size eq primary shards ( 1/2 of CPU cores )


위에 정리한 내용들의 출발은 알고 있는 정보가 전혀 없다는 가정에서 시작한 것입니다.

처음 시작 하시는 분들에게는 어디서 부터 어떻게 해야 할지 모르기 때문에 시작 할 수 있는 정보가 있다면 조금은 시간낭비나 고민을 덜어 드릴수 있지 않을까 싶어서 공유 합니다.


인덱스와 샤드에 대한 생성과 배치 전략에 대해서도 공유를 드리도록 하겠습니다.

그 전에 아주 옛날에 작성한 글 하나가 있어서 링크 투척하고

[Elasticsearch] replica & shard 이해하기.


약간의 부연 설명만 하고 마무리 하겠습니다.


1. Primary shard

원본 데이터 입니다.

한번 정의 하면 변경 할 수 없으며, 현재는 shrink, split, reindex 등의 API 를 이용해서 뭔가의 조작은 가능 합니다. (이것도 나중에 관련 API 설명을 해야 겠군요..)



2. Replica shard

복제 데이터 입니다.

동적으로 변경이 가능 하며, 장애 방지 및 검색 질의에 대한 throughput 향상에 활용 합니다.

(참고로 Replica shard 는 Primary shard 로 승격이 가능 합니다. - 참고문서)

: