[Elasticsearch] document 읽고 쓰는 과정 정리

1. ES에서 document를 읽어오는 과정을 도식화

 

 

1.1 ES에서 document를 읽어오는 과정

1. 읽기 요청은 coordinating node에서 수신 및 처리
2. 이후 routing 공식을 통해 document가 어떤 primary 샤드 혹은 replication group 내 존재하는지 확인
3. 만약 es가 document를 바로 primary 샤드로부터 읽어온다면, 읽어온 document들이 모두 동일한 샤드에 위치하는 문제가 발생 즉, scaling이 잘 안 되는 문제가 발생 -> doesn't scale well
4. 따라서, es는 이러한 문제를 방지하기 위해 Adaptive Replica Selection 기법을 사용하며 ARS는 최적의 샤드를 선택
5. ARS를 통해 샤드가 선택되면, coordinating node는 해당 샤드에게 읽기 요청을 보냄
6. coordinating node가 샤드로부터 응답을 수신한 뒤 클라이언트에게 전달

 

* 디폴트 라우팅 공식: shard_num = hash(document ID) % num_of_primary_shards 

* ARS는 로드 밸런서 역할도 하면서 쿼리 응답 시간을 단축시키는 역할도 함

 

2. ES에서 document를 쓰는 과정을 도식화

 

 

2.1 ES에서 document를 쓰는 과정

1. 쓰기 요청은 coordinating node에서 수신 및 처리
2. 이후 routing 공식을 통해 primary 샤드로 라우팅 (쓰기 요청은 항상 primary 샤드로 라우팅)
3. primary 샤드는 쓰기 요청을 검증하는 역할을 하며 요청의 구조(structure of request)와 필드 값(field value)를 검증
4. 우선, primary 샤드 내 document를 저장하며 이후 replication group 내 replica 샤드들에 대해 document 저장을 진행
5. 성능을 향상시키기 위해 replica 샤드들에 document를 저장할 때 병렬로 진행 

 

* primary 샤드에 document 저장이 성공할 경우 replica 샤드에 document 저장이 실패하더라도 write operation은 성공 처리

* es에서 다양한 요청이 비동기로 진행되므로 하드웨어 오류와 같은 오류로 인해 replica 샤드 내 document 저장하는 과정에서 실패할 수 있으며 이럴 경우 es는 복구 프로세스를 진행

 

2.2 replica 샤드 내 document 쓸 때 실패하는 예시와 복구 프로세스를 진행할지 판별하는 과정

예시

• primary 샤드 내 document 저장을 성공하고 replica 샤드 A에도 성공한 상태에서 replica 샤드 B에 저장을 진행할 때 하드웨어 오류로 인해 primary 샤드가 다운되어 replica 샤드 B에는 저장이 실패한 상황,
• replica group에는 반드시 primary 샤드가 존재해야 하기 때문에 es는 replica 샤드 B를 primary 샤드로 교체
• 문제는 primary 샤드로 바뀐 샤드가 아직 갱신이 안된 상황 즉, replica shard A와 primary 샤드의 형상이 맞지 않음

복구 프로세스를 진행할지 판별하는 과정

• es는 이를 primary terms와 sequence numbers를 통해 해결
• 위 케이스 같은 경우 replication group 내 primary 샤드가 변경되었기 때문에 primary term이 1에서 2로 변함
• replica 샤드에 대해 쓰기 요청이 진행될 때 현재 primary term 값이 같이 보내짐
• 따라서, 요청을 받은 replica 샤드는 primary term 값을 보고 primary 샤드가 변경되었는지 여부를 파악할 수 있으며 이를 통해 복구를 진행할지 여부를 파악 가능

복구 프로세스 과정

• https://jaimemin.tistory.com/1879 내 12번 13번 참고

 

출처

Udemy (elasticsearch-complete-guide)