Fluent Bit 문서/버퍼링 및 스토리지

1 개요[ | ]

Buffering & Storage
버퍼링 및 스토리지

Fluent Bit의 최종 목표는 로그를 수집, 구문분석, 필터링하고 중앙 위치로 전달하는 것입니다. 이 워크플로우에는 여러 단계가 있으며 중요한 부분 중 하나는 버퍼링 기능입니다 . 버퍼링은 전송 준비가 될 때까지 처리된 데이터를 임시 위치에 배치하는 메커니즘입니다.

기본적으로 Fluent Bit는 데이터를 처리할 때 메모리를 레코드를 저장하기 위한 기본 및 임시 장소로 사용하지만, 집계 및 데이터 안전 기능을 제공하기 위해 파일 시스템 기반의 영구 버퍼링 메커니즘을 갖는 것이 이상적인 특정 시나리오가 있습니다.

올바른 설정을 선택하는 것은 중요하며 서비스 동작은 백프레셔 세팅에 따라 조절될 수 있습니다. 설정을 시작하기 전에 청크, 메모리, 파일시스템, 백프레셔 사이의 관계를 이해했는지 확인해 보겠습니다.

2 청크, 메모리, 파일시스템, 백프레셔[ | ]

적절한 설정을 위해서는 청크, 버퍼링, 백프레셔 개념을 이해하는 것이 중요합니다. 이러한 개념의 의미를 요약해 보겠습니다.

2.1 청크[ | ]

입력 플러그인(소스)이 레코드를 내보내면 엔진은 해당 레코드를 청크로 그룹화합니다. 청크 크기는 일반적으로 약 2MB입니다. 설정에 따라 엔진은 이 청크를 배치할 위치를 결정하며, 기본값은 모든 청크가 메모리에만 생성되는 것입니다.

2.2 복구불가 청크[ | ]

fluent-bit가 청크를 복구불가로 마킹하는 경우는 다음 두 가지 시나리오입니다.

Fluent Bit가 청크에서 잘못된 레이아웃을 발견한 경우. 잘못된 레이아웃은 예상 형식을 따르지 않는 청크입니다(청크의 정의),
Fluent Bit가 잘못되었거나 유효하지 않은 청크 헤더 크기를 발견한 경우

두 시나리오 모두에서 Fluent-Bit은 오류 메시지를 기록하고 복구불가 청크를 삭제합니다.

2.3 버퍼링과 메모리[ | ]

앞에서 언급했듯이, 엔진에서 생성된 청크는 메모리에 배치되는데 이에 관한 설정이 가능합니다.

메모리가 입력 플러그인에 대해 설정된 유일한 메커니즘인 경우, 가능한 한 많은 데이터가 메모리에 저장됩니다. 이는 시스템 오버헤드가 가장 적은 가장 빠른 메커니즘이지만, 느린 네트워크나 응답하지 않는 원격 서비스로 인해 서비스가 레코드를 충분히 빠르게 전달할 수 없는 경우에는, 전달할 수 있는 것보다 더 많은 데이터를 축적하게 되어 Fluent Bit 메모리 사용량이 증가합니다.

백프레셔가 있는 고부하 환경에서는 메모리 사용량이 높아질 위험이 있으며 커널(OOM Killer)에 의해 종료(kill)될 가능성이 있습니다. 이 백프레셔 시나리오에 대한 회피방법(workaround)은 입력 플러그인이 등록하는 레코드의 메모리 용량을 제한하는 것입니다. 이러한 설정 속성이 mem_buf_limit입니다. 플러그인이 mem_buf_limit보다 많은 항목을 큐에 추가한 경우 해당 데이터가 적절하게 전달되거나 플러시될 때까지 더 많은 항목을 수집할 수 없습니다. 이 시나리오에서는 문제의 입력 플러그인이 일시중지되었습니다. 입력이 일시중지되면 재개될 때까지 레코드가 수집되지 않습니다. TCP나 tail과 같은 일부 입력의 경우 입력을 일시중지하면 거의 확실하게 로그 손실이 발생합니다. tail 입력의 경우 Fluent Bit는 읽고 있는 현재 파일에 현재 오프셋을 저장하고 입력이 재개되면 백업을 선택할 수 있습니다.

