Ch09. 엘라스틱서치와 루씬 이야기- 고가용성을 위한 Translog의 비밀

엘라스틱서치는 분산 시스템이 지원해야 하는 고가용성을 제공하기 위해 내부적으로 Translog라는 특수한 형태의 파일을 유지하고 관리하고 있다. 장애 복구를 위한 백업 데이터 및 데이터 유실 방지를 위한 저장소로써 Translog를 적극 활용한다.

Translog의 동작 순서

샤드 내부 Translog 개념

• 엘라스틱서치 샤드는 내부에 Translog라는 특수 파일을 가지고 있으며, 샤드에 변경사항이 생길 경우 Translog 파일에 해당 내용을 기록한 후, 내부에 존재하는 루씬 인덱스로 데이터를 전달한다.
• 엘라스틱서치는 기본적으로 1초마다 Refresh 작업이 수행되는데, 이때 Translog 파일에 기록된 내용은 삭제되지 않고 유지된다.
• Translog는 엘라스틱서치 샤드에서 일어나는 모든 변경사항을 담고 있는 특수한 형태의 로그이다.
  • Translog 내역을 바탕으로 자애 발생 시 복구 작업을 수행할 수 있다.
• 엘라스틱서치에서 기본적으로 5초마다 Flush() 작업이 수행되고, 이를 성공적으로 마무리하여 물리적으로 디스크 동기화에 성공하면 누적된 Translog 파일 내용이 삭제된다
  • Flush가 일어난다는 것은 디스크에 물리적으로 기록된다는 의미이고, 영구적으로 보관된다는 것을 의미하기에 이 시점까지의 로그는 더는 필요 없어진다.
  • Translog의 내부의 로그는 의미가 없어지며, 이 시점 Flush 이전의 정보는 모두 삭제된다.

정리

1. 데이터가 추가되면 Translog에 기록되고 동시에 인메모리 버퍼에 추가된다.
2. Refresh가 수행되면, 인메모리 버퍼에서는 사라지지만, Translog에는 계속 남아있다.
3. 더 많은 데이터가 추가되고, 지속적으로 세그먼트가 추가된다.
4. Translog 일정 크기 이상으로 커지면 Flush 작업이 수행된다.
5. 커밋 포인트가 디스크에 Flush 된다.
6. 시스템 캐시의 내용이 디스크에 Flush 된다.
7. Translog의 기록이 삭제된다.

Translog가 존재하는 이유

상황 [1]: Flush에 의해 루씬 Commit 작업이 시작되었지만, 완료되기 전에 샤드에 장애가 발생

해결 방법: 샤드가 강제로 종료될 경우 진행 중이던, 루씬 Commit 작업이 롤백되기 때문에 샤드를 정상적으로 재실행하고 나면 Translog의 로그 내역을 이용해 복구할 수 있다.(Translog 내역을 바탕으로 순차적으로 인메모리 버퍼를 복구, Refresh가 수행되고 나면 Flush 시점에 루씬 Commit이 수행)

 

상황 [2]: 변경사항이 순간적으로 많아져 루씬 Commit이 긴 시간 일어나게 되고, 그동안 많은 데이터 변경 요청이 한꺼번에 샤드로 들어오면?

해결 방법: 루씬 Commit 작업 수행이 길어진다고 Commit이 일어나는 동안 샤드로 전달된 변경사항이 반영되지 않는다면 실시간 검색을 지원하는 것의 의미가 퇴색될 것이다. (엘라스틱서치는 Commit이 일어나는 동안 들어온 변경사항을 루씬 인메모리 버퍼로 전달하지 않고 Translog로 임시 저장 후, 다음 Commit에 반영될 떄까지 유지한다.) -> 샤드는 세그먼트 검색을 수행하기 전에 Translog에서 임시로 저장된 변경사항이 없는지를 먼저 확인하게 되며, 이러한 매커니즘 때문에 루씬 Commit이 아무리 긴 시간 일어나도 변경사항에 대한 데이터 유실 없이 서비스를 안정적으로 유지할 수 있다.

 

1) Translog가 존재하는 가장 큰 이유는 장애 복구를 위해서다.

엘라스틱서치에서 실시간에 가까운 데이터를 제공하기 위해 1초마다 Refresh 작업을 수행하지만 이는 불안정한 상태로, 장애 발생 시 완벽한 복구를 위해서는 물리적인 디스크로 동기화하는 Flush가 반드시 필요하다. 그렇지만 Flush는 무거운 작업으로 상대적으로 긴 시간동안 발생할 수 있기에 Translog 파일을 일종의 임시 보관소로 사용하여 문제가 발생하더라도 데이터의 유실 없이 서비스를 가능하게 한다.

 

2) 운영 중에 샤드에 크래시가 발생할 경우에도 Translog를 사용한다.

Translog에 기록된 내용을 이용하면 사드를 완벽하게 복구할 수 있기 때문에 이를 다시 한번 재실행하면 샤드를 완벽하게 복구할 수 있을 것이다.

 

하지만 Translog 파일의 크기가 커질수록 장애 복구에 걸리는 시간도 늘어난다. 복구를 위해서는 마지막 루씬 Commit 이후의 모든 내역을 재실행해서 세그먼트를 재생성하는 과정이 필요하기 때문이다. Translog 파일이 크면, 그만큼 복구해야 하는 파일이 많다는 것이고 이를 복구하는 과정에서 다시 장애가 발생하며 지속적인 장애로 이어져 전체적인 클러스터가 마비되는 장애가 유발될 수도 있다. 
그러므로 데이터의 크기나 양에 따라 적절한 정책을 세우고 Translog의 크기를 관리하는 것이 중요하며, 적절한 주기로 Flush를 수행해 Translog의 크기가 항상 일정 크기 이하를 유지할 수 있도록 모니터링하고 관리하는것이 안정적인 클러스터를 운영하기 위한 기본이다.