Fluent Bit 문서/백프레셔 편집하기

==개요==
;백프레셔
특정 시나리오에서는 일부 대상으로 플러시하는 것보다 로그나 데이터가 더 빠르게 수집되거나 생성될 수 있습니다. 이러한 일반적인 시나리오 중 하나는 특히 큰 백로그가 있는 큰 로그 파일에서 읽고 응답하는 데 시간이 걸리는 네트워크를 통해 로그를 백엔드로 디스패치하는 경우입니다. 이로 인해 백프레셔가 발생하여 서비스에서 메모리 소비가 높아집니다.

백프레셔를 방지하기 위해, Fluent Bit는 입력 플러그인이 수집할 수 있는 데이터 양을 제한하는 메커니즘을 엔진에 구현합니다. 이는 '''Mem_Buf_Limit''' 및 '''storage.Max_Chunks_Up''' 설정 파라미터를 통해 수행됩니다.

버퍼링 개념 섹션 에 설명된대로 Fluent Bit는 데이터 처리를 위해 인메모리(기본값)와, 인메모리+파일시스템(선택사항)의 두 가지 모드를 제공합니다.

기본값인 <code>storage.type memory</code>에서 버퍼는 '''Mem_Buf_Limit'''로 제한할 수 있습니다. 메모리가 이 제한에 도달하고 백프레셔 시나리오에 도달하면, 메모리에 있는 데이터 청크가 플러시될 때까지 더 많은 데이터를 수집할 수 없습니다. 입력이 일시중지(pause)되고 Fluent Bit가 <code>[warn] [input] {input name or alias} paused (mem buf overlimit)</code> 로그 메시지를 내보냅니다. 사용 중인 입력 플러그인에 따라 수신 데이터가 삭제될 수 있습니다(예: TCP 입력 플러그인). tail 플러그인은 데이터 손실 없이 일시중지를 처리할 수 있습니다. 현재 파일 오프셋을 저장하고 나중에 읽기를 다시 시작합니다. 버퍼 메모리를 사용할 수 있으면 입력이 로그 수집/수락을 재개(resume)하고 Fluent Bit가 <code>[info] [input] {input name or alias} resume (mem buf overlimit)</code> 메시지를 내보냅니다.

버퍼링 및 스토리지에 설명된대로 <code>storage.type filesystem</code>를 사용하여 파일시스템에 보조 스토리지를 구성하면 이러한 데이터 손실 위험을 완화할 수 있습니다. 처음에는 로그가 메모리와 파일시스템 모두에 버퍼링됩니다. <code>storage.max_chunks_up</code> 제한에 도달하면 모든 새 데이터가 파일시스템에만 안전하게 저장됩니다. Fluent Bit는 메모리에 새 데이터를 추가하는 것을 중지하고 파일시스템에만 버퍼링합니다. <code>storage.type filesystem</code>이 설정되면 <code>Mem_Buf_Limit</code> 설정은 더 이상 효과가 없으며 대신 <code>[SERVICE]</code> 부분의 <code>storage.max_chunks_up</code> 설정이 메모리 버퍼의 크기를 제어합니다.

==Mem_Buf_Limit==
이 옵션은 기본적으로 비활성화되어 있으며 모든 입력 플러그인에 적용될 수 있습니다. Mem_Buf_Limit는 기본값인 <code>storage.type memory</code>에만 적용된다는 점에 유의하세요. 다음 시나리오를 사용하여 동작을 설명하겠습니다.

* Mem_Buf_Limit가 1MB로 설정되었습니다.
* 입력 플러그인이 700KB를 추가하려고 시도합니다.
* 엔진은 데이터를 출력 플러그인으로 라우팅합니다.
* 출력 플러그인 백엔드(HTTP 서버)가 다운되었습니다.
* 엔진 스케줄러는 10초 후에 플러시를 재시도합니다.
* 입력 플러그인이 500KB를 추가하려고 시도합니다.