Fluent Bit 로그 출력에서 다음과 같은 메시지를 찾아 볼 수 있습니다.

[input] tail.1 paused (mem buf overlimit)
[input] tail.1 resume (mem buf overlimit)

mem_buf_limit 회피방법은 특정 시나리오 및 환경에 적합하고 서비스의 메모리 사용량을 제어하는 데 도움이 되지만, 일시중지된 동안 파일이 회전되면 새 레코드를 등록할 수 없으므로 해당 데이터가 손실될 수 있습니다. 이러한 현상은 모든 입력 소스 플러그인에서 발생할 수 있습니다. mem_buf_limit의 목표는 메모리 조절과 서비스의 생존입니다.

완전한 데이터 안전을 보장하려면 파일시스템 버퍼링을 활용하세요.

다음은 입력 정의의 예시입니다.

[INPUT]
    Name          tcp
    Listen        0.0.0.0
    Port          5170
    Format        none
    Tag           tcp-logs
    Mem_Buf_Limit 50MB

이 입력이 로그 버퍼링에 50MB가 넘는 메모리를 사용하는 경우, Fluent Bit 로그에 다음과 같은 경고가 표시됩니다.

[input] tcp.1 paused (mem buf overlimit)

Mem_Buf_Limit는 storage.type가 기본값인 memory으로 설정된 경우에만 적용됩니다. 아래 섹션에서는 storage.type filesystem을 활성화할 때 적용되는 제한사항을 설명합니다.

2.4 구조(rescue)를 위한 파일시스템 버퍼링[ | ]

파일시스템 버퍼링을 활성화하면 백프레셔 및 전반적인 메모리 조절에 도움이 됩니다.

그 이면에는 메모리와 파일시스템 버퍼링 메커니즘은 상호 배타적이지 않습니다. 실제로 입력 플러그인(소스)에 대해 파일 시스템 버퍼링을 활성화하면 성능과 데이터 안전성이라는 두 가지 장점을 얻을 수 있습니다.

파일시스템 버퍼링이 활성화되면 엔진의 동작이 달라집니다. 청크가 생성되면 엔진은 콘텐츠를 메모리에 저장하고 복사본을 디스크에 (mmap(2)을 통해) 매핑합니다. 새로 생성된 청크는 (1) 메모리에서 활성화되고 (2) 디스크에 백업되며 (3) up 상태("청크 내용이 메모리에 있음")가 되도록 호출됩니다.

파일시스템 버퍼링 메커니즘은 높은 메모리 사용량과 백프레셔를 어떻게 처리할까요? Fluent Bit는 메모리에 있는 up 상태인 청크의 수를 제어합니다 .

기본적으로, 엔진은 총 128개의 청크를 메모리에 올릴(up) 수 있도록 허용하며, 이 값은 서비스 속성 storage.max_chunks_up에 의해 제어됩니다.

업(up) 상태의 활성 청크는 전송 준비가 된 것이며, 한편 아직 레코드를 수신 중인 청크도 있습니다. 다른 나머지 청크는 다운(down) 상태입니다. 즉, 파일시스템에만 있고 전송 준비가 되지 않으면 메모리에 올라가지(up) 않는다는 의미입니다. 청크는 2MB보다 훨씬 클 수 없으므로 storage.max_chunks_up이 기본값인 128이면, 각 입력은 대략 256MB의 메모리로 제한됩니다.

입력 플러그인의 storage.type가 filesystem으로 활성화된 경우, storage.max_chunks_up 임계값에 도달하면, 플러그인이 일시중지되는 대신, 모든 새로운 데이터는 파일시스템에 있는 청크로 이동합니다. 이를 통해 서비스의 메모리 사용량을 제어할 수 있으며 서비스에서 데이터가 손실되지 않는다는 보장도 제공됩니다. 기본적으로, storage.max_chunks_up 제한은 최선(best-effort)의 방식으로 적용됩니다. Fluent Bit는 다음과 같은 up 상태인 청크에만 새 데이터를 추가할 수 있습니다. 제한에 도달하면 청크를 임시로 메모리에 올렸다가(up), 새 데이터를 수집한 다음 down 상태로 전환합니다. 일반적으로 Fluent Bit는 전체 up 청크 수를 storage.max_chunks_up 이하로 유지하도록 작동합니다.

