높은 처리량을 위한 Amazon ECS 로그 구성

로그 처리량이 많은 시나리오의 경우, FireLens 및 Fluent Bit와(과) 함께 awsfirelens 로그 드라이버를 사용하는 것이 좋습니다. Fluent Bit은(는) 리소스를 효율적으로 사용하며 수백만 개의 로그 레코드를 처리할 수 있는 경량 로그 프로세서입니다. 하지만 대규모 환경에서 최적의 성능을 달성하려면 구성을 조정해야 합니다.

이 섹션에서는 시스템 안정성을 유지하고 데이터 손실이 없도록 보장하면서 높은 로그 처리량을 처리하기 위한 고급 Fluent Bit 최적화 기술을 다룹니다.

FireLens에서 사용자 지정 구성 파일을 사용하는 방법에 대한 자세한 내용은 사용자 지정 구성 파일 사용을(를) 참고하세요. 추가 예제는 GitHub의 Amazon ECS FireLens 예제를 확인하세요.

청크 이해

Fluent Bit는 데이터를 청크라는 단위로 처리합니다. INPUT 플러그인이 데이터를 수신하면 엔진은 OUTPUT 대상으로 전송되기 전에 메모리 또는 파일 시스템에 저장되는 청크를 생성합니다.

버퍼링 동작은 INPUT 섹션의 storage.type 설정에 따라 달라집니다. 기본적으로 Fluent Bit는 메모리 버퍼링을 사용합니다. 높은 처리량 또는 프로덕션 시나리오의 경우 파일 시스템 버퍼링은 더 나은 복원력을 제공합니다.

자세한 내용은 Fluent Bit 설명서의 청크 및 AWS for Fluent Bit 리포지토리 예제의 청크란 무엇입니까?를 참조하세요.

메모리 버퍼링(기본값)

기본적으로 Fluent Bit는 메모리 버퍼링(storage.type memory)을 사용합니다. Mem_Buf_Limit 파라미터를 사용하여 INPUT 플러그인당 메모리 사용량을 제한할 수 있습니다.

다음 예제에서는 메모리 버퍼 입력 구성을 보여줍니다.

[INPUT]
    Name          tcp
    Tag           ApplicationLogs
    Port          5170
    storage.type  memory
    Mem_Buf_Limit 5MB

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

메모리 버퍼링은 로그 처리량이 낮거나 중간 수준인 간단한 사용 사례에 적합합니다. 데이터 손실이 우려되는 높은 처리량 또는 프로덕션 시나리오의 경우 파일 시스템 버퍼링을 대신 사용합니다.

자세한 내용은 Fluent Bit 설명서의 버퍼링 및 메모리와 AWS for Fluent Bit 리포지토리 예제의 메모리 버퍼링 전용을 참조하세요.

파일 시스템 버퍼링

처리량이 많은 시나리오의 경우 파일 시스템 버퍼링을 사용하는 것이 좋습니다. Fluent Bit이(가) 버퍼링과 스토리지를 관리하는 방법에 대한 자세한 내용은 Fluent Bit 문서의 버퍼링 및 스토리지 섹션을 참고하세요.

파일 시스템 버퍼링은 다음과 같은 장점을 제공합니다:

파일 시스템 버퍼링을 활성화하려면 사용자 지정 Fluent Bit 구성 파일을 제공하세요. 다음 예시는 권장 구성을 보여줍니다:

[SERVICE]
    # Flush logs every 1 second
    Flush 1
    # Wait 120 seconds during shutdown to flush remaining logs
    Grace 120
    # Directory for filesystem buffering
    storage.path             /var/log/flb-storage/
    # Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
    storage.max_chunks_up    32
    # Flush backlog chunks to destinations during shutdown (prevents log loss)
    storage.backlog.flush_on_shutdown On

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    # Run input in separate thread to prevent blocking
    threaded true
    # Enable filesystem buffering for persistence
    storage.type filesystem

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    # Use multiple workers for parallel processing
    workers 2
    # Retry failed flushes up to 15 times
    retry_limit 15
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 10G

