詳解 FireLens – Amazon ECS タスクで高度なログルーティングを実現する機能を深く知る

この記事は Under the hood: FireLens for Amazon ECS Task (記事公開日: 2019 年 11 月 18 日) を翻訳したものです。

2019 年 11 月、Amazon ECS は FireLens によるカスタムログルーティングのサポートを発表しました。FireLens によって、人気の高いオープンソースのロギングプロジェクトである Fluentd や Fluent Bit を簡単に使用することができ、さまざまな AWS サービスやパートナーの宛先にログを送信することができます。

この記事では、私たちがなぜ、どのようにして FireLens を作ったのか、詳しく説明します。また、私が FireLens を使用した結果を共有し、FireLens を設定するための推奨事項を紹介します。この記事では、FireLens、Fluent Bit や Fluentd について深く掘り下げます。Fluentd や Fluent Bit に馴染みのない方は、読み進める前に、Fluentd や Fluent Bit と FireLens のドキュメントをよく理解しておくことをお勧めします。

この記事のカバー範囲

• なぜ FireLens を開発したのか
• FireLens はどのように機能するのか
• FireLens を使用した私の経験 – 信頼性と推奨事項

AWS では、新機能はお客様との会話から生まれます。お客様は、公開されている Containers Roadmap で Issue を作成し、コメントすることで、このプロセスに参加することができます。アプリケーションロギングについていただいたフィードバックは、以下の要件にまとめられました。

1. ログの宛先としてさまざまな AWS サービスをサポート。CloudWatch Logs、Amazon Elasticsearch Service、Amazon S3 と Amazon Athena など、AWS はアプリケーションログを保存および検索できる複数のサービスを提供します。
2. タスク定義以外の追加設定は不要。ロギングエージェントのインストール、設定、トラブルシューティングについて心配したい人はいません。自分のユースケースを見つけるためにドキュメントをしらみつぶしに調べたい人もいません。理想的なソリューションは、単に一般的なユースケースのためのサンプルのセットを持っていて、それをそのまま使うことができます。
3. 拡張性のためのオープンソースの使用。もしユースケースがサポートされていなければ、Fluentd や Fluent Bit に変更やプラグインをコントリビュートしてください。AWS を巻き込む必要はありません ?
4. ログへの ECS メタデータの付与。ログメッセージを作成した AWS リソースを識別できるべきです。
5. ログソリューションのパフォーマンスに関する可観測性。Fluentd または Fluent Bit コンテナのロギングを有効にし、リソースの使用状況を検査し、ログ配信メトリクスを取得することができます。これは、Docker Daemon の中に “隠されている” Docker ログドライバーとは対照的です。
6. パートナーとの容易な統合。FireLens のパブリックプレビューが発表されてから、多くのパートナーが Fluentd や Fluent Bit のサポートを追加しています。FireLens がオープンソースでの新しいコントリビューションを促進していることを嬉しく思います。

これらのユースケースから、Fluentd と Fluent Bit をベースにしたソリューションを構築する必要があることは明らかでした。Fluent Bit が AWS の推奨ですが、それは Fluentd に比べてリソース使用量が大幅に少ないからです。Fluentd も何百ものプラグインが存在する定評のあるツールであり、サポートします。長期的には、FireLens がオープンソースコミュニティを活性化し、Fluentd がサポートする多くの機能とすべての送信先が Fluent Bit に追加されることを期待しています。AWS は Fluent Bit にプラグインや改善を提供し続けることで、この役割を果たしていきます。

なぜ単に Fluentd や Fluent Bit を推奨しないのですか？なぜ FireLens なのですか？

Fluentd と Fluent Bit は強力ですが、たくさんの機能セットには常に複雑さが伴います。FireLens を設計する際、2 つの主要なユーザーセグメントを想定しました。

1. Fluentd と FluentBit を使用して、ログをどこにでも簡単に送信する方法を必要としているユーザー。
2. Fluentd と FluentBit のフルパワーを必要としており、タスクのログをこれらのログルーターにパイプするために必要な差別化につながらない重労働は AWS に管理して欲しいユーザー。

