추석 연휴 동안 서버 3대중 한대가 죽어서 2대로 테스트 데이터를 받고있었습니다. 오늘 회사 서버를 살려서 연결 해 보니, 새로 생성된 데이터의 샤드가 제대로 분배가 되지 않는것을 파악했습니다. 그 해결책으로 밑에 구문을 보시면 될거같습니다. 장애 대응으로 한참 샤드 복구와 샤드 할당 작업 등이 수행 중인 바쁜 상황에서 새 인덱스가 생성 될 때를 조심해야 한다. 엘라스틱서치에 새 샤드가 할당될 때 엘라스틱서치는 해당 노드에 총 몇개의 샤드가 있는지 체크한 뒤 적은 수의 샤드를 들고 있는 노드에 새 샤드를 할당한다. 문제는 장애 복구 작업 중 방금 재시작된 노드는 샤드 복구가 제대로 끝난 상태가 아니라는 것이다. 이 노드는 겉으로 보기에는 적은 샤드를 들고 있는 것으로 판정된다. 이때 새 인덱스가 생성되면..

인덱스의 샤드 개수(number_of_shards) 는 한 번 지정하면 reindex 등의 특별한 작업을 수행하지 않는 한 변경할 수 없다. 그런데 샤드 개수를 어떻게 지정하느냐에 따라 엘라스틱서치 클러스터 전체의 성능이 크게 달라진다. 중요한 설정임에도 불구하고 샤드 개수를 정확히 어떤 값으로 지정하면 되는지 딱 정해주는 알기 쉽고 명확한 기준은 알려진 바가 없다. 이 문제는 굉장히 어려운 문제다. 이번 절에서는 샤드 개수를 어떻게 지정할지 그 전략을 알아보도록 하겠습니다. 샤드 크기와 개수 조정 클러스터에 샤드 숫자가 너무 많아지면 클러스터 성능이 눈에 띄게 떨어지게 됩니다. 샤드 하나당 루씬 인덱스가 하나씩 더 뜨며 힙을 차지 한다. 주 샤드를 하나 더 띄울 때마다 복제본 샤드도 늘어나는 것을 고려..

서비스 출시를 위한 초기 데이터 세팅이나 마이그레이션, reindex 를 통한 인덱스 재생성 등 대량 색인이 필요할 때가 있습니다. 이런 경우에는 색인 도중 데이터를 조회할 필요가 없다. 따라서 다음과 같은 설정을 통해 색인 속도를 높일 수 있습니다. PUT my_index/_settings { "refresh_interval" : "-1", "number_of_replicas" : 0 } refresh를 끄고 복제본 샤드 개수를 0으로 지정해서 복제본 생성을 중지하는 설정이다. 작업이 끝나면 원래 설정으로 복구하는 것을 잊지 않아야 한다.

개요 Elasticsearch 와 같은 분산형 시스템을 다룰 때 동시성 때문에 문제가 생길수 있습니다. Elasticsearch는 어떻게 동시성 문제를 제어하는지에 대해 알아볼겁니다. 그 이전에 동시성 문제가 무엇인지 알아야합니다. 동시성 제어는 여러 클라이언트나 요청이 동시에 Elasticsearch 클러스터에 접근하거나 쓰기 작업을 수행할 때 데이터 무결성을 유지하고 성능을 최적화하기 위해 사용되는 중요한 개념입니다. 인덱스 동시성 - 여러 클라이언트가 동시에 같은 인덱스에 데이터를 쓰려고 할때, Elasticsearch 는 쓰기 작업을 조정하여 데이터 무결성을 보장합니다. 검색 동시성 - 많은 클라이언트가 동시에 검색을 실행할 때, Elasticsearch 는 검색 요청을 효율적으로 처리하기 위해 ..

ES Version : 7.12 kibana : 7.12 요건 : 핫 노드에서 웜 노드로 하루 주기 설정하여 이동 및 read_only 설정했을때와 안했을때의 차이점 현재 핫 노드에서 한달 주기로 저장된 인덱스를 웜 노드로 이동시키고 있습니다. 단지 테스트를 위해서 하루 주기로 변경하였습니다. 대략 한달 된 인덱스 xxxx_2023.08 의 데이터는 하루 대략 2천만건 씩 쌓여서 한달에 대략 6억건 정도가 쌓입니다. 용량으로는 7기가에서 8기가 사이 정도가 됩니다. 요구사항 : 처음 핫웜 아키텍쳐를 도입할때, 고객사에서 한달이 지난 데이터 즉, 웜노드에서도 드물게 읽기 및 검색 외에 업데이트를 원하였습니다. index.lifeCycle management 에서 read_only를 기본설정으로 해놓았기때문..