주요 구성 파라미터:

자세한 내용은 Fluent Bit 설명서의 파일 시스템 버퍼링과 AWS for Fluent Bit 리포지토리 예제의 파일 시스템 및 메모리 버퍼링을 참조하세요.

storage.total_limit_size 이해

각 OUTPUT 플러그인의 storage.total_limit_size 파라미터는 해당 출력의 버퍼링된 데이터에 대한 최대 디스크 공간을 제어합니다. 이 제한에 도달하면 새 데이터 공간을 확보하기 위해 해당 출력의 가장 오래된 레코드가 삭제됩니다. 디스크 공간이 완전히 소진되면 Fluent Bit가 레코드를 대기열에 추가하지 못하고 레코드는 손실됩니다.

다음 공식을 사용하여 로그 속도와 원하는 복구 기간에 따라 적절한 storage.total_limit_size를 계산합니다.

If log rate is in KB/s, convert to MB/s first:
log_rate (MB/s) = log_rate (KB/s) / 1000

storage.total_limit_size (GB) = log_rate (MB/s) × duration (hours) × 3600 (seconds/hour) / 1000 (MB to GB)

다음 표에는 일반적인 로그 속도 및 복구 기간에 대한 계산 예제가 나와 있습니다.

최대 처리량을 관찰하고 적절한 버퍼 크기를 선택하려면 measure-throughput FireLens 샘플을 사용합니다.

공식, 예제 계산 및 벤치마킹을 사용하여 중단 시 최선의 복구를 위한 런웨이를 제공하는 적절한 storage.total_limit_size를 선택합니다.

Amazon ECS 태스크 스토리지 요구 사항

OUTPUT 섹션의 모든 storage.total_limit_size 값을 합산하고 오버헤드에 대한 버퍼를 더합니다. 이 합계는 Amazon ECS 태스크 정의에 필요한 스토리지 공간을 결정합니다. 예를 들어, 출력 3개 × 각 10GB = 30GB + 버퍼(5~10GB) = 총 35~40GB가 필요합니다. 총합니 사용 가능한 스토리지를 초과하면 Fluent Bit가 레코드를 대기열에 추가하지 못하고 레코드는 손실될 수 있습니다.

다음과 같은 스토리지 옵션을 사용할 수 있습니다.

데이터 볼륨에 대한 자세한 내용은 Amazon ECS 작업에 대한 스토리지 옵션 섹션을 참조하세요.

출력 구성 최적화

네트워크 문제, 서비스 중단, 대상지의 스로틀링 등으로 인해 로그가 전달되지 않을 수 있습니다. 적절한 출력 구성은 데이터 손실 없는 복원력을 보장합니다.

출력 플러시가 실패하면 Fluent Bit은(는) 해당 작업을 재시도할 수 있습니다. 다음 파라미터는 재시도 동작을 제어합니다:

재시도 간 대기 시간은 지터와 함께 지수 백오프를 사용합니다.

wait_time = random(base, min(base × 2^retry_number, cap))

예를 들어 scheduler.base 10 및 scheduler.cap 60 사용 시:

자세한 내용은 Fluent Bit 설명서의 재시도 대기 시간 구성 및 네트워킹을 참조하세요.

[SERVICE] 섹션의 Grace 파라미터는 종료 시 버퍼링된 데이터를 플러시하기 위해 Fluent Bit이(가) 대기하는 시간을 설정합니다. Grace 기간은 컨테이너의 stopTimeout와(과) 연계하여 조정해야 합니다. Fluent Bit이(가) SIGKILL을(를) 받기 전에 플러시를 완료할 수 있도록 stopTimeout이(가) Grace 기간을 초과하도록 설정하세요. 예를 들어 Grace이(가) 120초라면, stopTimeout은(는) 150초로 설정합니다.

다음 예시는 높은 처리량 시나리오를 위해 권장되는 모든 설정이 포함된 전체 Fluent Bit 구성을 보여줍니다.