最初のグループに対する私たちの答えは、私たちが作成した FireLens サンプルの GitHub リポジトリによって最もよく実証されています。これらの例のほとんどは、タスク定義での設定のみを必要とし、誰でもわずかな変更だけで使用することができます。簡単であり、Fluentd や Fluent Bit の知識を必要としません。

2 番目のグループに対する私たちのソリューションは、タスク定義の FireLensConfiguration オブジェクトの options フィールドに示されています。

"firelensConfiguration": {
    "type": "fluentbit"
    "options": {
        "config-file-type": "s3",
        "config-file-value": "arn:aws:s3:::mybucket/fluent.conf"
    }
}

高度なユースケースに対応するために、Fluentd または Fluent Bit の設定ファイル全体を S3 から取得することができます (訳注: EC2 起動タイプの場合)。この設定ファイルは、ECS が生成する設定からインクルードされます。これについては次のセクションで詳しく説明します。

設定ファイルを S3 に保存することで、更新が容易になります。個人的には、設定をテストする際にこれが非常に便利でした。FireLens を導入する前は、設定ファイルを Fluentd や Fluent Bit のイメージに含めていましたが、設定を変更する必要がある場合は、イメージを再ビルドし、Amazon ECR に再プッシュしなければなりませんでした。FireLens を使えば、ファイルを編集して S3 に再アップロードするだけで、タスクの起動時に自動的に新しい設定を取り込むことができます。

他のログルーティングプロジェクトをサポートしますか？

FireLens をきっかけに、オープンソースコミュニティがより多くのプラグインをコントリビュートし、Fluentd と Fluent Bit を改善してくれることを期待しています。これらのプロジェクトの標準化によって、コミュニティの努力を集中させることができます。機能が多くのプロジェクトに分散してしまうのは理想的ではありません。とはいえ、FireLens のインターフェイスは最小限であり、他のプロジェクトがサポートされる可能性はあります。もし、他のオープンソースのロギングプロジェクトが主流になり、お客様からの要望が多ければ、それをサポートしていきます。

FireLens はどのように機能するのか

FireLens は Docker のログドライバーですか？

"logConfiguration": {
    "logDriver": "awsfirelens",
    "options": {
        "Name": "firehose",
        "region": "us-west-2",
        "delivery_stream": "my-stream"
    }
}

いいえ。awsfirelens ログドライバーは、タスク定義用のシンタックスシュガーであり、Fluentd または FluentBit のアウトプットプラグインの設定を指定できます。

FireLens の内部構造

上の図は、FireLens がどのように機能するかを示しています。コンテナの標準出力ログは、Fluentd Docker ログドライバーを介して Unix ソケット経由で FireLens コンテナに送信されます。このドライバーは TCP と Unix の両方のソケットをサポートしていますが、 より高速でパフォーマンスの高いオプションである Unix ソケットを選択しました。さらに、FireLens コンテナは、Fluentd Forward Protocol メッセージを TCP ソケットでリッスンします。これにより、Fluent Logger ライブラリを使用して、アプリケーションコードからログにタグを付けて送信することができます。

Fluent 設定の生成

ECS エージェントは、FireLens を使用するタスクを起動すると、以下の部分からなる Fluent 設定ファイルを構築します。

1. ログソース。ログソースは前述の Unix および TCP ソケットです。
2. ECS メタデータを追加するトランスフォーマー。オプトアウトしない限り、record_transformer プラグインを使用して、すべてのログオブジェクトにメタデータを追加します。
3. オプションのユーザー提供の設定。ユーザーが独自の設定ファイルを指定した場合、include ディレクティブを使用して、生成された設定ファイルにインポートします。
4. タスク定義から生成されたログ保管先。awsfirelens という疑似ドライバーで指定した設定オプションは、Fluentd または Fluent Bit のアウトプットプラグインの設定に変換されます。

この設定ファイルは、AWS の Golang Fluent Config Generation Project を使用して生成されます。この生成された設定ファイルは、FireLens を使用する EC2 起動タイプの ECS タスクを起動した後に見ることができます。設定ファイルは、ホスト上の環境変数 ECS_HOST_DATA_DIR の値で指定されたパスに保存されます。デフォルトでは、この変数は /var/lib/ecs に設定されています。

タスク用に生成された設定ファイルは、EC2 インスタンス上の次のパスにあります。

