본문 바로가기

SearchDeveloper/엘라스틱서치 바이블

[2] 엘라스틱서치 기본 동작과 구조

23.11.3

코디네이터 노드 역할

클라 요청을 받아서 데이터 노드에 요청을 분배하고 클라에게 응답을 돌려준다.

루씬 flush

시스템의 페이지 캐시에 데이터를 쓴다. 이 때부터 세그먼트가 되며 검색가능한 상태가 된다.

https://ddongwon.tistory.com/56

page cache
우리가 컴퓨터를 사용할 때, CPU는 사용을 적게 할수록 성능이 좋아진다.(발열관련 문제)
하지만, 메모리는 사용을 적게 하거나 빵빵하게 사용한다고 해서 컴퓨터 성능에 영향을 주지 않는다.
이런 특징을 이용해서 메인 메모리(램)의 남는 공간을 활용해 페이지 캐시(page cache)라는 메모리 공간을 마련해 놓는다. 이 공간은 파일 I/O의 성능을 향상시키기 위해 사용되는 것으로, 사용된 파일의 내용을 저장해 놓았다가 다음에 read나 open할 시에 page cache를 활용하여 컴퓨터의 성능을 극대화 시킨다.

ES 페이지 캐시

루씬 commit

fsync 시스템 콜을 통해 주기적으로 커널 시스템의 flush 에서 쓴 페이지 캐시 내용과 실제 디스크에 기록된 내용의 싱크를 맞추는 작업을 수행한다.

https://backuporigin.tistory.com/entry/fsync-sync-%EC%B0%A8%EC%9D%B4%EC%A0%90-%ED%99%9C%EC%9A%A9%EB%B2%95

fsync: 디스크에 쓰는거

파일을 새로 만들고 저장하면, 내 하드 디스크에 바로 그 즉시 저장될까? 정답은 아니다. 실제로 우리가 새로 만든 파일은 우선 메모리 버퍼에 저장되며 운영체제(커널)가 판단하여 일정 시간이 지난 뒤 하드 디스크에 저장한다.

fsync
변경 파일(data와 metadata)을 하드 디스크에 저장되도록 요청하며, data와 metadat가 저장될 때 까지 기다린다.

sync
현재 버퍼에 있는 모든 파일들을 디스크에 저장하도록 요청한다. 요청만 할 뿐, 실제 저장 완료될 때까지 기다리진 않는다. 따라서 자주 사용하게 되면 시스템 성능에 영향을 미칠 수 있다. 꼭 필요한 상황에서만 사용하는 것이 좋다.

세그먼트

디스크에 기록된 파일들이 모이면 세그먼트라는 단위가 되며, 이 세그먼트가 루씬의 검색 대상이다.

루씬 인덱스와 엘라스틱서치 인덱스

여러 세그먼트가 모이면 하나의 루씬 인덱스가 된다. 루씬은 이 인덱스에서만 검색 가능하다.

ES 샤드는 이 루씬 인덱스 하나를 래핑한 단위다.

이후 클라이언트가 검색 요청을 보내면 ES 는 각 샤드를 대상으로 검색을 한 뒤 그 결과를 모아 병합하여 최종 응답을 만든다.

이렇게 루씬 레벨에서는 불가능한 분산 검색을 ES 레벨에서는 가능하게 만든다.

translog

-ES 는 루씬 commit 까지 완료되어야 디스크에 안전하게 기록되는데, 그 전 단계에서 장애가 발생하면 데이터가 유실될 우려가 있다. 이를 방지하기 위해 translog 라는 작업 로그를 남긴다.

-샤드 복구 단계에서 translog 에는 기록되어있지만 commit 에 포함되지 않은 작업 내용을 복구한다.

-translog 파일 크기가 너무 크면 복구할 때 읽느라 오래 걸릴 수 있으므로 적절히 잘라줘야 한다. ES flush 가 백그라운드에서 주기적으로 수행되며 translog 크기를 적절하게 유지한다.

-translog 에는 디스크에 fsync 된 데이터만 보존된다. 클라이언트가 색인, 삭제, 수정 등의 요청을 보냈을 때 ES 는 translog 에 성공적으로 fsync 됐을 때만 성공을 보고한다.

 

레퍼런스

엘라스틱서치 바이블 2장