문의
ES로 쿼리요청이 2000개 정도 동시에 막 들어오면 1개씩 순차적으로 처리되는지멀티로 처리되는지 궁금합니다.
만약 멀티로 처리되면 몇개씩 처리가 되는지,?
동시에 처리하는 개수 조절할 수 있는지?
노드당 동시 처리할 수 있는 job의 개수 정보 있는지 관련된 정보 공유 부탁드립니다.
답변
만약 3개 노드로 구성된 클러스터에서 master/data역할을 동시에 수행하도록 설정된 경우 그리고 kibana를 통해 검색 요청이 전달되는 경우, kibana는 High availability across multiple Elasticsearch nodes 페이지 설명과 같이 round robin형태로 각 노드로 요청을 전달합니다. 각 노드는 search thread pool 을 가지며 pool size는 최초 1000으로 설정 그리고 Thread pools > search 설명과 같이 산출됩니다. 수신된 요청은 순차적으로 처리되며 검색 요청 처리에 필요한 샤드의 위치를 내부 로직에 의해 노드가 선택되어 내부 요청 전달이 이루어 집니다. 요청이 많고 요청 처리에 시간이 걸리는 경우 경우(예, 해당 샤드를 저장하여 처리해야 할 노드가 바쁜 경우나 많은 샤드를 기반으로 검색 요청이 이뤄지는 경우), 내부 queuing 되며 해당 queue 임계치보다 많은 요청 수신 시 (1000보다 더 많이 큐잉되는 경우), rejected 처리 되게 됩니다. 따라서, replica shard를 클러스터 내에 추가 설정하여 replica shard I을 저장한 노드가 바쁜 경우 다른 replica shard II을 저장한 노드로 내부 라우팅을 통해 검색 성능 개선 효과도 볼수 있습니다. 동시에 처리하는 개수를 조절은 가능하지 않으며, replica shard수를 늘려 특정 노드가 바쁜 시점에는 상대적으로 덜 바쁜 노드로 요청되게 하여 개선 효과를 기대하는것이 좋을 것으로 보입니다. 관련 검색 요청 라우팅 로직은 Adaptive replica selection페이지를 통해 확인가능합니다.
추가로 공유드리면, cat thread pool API를 사용하시어 GET _cat/thread_pool/search?v search thread pool의 노드별 active, queue, rejected 상태 조회가 가능하며 rejected는 해당 노드가 기동된 이후의 누적값 (과거 rejected count가 해당 노드 서비스 재기동 이전까지 리셋되지 않음)으로 확인됩니다. 만약 rejected가 확인되는 경우, 현재 사용중인 search query들을 slow logs를 설정하여 어느 쿼리에서 지연이 있었는지 확인가능할 것입니다. 또는, Tune for search speed 페이지 항목들을 통해 전반적인 쿼리 처리 성능을 개선할 수도 있습니다.
위 내용 참고부탁드리며, 추가 질문이 있으신 경우 다시 알려주세요.
댓글