/var/lib/ecs/data/firelens/{タスク ID}/config

FireLens の Fluentd と Fluent Bit の設定とタスク定義のサンプルはこちらからご覧いただけます。(訳注: Fluent Bit コンテナに対するヘルスチェックについてはこちらのガイダンスも参照してください。)

生成された設定ファイルは、ログルーターコンテナの以下のパスにマウントされます。

• Fluentd: /fluentd/etc/fluent.conf
• Fluent Bit: /fluent-bit/etc/fluent-bit.conf

これらは、公式の Fluentd および Fluent Bit イメージが使用するデフォルトの設定ファイルのパスです。これらのデフォルトパスを使用していれば、どのような Fluentd や Fluent Bit コンテナイメージでも FireLens で使用することができます。

設定順序の反映仕様 – Fluent Bit を使う理由の 1 つ

Fluent Bit 内部のログ処理パイプライン

上の図は、Fluent Bit 内部のログ処理パイプラインを示しています。設定ファイル内のセクションの順序にかかわらず、この順序は常に強制されます。これは、FireLens ユーザーにとって非常に便利です。すなわち、オプションのユーザー提供の設定ファイルに、ログソース、フィルター、およびアウトプットを追加できることを意味しています。

先ほどの設定ファイルの順序を思い出してください。

1. ログソース。
2. ECS メタデータを追加するためのトランスフォーマー。
3. オプションのユーザー提供の設定。
4. タスク定義から生成されたログ保管先。

ユーザー提供の Fluent Bit 設定ファイルにログソースが含まれていれば、ソースが ECS メタデータトランスフォーマーの後に来ていても、取り込んだログには ECS メタデータが追加されます。また、ログを複数の宛先に簡単に送ることができることも意味します。これらの複数のアウトプットをタスク定義とオプションの設定に分けて定義することもできます。1 つはタスク定義の logConfiguration セクションから、他はユーザー提供の設定に存在できます。これを示す例をここに作成しました。

上記はいずれも Fluentd では不可能です。ログメッセージは設定ファイルのセクションの登場順に処理され、タグにマッチする最初のアウトプットに送信されます。

生成された設定ファイルでのログのタグ付け

Fluentd と Fluent Bit はタグを介してログイベントをルーティングします。各ログメッセージにはタグがあり、各設定セクションには、どのタグに対して適用するかを決定するパターンが含まれています。例にあるように、ECS メタデータを追加する record_modifier は、Fluent Bit では *、Fluentd では ** にマッチします。つまり、すべてのログに ECS メタデータが追加されることになります (ただし、前のセクションで指摘したように、Fluentd ではすべてのイベントがこのセクションを “通過する” わけではないことに注意点してください) 。なぜ ** が必要なのかについては、Fluentd のドキュメントを参照してください。

タスク定義から生成されるログアウトプットは、<コンテナ名>-firelens* と <コンテナ名>-firelens** にマッチします。つまり、Fluent Bit を使用していて、コンテナ名が app の場合、マッチパターンは app-firelens* となります。

コンテナの標準出力ログは、<コンテナ名>-firelens-<タスク ID> というタグが付けられています。つまり、コンテナ名が app で、タスク ID が dcef9dee-d960-4af8-a206-46c31a7f1e67 の場合、タグは app-firelens-dcef9dee-d960-4af8-a206-46c31a7f1e67 となります。

Fluentd と Fluent Bit の CloudWatch Logs プラグインは、どちらもログのタグを基にした名前のログストリームを自動作成することができます。これにより、ログが発生したコンテナやタスクに応じた名前のログストリームを作成することができます。

この情報を使って、クールなことをやってみましょう。FireLens のドキュメントから、ECS が環境変数 FLUENT_HOST と FLUENT_PORT を注入することを思い出してください (bridge または awsvpc ネットワークモードを使用する場合) 。これにより、ログルーターがリッスンしている TCP ポートへの接続が可能です。

FireLens の CloudWatch Logs のタスク定義の例を、次の logConfiguration で使用します。

             "logConfiguration": {
                 "logDriver":"awsfirelens",
                 "options": {
                    "Name": "cloudwatch",
                    "region": "us-west-2",
                    "log_group_name": "firelens-blog",
                    "auto_create_group": "true",
                    "log_stream_prefix": "from-fluent-bit"
                }
            }