바로 이 시점에서 엔진은 500KB의 데이터를 메모리에 추가하는 것을 허용합니다. 전체적으로 1.2MB의 데이터가 버퍼링됩니다. 이 한도는 허용적(permissive)이며 한도를 초과하는 단일 쓰기를 허용하지만 한도를 '''초과'''하면 다음 작업이 수행됩니다.

* 입력 플러그인에 대한 로컬 버퍼 차단(더 이상의 데이터를 추가할 수 없음)
* '''일시중지''' 콜백을 호출하는 입력 플러그인에 알림

엔진은 스스로를 보호하며 문제의 입력 플러그인에서 들어오는 데이터를 더 이상 추가하지 않습니다. 일시중지 상태에서 무엇을 할지 결정하는 것은 플러그인의 책임입니다.

일반적으로 초 단위로 측정되는 일정 시간이 지난 후, 스케줄러가 처음의 700KB 데이터를 플러시할 수 있거나 재시도 후 포기한 경우, 해당 메모리 양이 해제되고 다음 작업이 발생합니다.

* 데이터 버퍼 해제(700KB) 시 내부 카운터가 업데이트됩니다.
* 이제 카운터는 500KB로 설정됩니다.
* 500KB는 1MB 미만이므로 입력 플러그인 상태를 확인합니다.
* 플러그인이 일시중지되면 '''재개''' 콜백이 호출됩니다.
* 입력 플러그인은 계속해서 더 많은 데이터를 추가할 수 있습니다.

==storage.max_chunks_up==
<code>storage.type filesystem</code>이 설정되면 <code>Mem_Buf_Limit</code> 설정은 더 이상 효과가 없으며 대신, <code>[SERVICE]</code> 부분의 <code>storage.max_chunks_up</code> 설정이 메모리 버퍼의 크기를 제어합니다.

기본값이 아닌 <code>storage.pause_on_chunks_overlimit</code> 항목이 활성화된 경우, 이 설정은 위의 <code>Mem_Buf_Limit</code> 시나리오와 유사하게 작동합니다.

<code>storage.pause_on_chunks_overlimit</code>이 비활성화되면(기본값), 메모리 제한에 도달해도 입력이 일시중지되지 않습니다. 대신 파일시스템의 로그 버퍼링으로만 전환됩니다. 파일시스템 버퍼링에 사용되는 디스크 공간은 <code>storage.total_limit_size</code>로 제한될 수 있습니다.

자세한 내용은 버퍼링 및 스토리지 문서를 참조하세요 .

==콜백 일시중지 및 재개 정보==
각 플러그인은 독립적이며 모든 플러그인이 일시중지 및 재개 콜백을 구현하는 것은 아닙니다. 이러한 콜백은 플러그인에 대한 알림 메커니즘일 뿐입니다.

이러한 콜백을 구현하고 상태를 올바르게 유지하는 플러그인의 한 가지 예는 Tail 입력 플러그인입니다. '''일시중지''' 콜백이 발동되면 수집기를 일시중지하고 데이터 추가를 중지합니다. '''재개''' 시 수집기를 재개하고 데이터 수집을 계속합니다. Tail은 동일한 위치에서 일시중지하고 다시 시작할 때 현재 파일 오프셋을 추적합니다. 파일이 삭제되거나 이동되지 않은 경우에도, 여전히 읽을 수 있습니다.

기본값 <code>storage.type memory</code>와 <code>Mem_Buf_Limit</code>를 사용하면, 일시중지 및 재개에 대해 다음 로그 메시지가 생성됩니다.

<syntaxhighlight lang='text'>
[warn] [input] {input name or alias} paused (mem buf overlimit)
[info] [input] {input name or alias} resume (mem buf overlimit)
</syntaxhighlight>

<code>storage.type filesystem</code>과 <code>storage.max_chunks_up</code>를 사용하면 일시중지 및 재개를 위해 다음 로그 메시지가 생성됩니다.

<syntaxhighlight lang='text'>
[input] {input name or alias} paused (storage buf overlimit
[input] {input name or alias} resume (storage buf overlimit
</syntaxhighlight>

==참고==
* https://docs.fluentbit.io/manual/administration/backpressure

[[분류: Fluent-bit]]