高スループットの 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 ドキュメントの「チャンク」および Fluent Bit リポジトリ例の AWS の「チャンクとは」を参照してください。

メモリバッファリング (デフォルト)

デフォルトでは、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 ドキュメントの「バッファリングとメモリ」および Fluent Bit リポジトリ例の AWS の「メモリバッファリングのみ」を参照してください。

ファイルシステムのバッファリング

高スループットのシナリオでは、ファイルシステムのバッファリングを使用することをお勧めします。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 ドキュメントの「ファイルシステムのバッファリング」および Fluent Bit リポジトリ例の AWS の「ファイルシステムとメモリのバッファリング」を参照してください。

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)

次の表は、一般的なログレートと復旧ウィンドウの計算例を示しています。

ピークスループットを観察し、適切なバッファサイズを選択するには、メジャースループット FireLens サンプルを使用します。

式、計算例、ベンチマークを使用して、停止中のベストエフォートリカバリのためのランウェイを提供する適切な storage.total_limit_size を選択します。

Amazon ECS タスクストレージの要件

OUTPUT セクション全体のすべての storage.total_limit_size 値を合計し、オーバーヘッドのバッファを追加します。この合計により、Amazon ECS タスク定義に必要なストレージスペースが決まります。例えば、3 つの出力 × 各 10 GB = 30 GB + バッファ (5～10 GB) = 合計 35～40 GB が必要です。合計が使用可能なストレージを超える場合、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 と調整する必要があります。SIGKILL を受信する前に Fluent Bit がフラッシュを完了できるように、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 を設定するのに役立ちます。

レコードは 2 つの方法で失われます: ストレージがいっぱいになると最も古いレコードがドロップされる、またはシステムがより多くのデータを受け入れることができないと最新のレコードが拒否される。

最も古いレコードがドロップされた

最も古いバッファされたレコードは、再試行回数を使い切ったとき、または 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 入力プラグインでファイルベースのログを使用する

ログ損失が重大な懸念事項となる高スループットのシナリオでは、別の方法として、アプリケーションがディスク上のファイルにログを書き込み、tail 入力プラグインを使用してそれらを読み取るように Fluent Bit を設定します。このアプローチは、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」を参照してください。ベストプラクティスについては、「Fluent Bit トラブルシューティングガイド」の AWS の「ベストプラクティスを使用した Tail 設定」を参照してください。

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 ロギングドライバー」を参照してください。

このオプションは、スループットが高いために 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
        }
    ]
}