アプリケーションコードでは Fluent Logger ライブラリを使用できます。Python Logger ライブラリのコード例を以下に示します。

from fluent import sender
# FireLens ログルーターに接続
# コンテナ名は 'app'
logger = sender.FluentSender('app-firelens', host=os.environ['FLUENT_HOST'], port=int(os.environ['FLUENT_PORT']))

# app-firelens.debug タグでデバッグメッセージを送信
logger.emit('debug', {'log': 'debug info'})

# app-firelens.error タグでエラーメッセージを送信
logger.emit('error', {'log': 'Error: Something went wrong'})

ロググループ firelens-blog では、デバッグメッセージとエラーメッセージにそれぞれ異なるタグが付けられているため、別々のログストリームが得られます。

FireLens を使用した私の経験: 信頼性と推奨事項

FireLens と AWS Fluent Bit Plugins の開発中、ログを宛先に確実に配信でき、ログの損失を引き起こす可能性のあるシナリオに耐えられることをテストしたいと考えました。また、さまざまな負荷状況で、AWS プラグインを搭載した Fluent Bit のリソース使用状況を理解することにも興味がありました。この目的のために、私はいくつかの実験を行いました。

これから紹介する結果は保証を表すものでないことをご了承ください。あなたの場合の結果は異なるかもしれません。FireLens と Fluent Bit ユーザーの経験の 1 つとして共有させてください。

信頼性

信頼性は、あらゆるロギングソリューションにとって重要です。権限やネットワークの設定ミス、転送先サービスの可用性の低下など、ログ損失につながる可能性のあるさまざまな状況があります。FireLens では、ログ損失の最も一般的な原因は、タスクの終了でしょう。タスクが終了すると、FireLens のサイドカーコンテナが停止し、未送信のログは永遠に失われます。これは、Fluentd や Fluent Bit に永続的なファイルバッファを設定することで軽減できますが、Fargate ではこのオプションは利用できず (永続ストレージがないため) 、タスク終了後に未送信のファイルバッファからログを収集するという面倒なプロセスが必要になります。(訳注: 現在は Fargate は EFS ファイルシステムをサポートしていますが、ワークロードとそのログ出力ボリュームによっては望ましい読み書きの速度が実現できない可能性もあるため、注意が必要です。)

理想的には、ロギングサイドカーが終了するまでに、すべてのログが送信されるべきです。これをテストするために、予測可能なイベントをログに記録するフェイクアプリケーションを作成し、後でログ送信先でカウントできるようにしました。このロガーは、設定可能な 1 秒あたりのレートで、1 分間ログを発行します。その後、すぐに終了します。

テストの結果を分析する前に、タスクのシャットダウン時に何が起こるかを理解する必要があります。ECS は、Container Dependency 機能でオーバーライドされない限り、FireLens コンテナが最初に起動し、最後に停止することを保証します。(より正確には、FireLens コンテナは awsfirelens ログドライバーを使用する全てのコンテナのよりも前に開始し、awsfirelens ログドライバーを使用する全てのコンテナのよりも後に停止します。)

そのため、私のログ損失テストでは、アプリのコンテナが最初に終了しました。このコンテナの essential パラメータは true であるため、これはタスク終了のトリガーとなります。次に ECS エージェントは、Fluent Bit/FireLens コンテナに SIGTERM を送り、クリーンアップとシャットダウンの準備をするように通知します。そしてその 30 秒後に、SIGKILL を送りコンテナを強制的に停止させます。(この 30 秒のタイムアウトは “grace period” と呼ばれ、EC2 起動タイプでは変更可能です。訳注: EC2/Fargate 起動タイプのいずれでも、タスク定義の stopTimeout パラメータで変更可能です。)

しかし、このテストを行っているうちに、Fluent Bit はデフォルトでは SIGTERM を受け取ってから 5 秒しか待機せずにシャットダウンしていることがわかりました。つまり、許容されている 30 秒をフルに使っていないことになります。また、デフォルトでは、Fluent Bit は 5 秒ごとにログをアウトプットプラグインにフラッシュしようとすることもわかりました。このフラッシュのたびに、AWS プラグインは複数の API コールを行います。しかし、この間隔を短くすることでスループットを向上させることができます。