[SERVICE]
    # Flush logs every 1 second
    Flush 1
    # Wait 120 seconds during shutdown to flush remaining logs
    Grace 120
    # Directory for filesystem buffering
    storage.path             /var/log/flb-storage/
    # Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
    storage.max_chunks_up    32
    # Flush backlog chunks to destinations during shutdown (prevents log loss)
    storage.backlog.flush_on_shutdown On
    # Minimum seconds between retries
    scheduler.base           10
    # Maximum seconds between retries (exponential backoff cap)
    scheduler.cap            60

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    # Run input in separate thread to prevent blocking
    threaded true
    # Enable filesystem buffering for persistence
    storage.type filesystem

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    # Use multiple workers for parallel processing
    workers 2
    # Retry failed flushes up to 15 times
    retry_limit 15
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 10G

데이터 손실 시나리오 이해

장기 중단 또는 출력 대상 관련 문제 발생 시 레코드가 손실될 수 있습니다. 이 가이드의 구성 권장 사항은 데이터 손실을 최소화하기 위한 최선의 방식이지만, 장애가 장기화되면 무손실을 보장할 수 없습니다. 이러한 시나리오를 이해하면 복원력을 극대화하도록 Fluent Bit를 구성할 수 있습니다.

레코드는 두 가지 방식으로 손실될 수 있습니다. 스토리지가 가득 찰 때 가장 오래된 레코드가 삭제되거나 시스템에서 더 많은 데이터를 수락할 수 없을 때 최신 레코드가 거부됩니다.

가장 오래된 레코드 삭제

가장 오래전에 버퍼링된 레코드는 재시도가 소진되거나 storage.total_limit_size가 가득 채워지고 새 데이터 공간을 확보해야 할 때 삭제됩니다.

최신 레코드 거부

디스크 공간이 소진되거나 Mem_Buf_Limit로 인해 입력이 일시 중지되면 최신 레코드가 삭제됩니다.

데이터 손실 최소화 모범 사례

데이터 손실 최소화를 위해 고려할 모범 사례:

안전성을 위해 다중 대상 로깅 사용

로그를 여러 대상으로 전송하면 단일 장애점을 제거할 수 있습니다. 예를 들어 CloudWatch Logs에 장애가 발생하더라도 로그는 여전히 Amazon S3에 도달합니다.

다중 대상 로깅은 다음과 같은 이점을 제공합니다. Amazon S3 출력 플러그인은 gzip 및 Parquet 형식과 같은 압축 옵션도 지원하여 스토리지 비용을 절감할 수 있습니다. 자세한 내용은 Fluent Bit 문서의 S3 압축 섹션을 참고하세요.

다중 대상 로깅은 다음과 같은 이점을 제공할 수 있습니다:

다음 Fluent Bit 구성은 CloudWatch Logs와 Amazon S3 모두에 로그를 전송합니다.

[OUTPUT]
    Name cloudwatch_logs
    Match *
    region us-west-2
    log_group_name /aws/ecs/my-app
    log_stream_name $(ecs_task_id)
    workers 2
    retry_limit 15

[OUTPUT]
    Name s3
    Match *
    bucket my-logs-bucket
    region us-west-2
    total_file_size 100M
    s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID
    upload_timeout 10m
    # Maximum disk space for buffered data for this output
    storage.total_limit_size 5G

두 출력 모두 동일한 Match * 패턴을 사용하므로, 모든 레코드가 두 대상지에 각각 독립적으로 전송됩니다. 한 곳의 대상지에 장애가 발생하더라도 로그는 다른 곳으로 계속 흐르며, 실패한 플러시는 나중에 재시도할 수 있도록 파일 시스템 버퍼에 축적됩니다.

tail 입력 플러그인을 사용한 파일 기반 로깅 사용

로그 손실이 중요한 문제인 높은 처리량 시나리오에서는 대안적인 접근 방식을 사용할 수 있습니다. 애플리케이션이 로그를 디스크 파일에 쓰고, Fluent Bit이(가) tail 입력 플러그인을 사용하여 해당 파일을 읽도록 구성하는 방식입니다. 이 방식은 Docker 로깅 드라이버 레이어를 완전히 우회합니다.

