elasticsearch translog 튜닝 with async

왜 필요할까?

트랜스 로그가 왜 필요한지 기본적인 설명은 전에 설명하였지만 간단하게 설명하면

장애 복구이다 요청 들어온 것을 translog에 기록하여 디스크에 동기화 되었을 때만 해당 데이터를 삭제하는 사이클을 가지고 있다

더 궁금하다면 https://ksk-developer.tistory.com/28 에 들어가서 확인 바란다

오늘은 색인시 더 빨리 색인할 수 있는 간단한 팁을 설명하겠다

index.translog.durability

index.translog.durability이라는 옵션은 기본 값이 request인데

translog도 파일에 건건이 I/O 작업을 하게 된다

실제로 색인, 삭제, 업데이트 벌크 요청등등 매 요청마다 translog에 들어가게 된다

건건이 들어가는 이유는 장애 복구 때문인데 만약 배치나, reindex와 같은 것을 사용한다면 꼭 장애 복구를 대비해서 건건이 translog에 기록할 필요가 있을까? 물론 상황에 따라 다르겠지만 일반 적으로는 아니다

배치 작업을 하다 장애가 난다면 해당 인덱스를 색인하는 정적 색인을 다시 돌리면 되는 것이다

그래서 배치 작업과 같은 사용자(고객) 요청이 아닐경우에는 request가 아니라 async를 사용하자 백그라운드에서 돌아가며 index.translog.sync_interval의 시간의 주기대로 실행된다

전 처럼 건건이 기록되는 것이 아니라 시간의 주기에 따라 몰아서 한번에 I/O를 하게 된다

그럼 전에 보다 훨씬 더 많이 I/O의 건수가 줄게 된다

그리고 이건 그냥 내 생각인데 색인 프로세스에서도 이점이 있을 것 같다

색인 프로세스를 간단하게 보자면 coodinator → data node(primary shard) → data node(replica shard)인데 primary shard는 replica node가 in memory buffer, translog에 입력하고 응답을 줄 때 까지 기다리게 된다 그러나 *async로 설정하면 백그라운드로 하기 때문에 기다릴 필요가 없어지게 된다*

 

*시작 부터 끝이 내 생각이다

 

정리하자면

1. 색인 프로세스에서 primary node를 가진 data node가 replica shard를 가진 data node가 파일에 입력을 완료한 뒤까지 기다릴 필요가 없다
2. shard에서도 전에 비해 I/O가 적게 발생하므로(물론 총양은 같음) 비용에 대해서도 전에 비해 저렴해진다

그러나 배치와 같은 작업이 완료된 뒤에는 async 설정을 request 설정으로 변경해야 한다.

 

현재 회사에 async로 변경하자고 제안을 했고 조만간 도입이 될 것이다