これらの設定は両方とも、Fluent Bit の設定ファイルの Service セクションで変更することができます。Grace は SIGTERM のタイムアウトを設定し、Flush はフラッシュの間隔を設定します。

[SERVICE]
    Flush 1
    Grace 30

私は、Fluent Bit のデフォルト設定と、これらが “最適化された” 設定の両方でテストを行いました。パフォーマンステストに使用したコードはこちらでご覧いただけます。テストは次の条件で行いました。

• タスクは c5.9xlarge の Amazon EC2 インスタンス上で実行されました。
• すべてのタスクで awsvpc ネットワークモードを使用していたため、それぞれが独自の Elastic Network Interface を持っていました。
• アプリケーションコンテナは 1 分間ログを出力した後、終了しました。
• タスクレベルの CPU とメモリの設定を使用し、各タスクには 1 GB のメモリと 0.5 vCPU が割り当てられました。
• テストは Kinesis Data Firehose と CloudWatch Logs を送信先として行いました。Kinesis Data Firehose では、配信ストリームのスループット制限を 30,000 レコード/秒に増やしました (ほとんどのリージョンでデフォルトは 1,000 です) 。なお、ほとんどの FireLens ユーザーは、ログに Kinesis Data Firehose を使用するためには、制限の引き上げをリクエストする必要があることに注意してください。
• ログの発行レートごとに、テストを 5 回を実行しました。

デフォルトの Fluent Bit 設定での FireLens ログ損失テスト

MIN は、合計 5 回のテスト実行のうち、最もパフォーマンスの低いテストケースです。

“最適化された” Fluent Bit 設定での FireLens ログ損失テスト

最適化された設定では、明らかにパフォーマンスが向上しています。結果の違いは、MIN 値で最も顕著です。最適化された設定は、より一貫性のある結果をもたらします。

CloudWatch Logs Fluent Bit プラグインは、どちらのテストシナリオでも Firehose プラグインをごくわずかに上回っています。これはおそらく、CloudWatch Logs の PutLogEvents API がリクエストごとに 10,000 イベントを受け入れるのに対し、Firehose の PutRecordBatch API は 500 イベントしか受け入れないためです。各リクエストには少量のオーバーヘッドが追加されるため、API のバッチサイズが大きいほど、スループットがわずかに高くなるのではないかと思われます。

しかし、全体的に見れば、デフォルトの設定でも非常に良い結果が得られています。多くのアプリケーションでは、最適化された設定の効果を確認できるほどの速度でログを出力することはありません。しかし、ログを高速で出力するアプリケーションの場合は、最適化された設定を使用することをお勧めします。

AWS for Fluent Bit イメージのバージョン 1.3.2 の時点で、イメージ内のパス /fluent-bit/configs/minimize-log-loss.conf に “最適化された” 設定ファイルを含めています。Fluent Bit コンテナのコンテナ定義に以下のセクションを追加することで、FireLens でこの設定ファイルを使用することができます。

"firelensConfiguration": {
    "type": "fluentbit",
    "options": {
        "config-file-type": "file",
        "config-file-value": "/fluent-bit/configs/minimize-log-loss.conf"
    }
}

これらのテスト結果は満足のいくものでしたが、Fluent Bit コンテナのメモリ使用量に興味がありました。すべてのログを送信するために、メモリ使用量が急激に増加してはいないでしょうか？そこで、今回は Fluent Bit コンテナのメモリ使用量に 100 MB というハードリミットを設定し、再びデフォルト設定でテストを行いました。すなわち、メモリ使用量が 100 MB を超えると OOM-Kill され、ログ損失が発生します。

デフォルトの Fluent Bit 設定での FireLens ログ損失テスト – 100 MB のメモリ使用量ハードリミット

結果は、毎秒 7,000 行 のログまでは、Fluent Bit は 100 MB 以下のメモリ消費で AWS の宛先にログを送信できることを示しています。興味深いことに、Firehose プラグインは再び CloudWatch プラグインよりもわずかに悪いパフォーマンスを示しています。この結果は、Firehose プラグインが CloudWatch プラグインよりも OOM-Kill されやすいことを強く示唆しています。これはおそらく、やはり API のバッチサイズが小さいことが原因です。ログの送信速度が遅いため、メモリ内バッファがより早くいっぱいになります。

