logstash의 Persistent quees 및 Backpressure 소개

이것은 FJCT Advent Calendar 다음날의 문장이다.
첫날은 @fuku2014의Let's Encerypt의 DNS-01 방식은 Nifuclass DNS 인증을 통해 무료 SSL 인증서를 획득하고 자동으로 업데이트됩니다.였다.
셋째 날은 @riow씨의 착각, 정해진 시간 전에 돌아가면 재발 방지 대책과입니다.
이는 OJT가 엘라스틱 검색-logstash-kibana를 활용해 로그 기반을 개발할 때 로지스타쉬에 대한 기사가 많지 않아 자신이 재미있게 생각하는 부분을 묘사한 것이다.다음은logstash 문서를 참고하여 다음과 같은 두 가지 내용을 설명한다.

logstash의Persistent queues와backpressure에 대한 소개

메시지 대기열 등 도구를 만들 때 참고할 수 있는 구조에 대한 소개

logstash 소개

logstash의 소개는 아래의 홈페이지를 참조하십시오
개방된 원본의 서버 측 데이터 처리 라인에서 수량이 방대한 원본에서 동시에 데이터를 얻는다
변환 후 지정한 임의의 라이브러리로 보냅니다. (우리에게는 당연히 Elasticsearch입니다.)
https://www.elastic.co/jp/products/logstash

영구 대기열

logstash의 약점은 버퍼 메모리가 없다는 것이라고 한다.따라서 대량의 로그를 처리할 때 자주 버퍼 역할과 MQ 도구(kafka 등)로 조합된다.
그래서 이쪽 상황을 개선하기 위해서다.x에서perrsistent queues (영구 대기열) 기능을 할 수 있습니다.
그나저나 logstash의 기본 설정에서 로그 버퍼는 in memory이기 때문에 변경할 수 없습니다.이런 상황에서 데이터 흐름은 다음과 같다. 과정이 사라지기 때문에 로그 손실의 가능성이 높다.
input -> pipeline -> workers
perrsistent queues (지속 대기열) 기능은 변경 가능한 in disk 버퍼 메모리입니다.또한 프로세스가 사라진 후 다시 시작할 때 처리에서 시작되기 때문에 로그의 손실을 방지할 수 있다.이 때의 데이터 흐름은 다음과 같다.
input → queue → filter + output

설정 방법

이 글은 설정 방법과 in-memory와 in-disk의 비교가 있으니 참고하시기 바랍니다.
https://dev.classmethod.jp/server-side/elasticsearch/logstash-queue-persisted/

구조

데이터 관리 구조

Persistent quees는 페이지 단위로 데이터를 관리합니다.1페이지는 queue.page_capacity에 설정된 bytes 용량의 1file에 해당한다.또한 페이지는 헤드 페이지와tail 페이지 두 가지가 있습니다.Head page는 데이터를 쓸 수 있는 곳이며 확장만 가능합니다.헤드 페이지는 자신의 사이즈가 커지면tail 페이지로 바뀌어 새로운 헤드 페이지를 만든다.Tail 페이지의 데이터는 이후 로그의 Filter와 output 단계로 전송되며 모든 처리가 정상적으로 끝난 후 output 모듈에서 ACK로 되돌아와tail 페이지를 삭제합니다.
페이지는 여러 개의 이벤트라는 논리 단위로 구성되어 있습니다.queue.max_events에서 1페이지의 이벤트 수량을 지정할 수 있습니다.logstash는 이벤트 단위로 처리됩니다.예를 들어 웹 페이지의 삭제(스팸 수거)는 소속된 모든 이벤트가 ACK를 받은 상태에서만 가능하다.또한logstash 프로세스가 비정상적으로 정지되어 다시 시작할 때 ACK를 받지 못한 이벤트는 손상되지 않고 처리됩니다.

Back pressure

대기열queue.max_bytes에 설정된 최대 크기에 도달했을 때logstash는 데이터를 보내는 목적지(beats 등)에 데이터 발송을 잠시 중지하도록 요구한다. 이것을backpressure라고 한다.이렇게 하면logstash 프로세스 자체의 부하를 어느 정도 이하로 제한할 수 있고elasticsearch에 대한 불합리한 output을 피할 수 있다.그나저나'대열이 찼다'는 ACK를 받지 못한 이벤트가 매몰된 상태를 뜻한다.Back pressure가 빈번하게 발생하면logstash가 시스템의 데이터 양을 처리할 수 없기 때문에 대기열 크기를 늘리고 서버의 규격을 높여야 합니다.

쓰기 관리

인풋이 멈추고 다시 시작할 때 어디서 시작되는지 어떻게 알아요?logstash는 checkpoint 파일을 생성하여 자신의 데이터 쓰기 상태를 감시하고 쓰기 대상의 헤드 페이지 상태를 관리합니다.구체적으로 헤드 페이지fsync의 상태를memory에서disk로 저장합니다.한 번의 쓰기가 1 이벤트가 됩니다.queue.checkpoint.writes 에서memory에 몇 번을 써야 디스켓에 쓸 수 있는지 지정할 수 있습니다.1를 지정하면 데이터의 건전성을 최대한 유지할 수 있으나 성능에 영향을 미칠 수 있다.반대로 이걸 드리면logstash의 처리 속도를 높일 수 있습니다.자세한 내용checkpoint의 원본 코드는 이쪽으로 여겨집니다.

최후

logstash의Persistentquees 기능은 메시지 대기열 등 도구를 만들 때 참고할 수 있는 구조라고 생각합니다.물론 in-disk를 사용하면 성능에 좋지 않은 영향을 미칠 수 있다고 생각하지만 여기 기사. 검증 결과
10만 개의 in-disk는 in memory보다 17초 차이가 나기 때문에 그 정도의 차이는 시스템에 따라 허용되지 않을 수 있습니다.
내일은 @riow씨의 착각, 정해진 시간 전에 돌아가면 재발 방지 대책과입니다.
정말 재밌는 걸 기대할 수 있을 거예요!