storage.pause_on_chunks_overlimit이 활성화된 경우(기본값은 off), storage.max_chunks_up를 초과하면 입력 플러그인이 일시중지됩니다. 따라서 이 옵션 storage.max_chunks_up을 사용하면 입력에 대한 하드 제한(hard limit)이 됩니다. 입력이 일시중지되면 재개될 때까지 레코드가 수집되지 않습니다. TCP나 tail과 같은 일부 입력의 경우, 입력을 일시중지하면 거의 확실하게 로그 손실이 발생합니다. tail 입력의 경우 Fluent Bit는 읽고 있는 현재 파일에 현재 오프셋을 저장하고 입력이 재개되면 백업을 선택할 수 있습니다.

Fluent Bit 로그 출력에서 다음과 같은 메시지를 찾아볼 수 있습니다.

[input] tail.1 paused (storage buf overlimit
[input] tail.1 resume (storage buf overlimit

2.5 청크에 대한 파일시스템 공간 제한[ | ]

Fluent Bit는 논리적 큐 개념을 구현합니다. 태그를 기반으로 청크를 여러 대상으로 라우팅할 수 있습니다. 따라서 우리는 청크가 생성된 위치와 이동해야 하는 위치에 대한 내부 참조를 유지합니다.

청크에 대한 여러 대상이 있는 경우 대상 중, 하나가 다른 대상보다 느리거나, 하나가 백프레셔를 생성하지만 전부는 아닌 경우를 찾는 것이 일반적입니다. 이 시나리오에서 논리적으로 큐에 추가되는 파일 시스템 청크의 양을 어떻게 제한할까요?

Fluent Bit v1.6부터, 특정 논리적 출력 목적지에 대해 파일시스템에 존재할 수 있는 청크의 총 크기(바이트)를 제한하는 storage.total_limit_size라는, 출력 플러그인에 대한 새로운 설정 속성을 도입했습니다. 목적지들 중 하나가 설정된 storage.total_limit_size에 도달하면, 해당 논리적 출력 목적지에 대한 큐에서 가장 오래된 청크가 삭제되어 새 데이터를 위한 공간을 확보합니다.

3 설정[ | ]

스토리지 계층 설정은 다음 세 가지 영역으로 이루어집니다.

서비스 섹션
입력 섹션
출력 섹션

알려진 서비스 섹션은 스토리지 계층에 대한 전역 환경을 설정하고, 입력 섹션은 사용할 버퍼링 메커니즘을 정의하며, 출력은 논리적 파일 시스템 큐에 대한 제한을 정의합니다.

3.1 서비스 섹션 설정[ | ]

서비스 섹션은 기본 설정 파일에 정의된 섹션을 참조합니다.

키	설명	기본값
storage.path	스트림과 데이터 청크를 저장할 파일 시스템의 선택적 위치를 설정합니다. 이 매개변수가 설정되지 않으면 입력 플러그인은 메모리 내 버퍼링만 사용할 수 있습니다.
storage.sync	데이터를 파일 시스템에 저장하는 데 사용되는 동기화 모드를 구성합니다. Normal 또는 full 값을 사용할 수 있습니다 . 전체를 사용하면 파일 시스템 버퍼의 안정성이 향상되고 Fluent Bit가 충돌하더라도 데이터가 파일 시스템에 동기화되도록 보장됩니다. Linux에서 full은 MAP_SYNC 옵션 에 해당합니다.	normal
storage.checksum	파일시스템에서 데이터를 쓰고 읽을 때 데이터 무결성 검사를 활성화합니다. 스토리지 계층은 CRC32 알고리즘을 사용합니다.	Off
storage.max_chunks_up	입력 플러그인이 filesystem저장소 유형을 활성화한 경우 이 속성은 메모리에 있을 수 있는 최대 청크 수를 설정합니다 up. 활성화할 때 메모리 사용량을 제어하는 데 사용하는 설정입니다 storage.type filesystem.	128
storage.backlog.mem_limit	storage.path가 설정된 경우 Fluent Bit는 전달되지 않았지만 여전히 스토리지 계층에 있는 데이터 청크를 찾습니다. 이를 백로그 데이터라고 합니다. 백로그 청크는 이전 Fluent Bit 실행에서 남은 파일 시스템 청크입니다. 다시 시작할 때 Fluent Bit가 선택하는 종료 전에 보낼 수 없는 청크입니다. Fluent Bit는 입력에 대한 storage.backlog.mem_limit모든 청크의 현재 메모리 사용량과 비교하여 값을 확인합니다 . 청크가 현재 제한보다 적은 메모리를 소비하는 up경우 백로그 청크를 메모리로 가져와 출력으로 전송할 수 있습니다.	5M
storage.metrics	http_server기본 섹션에서 옵션이 활성화된 경우 [SERVICE]이 옵션은 스토리지 계층의 내부 메트릭을 사용할 수 있는 새 엔드포인트를 등록합니다. 모니터링 섹션을 참조하세요.	off
storage.delete_irrecoverable_chunks	활성화되면 런타임 중에 삭제되고, 설정된 저장 경로 디렉터리에 있는 다른 복구할 수 없는 청크는 Fluent-Bit이 시작될 때 삭제됩니다.	off

서비스 섹션은 다음과 같이 생겼습니다.

[SERVICE]
    flush                     1
    log_Level                 info
    storage.path              /var/log/flb-storage/
    storage.sync              normal
    storage.checksum          off
    storage.backlog.mem_limit 5M

해당 구성은 데이터 경로가 /var/log/flb-storage/인 선택적 버퍼링 메커니즘을 설정하며, 백로그 데이터를 처리할 때 체크섬을 실행하지 않고 최대 5MB의 메모리를 사용하여 일반 동기화 모드를 사용합니다.

3.2 입력 섹션 설정[ | ]

선택적으로 모든 입력 플러그인은 스토리지 기본설정을 설정할 수 있습니다. 다음 표에서는 사용가능한 옵션을 설명합니다.

키	설명	기본값
storage.type	사용할 버퍼링 메커니즘을 지정합니다. memory(메모리) 또는 filesystem(파일시스템)일 수 있습니다.	memory
storage.pause_on_chunks_overlimit	storage.max_chunks_up 값에 도달 하면 입력 플러그인을 일시중지(새 데이터 수집 중지)해야 하는지 여부를 지정합니다.	off

다음 예시에서는 파일시스템 버퍼링 기능과 두 개의 입력 플러그인(첫 번째는 파일시스템 기반, 두 번째는 메모리 전용)을 제공하는 서비스를 설정합니다.

[SERVICE]
    flush                     1
    log_Level                 info
    storage.path              /var/log/flb-storage/
    storage.sync              normal
    storage.checksum          off
    storage.max_chunks_up     128
    storage.backlog.mem_limit 5M

[INPUT]
    name          cpu
    storage.type  filesystem

[INPUT]
    name          mem
    storage.type  memory

3.3 출력 섹션 설정[ | ]

특정 청크가 파일시스템 storage.type 기반인 경우, 출력 플러그인에 대한 논리적 큐의 크기를 조절할 수 있습니다. 다음 표에서는 사용가능한 옵션을 설명합니다.

키	설명	기본값
storage.total_limit_size	현재 출력 논리적 대상에 대한 파일 시스템의 청크 버퍼링을 위한 최대 디스크 공간 크기(바이트)를 제한합니다.

다음 예시에서는 파일시스템에 CPU 사용량 샘플이 포함된 레코드를 생성한 후 논리적 큐(버퍼링)을 5M로 제한하는 Google Stackdriver 서비스에 전달합니다.

[SERVICE]
    flush                     1
    log_Level                 info
    storage.path              /var/log/flb-storage/
    storage.sync              normal
    storage.checksum          off
    storage.max_chunks_up     128
    storage.backlog.mem_limit 5M

[INPUT]
    name                      cpu
    storage.type              filesystem 

[OUTPUT]
    name                      stackdriver
    match                     *
    storage.total_limit_size  5M

어떤 이유로 Fluent Bit가 네트워크 문제로 인해 오프라인 상태가 되면 CPU 샘플을 계속 버퍼링하지만 최신 데이터는 최대 5MB만 유지합니다.

4 같이 보기[ | ]

Fluent Bit 청크

5 참고[ | ]

https://docs.fluentbit.io/manual/administration/buffering-and-storage