今後の改善点

これらの結果に基づいて、私は改善のため 2 つの Issue をオープンしました。

• Fluent Bit Kinesis Data Firehose プラグインで複数のログ行を 1 つのレコードとしてバッチ処理する – amazon-kinesis-firehose-for-fluent-bit#12
• FireLens ユーザーがカスタム設定ファイルを指定しない場合、Grace を 30 に設定する – containers-roadmap#579

リソース使用状況

Fluent Bit CloudWatch Logs

Fluent Bit Kinesis Data Firehose

テストは、c5.9xlarge の Amazon EC2 インスタンスで実行されました。

これらのリソース使用量テストの結果は、ブログ記事 Centralized Container Logging with Fluent Bit (訳注: 翻訳記事 Fluent Bit による集中コンテナロギング) ですでに公開されています。FireLens を使用する際には、これらの値を使用して Fargate で必要なタスクサイズを見積もることをお勧めします。また、これらの値は FireLens のコンテナ定義の CPU と memoryReservation フィールドの設定にも使用できます。しかしながら、memory フィールドによるメモリ使用量のハードリミットは設定しないことをお勧めします。Fluent Bit と Fluentd のメモリ使用量は急増する可能性があり、その場合にコンテナが OOM-Kill される原因となるからです。FireLens コンテナは essential である必要があるため、これによりタスクが強制終了されます。ログ損失に関するセクションで示したように、Fluent Bit は 100 MB 以下のメモリ使用量でログを高速に処理することができますが、メモリ使用量のハードリミットは使用しない方が依然としてより安全です。

最後に、私は Fluent Bit を使って Kinesis Data Firehose にログを送信する FireLens タスクを実行しました。メモリ使用量が長期にわたって安定していることを確認するため、このタスクを 2 週間稼働させました。その結果、長期的なメモリリークやその他の問題はなく、長期的に安定していることが確認できました。Fluent Bit は大きなユーザーベースを持つ確立されたツールであり、この結果は予想通りです。

FireLens Fluent Bit の 2 週間にわたるメモリ使用量

まとめ

この記事では、なぜ FireLens を開発したのか、そしてどのように機能するのかをご紹介しました。その仕組みを知った上で、 Fluentd と Fluent Bit のカスタム設定ファイルの書き方のヒントを学びました。最後に、私が行ったリソース使用量とログ損失テストの結果から、ログルーターのリソースのプロビジョニングと信頼性の最適化についてのヒントを学びました。

AWS Containers のお客様のロギング体験を最適化するために、皆様からのフィードバックをお待ちしています。FireLens や Fluent Bit の統合に何を追加すべきでしょうか？ GitHub の aws/container-roadmap と aws/aws-for-fluent-bit リポジトリで Issue をオープンしたり、コメントしたりしてください。AWS はそれらで受け取ったフィードバックを真摯に受け止めています。Issue に寄せられた +1 やコメントの数は、どの機能がお客様にとって最も重要であるかを判断するのに役立ちます。

最後に、AWS re:Invent 2019 が間近に迫っています。 参加される方は、FireLens と Fluent Bit に関する以下のセッションのいずれかにサインアップすることを検討してください。これらのセッションは、私と Fluent Bit の開発者である Eduardo Silva が担当します。

• CON309-R FireLens (訳注: セッション資料)
• CON308-R1 FireLens

(訳注) AWS for Fluent Bit イメージには Amazon Kinesis Data Firehose、Amazon CloudWatch Logs、Amazon Kinesis Data Streams へのアウトプットプラグインが含まれていますが、現時点 (Fluent Bit v1.7) では、Fluent Bit のコア機能でこれら Amazon Kinesis Data Firehose、Amazon CloudWatch Logs、Amazon Kinesis Data Streams へのアウトプットや、Elasticsearch (Amazon Elasticsearch Service を含む) や Amazon S3 へのアウトプットがサポートされており、これらのコア機能を使うことが可能です。

翻訳はプロフェッショナルサービスの杉田が担当しました。原文はこちらです。