tail 플러그인을 사용한 파일 기반 로깅은 다음과 같은 이점을 제공합니다:

이 방식을 사용하려면 애플리케이션이 stdout 대신 파일에 로그를 기록해야 합니다. 애플리케이션 컨테이너와 Fluent Bit 컨테이너 모두 로그 파일이 저장된 공유 볼륨을 마운트합니다.

다음 예시는 모범 사례가 적용된 tail 입력 구성을 보여줍니다.

[INPUT]
    Name tail
    # File path or glob pattern to tail
    Path /var/log/app.log
    # Database file for storing file offsets (enables resuming after restart)
    DB /var/log/flb_tail.db
    # when true, controls that only fluent-bit will access the database (improves performance)
    DB.locking true
    # Skip long lines instead of skipping the entire file
    Skip_Long_Lines On
    # How often (in seconds) to check for new files matching the glob pattern
    Refresh_Interval 10
    # Extra seconds to monitor a file after rotation to account for pending flush
    Rotate_Wait 30
    # Maximum size of the buffer for a single line
    Buffer_Max_Size 10MB
    # Initial allocation size for reading file data
    Buffer_Chunk_Size 1MB
    # Maximum memory buffer size (tail pauses when full)
    Mem_Buf_Limit 75MB

tail 입력 플러그인을 사용할 때는 다음 사항을 고려하세요:

자세한 내용은 Fluent Bit 문서의 Tail 섹션을 참고하세요. 모범 사례는 AWS을(를) 위한 Fluent Bit 문제 해결 가이드의 Tail config with best practices를 참고하세요.

FireLens로 직접 로깅

awsfirelens 로그 드라이버가 태스크 정의에 지정되어 있으면 Amazon ECS 컨테이너 에이전트는 다음 환경 변수를 컨테이너에 주입합니다.

이 환경 변수들을 사용하면 stdout에 기록하는 대신 Fluent Forward 프로토콜을 사용하여 애플리케이션 코드에서 Fluent Bit 로그 라우터로 직접 로그를 보낼 수 있습니다. 이 방식은 Docker 로깅 드라이버 레이어를 우회하며 다음과 같은 이점을 제공합니다:

다음 Fluent 로거 라이브러리는 Fluent Forward 프로토콜을 지원하며 Fluent Bit(으)로 로그를 직접 보내는 데 사용할 수 있습니다.

Docker 버퍼 제한 구성

태스크 정의를 생성할 때 log-driver-buffer-limit에 값을 지정하여 메모리에 버퍼링되는 로그 라인의 수를 지정할 수 있습니다. 이는 Docker와 Fluent Bit 사이의 버퍼를 제어합니다. 자세한 정보는 Docker 설명서의 Fluentd logging driver(Fluentd 로깅 드라이버)를 참조하세요.

Docker에서 버퍼 메모리가 부족하여 새 메시지를 추가할 수 있도록 버퍼 메시지를 삭제할 수 있으므로 처리량이 많을 때 이 옵션을 사용합니다.

이 옵션을 사용할 때 다음 사항을 고려하세요:

다음 태스크 정의는 log-driver-buffer-limit을(를) 구성하는 방법을 보여줍니다.

{
    "containerDefinitions": [
        {
            "name": "my_service_log_router",
            "image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
            "cpu": 0,
            "memoryReservation": 51,
            "essential": true,
            "firelensConfiguration": {
                "type": "fluentbit"
            }
        },
        {
            "essential": true,
            "image": "public.ecr.aws/docker/library/httpd:latest",
            "name": "app",
            "logConfiguration": {
                "logDriver": "awsfirelens",
                "options": {
                    "Name": "firehose",
                    "region": "us-west-2",
                    "delivery_stream": "my-stream",
                    "log-driver-buffer-limit": "52428800"
                }
            },
            "dependsOn": [
                {
                    "containerName": "my_service_log_router",
                    "condition": "START"
                }
            ],
            "memoryReservation": 100
        }
    ]
}