개요
Elasticsearch 와 같은 분산형 시스템을 다룰 때 동시성 때문에 문제가 생길수 있습니다.
Elasticsearch는 어떻게 동시성 문제를 제어하는지에 대해 알아볼겁니다. 그 이전에 동시성 문제가 무엇인지 알아야합니다.
동시성 제어는 여러 클라이언트나 요청이 동시에 Elasticsearch 클러스터에 접근하거나 쓰기 작업을 수행할 때 데이터 무결성을 유지하고 성능을 최적화하기 위해 사용되는 중요한 개념입니다.
- 인덱스 동시성 - 여러 클라이언트가 동시에 같은 인덱스에 데이터를 쓰려고 할때, Elasticsearch 는 쓰기 작업을 조정하여 데이터 무결성을 보장합니다.
- 검색 동시성 - 많은 클라이언트가 동시에 검색을 실행할 때, Elasticsearch 는 검색 요청을 효율적으로 처리하기 위해 자원을 관리하고 검색 결과를 반환합니다.
- 노드간 동시성 - Elasticsearch 클러스터의 여러 노드 간에 데이터를 분산하고 복제할 때, 동시성을 관리하여 데이터 복제 및 복구 프로레스를 안정적으로 수행하빈다.
- Elasticsaerch 내부에서 자동으로 이루어지며, 사용자는 클라이언트 코드에서 추가적인 조치나 설정을 해야할 필요가 없습니다.
1.1 동시성 제어
Elasticsaerch 는 분산 되어 있습니다. 문서가 생성, 업데이트 또는 삭제되면 새 버전의 문서가 클러스터의 다른 노드에 복제되어야합니다. 또한 비동기식 이며 동시에 진행되기 때문에 이러한 복제 요청은 병렬로 전송되며 순서가 맞지 않게 목적지에 도착할 수 있습니다.
Elasticsearch 는 문서의 이전 버전이 최신 버전을 덮어쓰지 않도록 보장하는 방법이 필요합니다.
문서의 이전 버전이 최신 버전을 덮어쓰지 않도록 하기 위해, 문서에 대해 수행되는 모든 작업에는 해당 변경을 조정하는 기본 샤드에 의해 시퀀스 번호가 할당됩니다.
시퀀스 번호는 각 작업에 따라 증가하므로 최신 작업은 이전 작업보다 더 높은 시퀀스 번호를 갖도록 보장됩니다.
그러면 Elasticsearch 는 작업의 시퀀스 번호를 사용해 더 작은 시퀀스 번호가 할당된 변경으로 인해 최신 문서 버전이 재저으이되지 않도록 할 수 있습니다.
1.1-1 동시성 제어 목적
일관성 보장 | 여러 클라이언트 또는 스레드가 동시에 Elasticsearch 에 데이터를 쓰거나 숮어할 때 데이터 일관성을 보장합니다. 동시성에 제어를 통해 충돌이나 데이터 손실을 방지합니다. |
지원관리 | Elasticsearch 클러스터는 제한된 자원 ( 예: CPU, 메모리 , 디스크 공간) 을 가지고 있습니다. 동시성 제어를 사용하여 자원 사용을 효율적으로 관리하고 과부하를 방지합니다. |
성능 향상 | 동시성을 관리하면 다수의 동시 요청에 대한 대기 시간을 최소화하고 응답 시간을 개선할 수 있습니다. Elasticsearch 에서 동시성 제어는 다음과 같은 방법으로 구현됩니다. |
Elasticsearch 에서 동시성 제어는 다음과 같은 방법으로 구현됩니다. |
|
REST API 제한 | Elasticsearch 는 RESTful API 를 통해 상호 작용하며, 클라이언트가 요청을 전송할 때 병렬로 실행될 요청의 수를 제한하는 설정을 가질 수 있습니다. 이를 통해 과도한 요청이 동시에 처리되지 않도록 제어할 수 있습니다. |
스레드 풀 제어 | Elassticsearch 는 내부적으로 스레드 풀을 사용하여 요청을 처리합니다. 스레드 풀 설정을 통해 동시 처리 스레드 수를 제한하거나 조절할 수 있습니다. |
버퍼링과 큐 | Elasticsearch 클라이언트와 서버 간의 요청과 응답은 버퍼링되고 큐잉 될수 있습니다. 이를 통해 요청이 서버로 전달되기 전에 대기하게 하거나 과부하 상태일때 대기열에서 처리 순서를 조절할 수 있습니다. |
릴리스 및 재시도 매커니즘 | Elasticsearch 클라이언트는 요청이 실패할 경우 자동으로 재시도할 수 있는 매커니즘을 가지고 있습니다. 이를 통해 네트워크 문제 또는 일시적이 ㄴ오류로 인해 요청이 실패한 경우에 대처할 수 있습니다. |
예시 ) 전자 상 거래 애플리케이션
웹사이트 방문자가 장바구니에 상품을 추가하고 결제를 완료했다고 가정해 보겠습니다.
그런 일이 발생하면 애플리케이션은 Elasticsearch 에서 제품을 검색합니다.
이 특정 시점에 다른 방문자가 동일한 제품에 대한 결제 플로우를 완료하고 동일한 제품에 대한 결제 flow 를 완료하고 웹 서버의 다른 스레드에서도 제품을 검색합니다. 이시쯤 에서 두 스레드 모두 동일한 제품을 검색했습니다.
이러한 결과는 애플리케이션에 따라 다르지만 이 경우 다음과 같은 결과가 발생할 수 있습니다.
재고가 없는 제품을 판매하여 고객 겸험이 나빠지게 되는것이 있습니다.
이러한 경우 어떻게 해야 일이 발생하지 않을 수 있을까요??
문서를 검색한 이후 수정된 경우 업데이트가 실패하지 않도록 해야합니다. 버전관리가 이때 필요한것이겠죠
_seq_no 와 _primary_term 처럼 동시성을 제어하기 위한 메타데이터로 모든 문서마다 붙는다.
_versio은 0 이상 long 범위 이내의 정수여야 한다.
_seq_no, _primary_term과 다른 점은 클라이언트가 문서의 _version 값을 직접 지정할 수 있다.
◦현재 버전값보다 낮은 값으로 색인할 수 없다.
version_type을 external(external_gt)이나 external_gte로 설정하면 클라이언트가 직접 _version을 지정할 수 있다.
defual version_type 은 internal
다른 스토리지에서 저장된 데이터의 버전을 따로 관리하고 있고 그 데이터를 엘라스틱서치로 받아 와서 2차 스토리지로 동기화하여 사용하는경우 활용하기 좋다.
코드 >
예시) 인덱싱 명령은 문서를 만들고 할당합니다. 초기 시퀀스 번호 및 기본용어
응답 및 필드에서 할당된 시퀀스 번호와 기본 항을 볼 수 있습니다. _seq_no, _primary_term
Elasticsearch는 저장된 각 문서를 변경한 마지막 작업의 시퀀스 번호와 기본 용어를 추적합니다. 시퀀스 번호와 기본 용어는 GET API의 응답에서 _seq_no 및 _primary_term 필드에 반환됩니다
반환 값
참고: 검색 API는 seq_no_primary_term 매개변수를 설정하여 각 검색 히트에 대해 _seq_no 및 _primary_term을 반환할 수 있습니다.
시퀀스 번호와 주 용어는 변경 사항을 고유하게 식별합니다. 반환된 시퀀스 번호와 기본 용어를 기록해 두면 검색 이후 문서에 다른 변경 사항이 없는 경우에만 문서를 변경할 수 있습니다. 이 작업은 인덱스 API, 업데이트 API 또는 삭제 API의 if_seq_no 및 if_primary_term 매개변수를 설정하여 수행합니다.
예를 들어, 다음 인덱싱 호출은 설명이 변경되거나 다른 API에 의해 다른 태그가 추가될 수 있는 가능성을 잃지 않고 문서에 태그를 추가합니다:
'Elasticsearch' 카테고리의 다른 글
엘라스틱서치 - 샤드 운영전략 (0) | 2023.10.01 |
---|---|
엘라스틱서치 - 대량 색인이 필요할 때 (0) | 2023.10.01 |
엘라스틱서치에서 인덱스 생명주기 (elasticsearch- index_lifeCycle management) 설정 (1) | 2023.08.23 |
엘라스틱서치 샤드 재배치 (elasticsearch Shard relocation) (0) | 2023.08.03 |
Elasticsearch - node repurpose tool to clean up (0) | 2023.02.27 |