みなさんこんにちは。マネージドサービス課の塩野です。
Amazon ECS（Elastic Container Service）でコンテナアプリケーションを構築しようとした際に、ログをどのように収集・管理するかという問題に直面します。アプリケーションの動作確認やトラブルシューティングには欠かせないログですが、ECSでは複数の送信方法が用意されており、どれを選べばよいか迷ってしまうことも多いでしょう。
この記事では、Amazon ECSからログを送信する代表的な2つのパターン、awslogsとFireLensについて、それぞれの特徴や違いを整理してみました。それぞれのパターンの仕組みや適用ケースにフォーカスしてみたので、設定の際の参考にしていただければと思います。
Amazon ECSにおけるログドライバの基本
Amazon ECSでコンテナのログを扱う際、重要になるのが「ログドライバ」という概念です。ログドライバは、コンテナが標準出力（stdout）や標準エラー出力（stderr）に出力したログをどこに送るかを決定する仕組みで、タスク定義の中で指定します。
ECSがサポートするログドライバは起動タイプによって異なっており、例えばFargate起動タイプですとawslogs、splunk、awsfirelensの3つを利用することができます。EC2起動タイプではこれらに加えて、fluentd、gelf、json-file、journald、syslogといったログドライバを使うことができます。
本記事では、最も一般的に使用されるawslogsとawsfirelensの2つに絞って、それぞれの特徴を見ていきましょう。
awslogs - シンプルな選択肢
仕組みと特徴
awslogsは、CloudWatch Logs専用のログドライバです。Dockerデーモンが直接CloudWatch LogsのAPIを呼び出してログを送信するため、追加のコンテナを起動する必要がありません。タスク定義にログ設定を数行追加するだけで動作するという手軽さが最大の特徴といえます。
ログの流れは非常にシンプルで、アプリケーションコンテナが出力したログがDockerログドライバを経由し、そのままCloudWatch Logsへ送信されます。中間にログルーターのような仕組みを挟まないため、設定も動作もわかりやすいでしょう。
メリット
awslogsを選択する最大のメリットは、その設定の簡単さです。タスク定義でCloudWatch Logsのロググループ名やリージョンを指定するだけで、すぐにログの収集が始まります。追加のコンテナが不要なので、タスクのリソース消費も最小限に抑えられます。
また、AWS標準のサービスだけで完結するため、新たに学習すべき技術が少なく、すぐに使い始められる点も魅力です。CloudWatch Logsとの親和性も高く、ログの確認やフィルタリングもAWSコンソールから直感的に行えます。
デメリット
一方で、awslogsには送信先がCloudWatch Logsに限定されるという制約があります。ログドライバ側でログを加工したり、フィルタリングしたりする機能もないため、出力されたログがそのままCloudWatch Logsに送信されます。
また、複数の送信先に同時にログを送りたい場合やサードパーティのログ管理サービスを使いたい場合には、awslogsでは対応できません。こうした柔軟性が必要な場合は、次に紹介するFireLensを検討する必要があります。
こんな場合に最適
awslogsは、CloudWatch Logsだけでログ管理が完結する場合に最適です。小規模から中規模のアプリケーションで、とにかく早くログ収集を始めたいというケースでは、awslogsの手軽さが活きてきます。
AWS内でシステムを完結させたい、追加の学習コストをかけたくない、シンプルな構成を維持したいといった要件がある場合も、awslogsは良い選択肢になるでしょう。
FireLens - 柔軟な選択肢
仕組みと特徴
FireLensは、サイドカーコンテナとしてFluent BitまたはFluentdを使用し、柔軟なログルーティングを実現する方法です。アプリケーションコンテナのログは、まずFireLensコンテナに送られ、そこから様々な送信先にルーティングされます。
この仕組みの面白い点は、アプリケーションコンテナ自体には何も手を加える必要がないことです。ログルーティングのロジックはすべてFireLensコンテナ内で処理されるため、アプリケーションコードを変更することなく、ログの送信先や処理方法を変更できます。
メリット
FireLensの最大の強みは、その柔軟性にあります。CloudWatch Logsはもちろん、Kinesis Data Firehose、サードパーティのログ管理サービスなど、幅広い送信先に対応できます。しかも、複数の送信先に同時にログを送ることも可能です。また、Fluent Bitの機能を活用することで、ログの加工やフィルタリングも行えます。例えば、特定のログレベルだけをフィルタリングしたりといった処理をインフラ層で完結できます。
将来的にログの要件が変わった場合でも、FireLensを使っていれば柔軟に対応できるので、最初はCloudWatch Logsだけに送っていたログを後からサードパーティサービスにも送るといった変更があっても、比較的容易に対応できるようになると思います。
デメリット
FireLensを使用する場合はログ取得部分がサイドカーコンテナとなるため、タスク全体のリソース消費は増加します。また、設定はawslogsと比べてやや複雑になることやFluent Bitの基本的な知識が必要になる点も考慮すべきかもしれません。トラブルシューティングの際には、アプリケーションコンテナだけでなくFireLensコンテナのログも必要に応じて確認する必要があるでしょう。この複雑さは小規模なプロジェクトではオーバーヘッドになる可能性があるかもしれません。
セキュリティ面ではFireLensがポート24224をリッスンする点に注意が必要で、セキュリティグループで、VPC外部からのこのポートへのインバウンドトラフィックをブロックし、意図しないアクセスを防ぐことが重要です（Fargate内のコンテナ間通信はlocalhostで行われるため影響しません）。
送信方法のパターン
FireLensから他の宛先にログを送信する方法として、主に3つのパターンがあります。
1つ目は、Kinesis Data Firehose経由での送信です。FireLensからFirehoseにログを送り、Firehoseがバッファリングやリトライを担当しながら最終的な送信先へ配信します。AWSマネージドサービスの信頼性を活かせる方法で、大量のログを安定的に送信したい場合に適しています。
2つ目は、HTTPプラグインなどを使った直接送信です。FireLensから送信先のAPIへ直接ログを送る方法で、Firehoseを経由しない分、構成がシンプルになってレイテンシも低く抑えられます。コストを抑えたい場合やリアルタイム性が重要な場合に有効です。
3つ目は、FireLensを使ってCloudWatch Logsに送る方法です。awslogsと同じ送信先ですが、FireLensを経由することでログの加工やフィルタリングが可能になります。複数の送信先の1つとしてCloudWatch Logsを使う場合にもこの方法が活用できますし、ヘルスチェックのアクセスログやDEBUGログ）などの不要なログをFireLens側で除外（Drop）してから送信することで、CloudWatch Logsの取り込み料金や保存料金を削減することができます。
使用するイメージ
FireLensコンテナに使用するイメージとしては、AWSが提供する「AWS for Fluent Bit」が一般的です。このイメージには、CloudWatch Logs、Kinesis Data Streams、Kinesis Data Firehose用のプラグインがプリインストールされています。その他、New RelicなどのSaaSでは自社サービスへのルーティングを含めた独自のイメージを配布しているようなパターンもあります。
こんな場合に最適
FireLensは、サードパーティのログ管理サービスを使いたい場合に最適です。複数の送信先に同時にログを送りたい、ログの加工やフィルタリングが必要、といった要件がある場合も、FireLensの柔軟性が活きてきます。
本番環境での長期運用を考えている場合や、将来的な拡張性を確保しておきたい場合にも、FireLensを選択する価値があります。初期の学習コストは多少かかりますが、運用が安定すればその柔軟性が大きなメリットになると思います。
2つのパターンの比較
ここまで説明してきた2つのパターンを表にまとめると、以下のようになります。
| 項目 | awslogs | awsfirelens |
|---|---|---|
| 送信先 | CloudWatch Logsのみ | CloudWatch Logs、Firehose、サードパーティなど多数 |
| 設定の複雑さ | シンプル | やや複雑 |
| 柔軟性 | 限定的 | 非常に高い |
| 追加コンテナ | 不要 | 必要（サイドカー） |
| リソース消費 | 最小限 | サイドカー分追加 |
| ログ加工 | 不可 | 可能 |
| 複数送信先 | 不可 | 可能 |
| 学習コスト | 低い | 中程度 |
選択の判断基準としては、まず送信先がCloudWatch Logsだけで十分かどうかを考えてみるとよいでしょう。もしCloudWatch Logsだけで問題なくてログの加工も不要であれば、awslogsのシンプルさが魅力的です。
一方、New Relicなどのサードパーティサービスを使いたいという要件や、複数の送信先が必要だったり、ログの加工やフィルタリングが必要といった要件が1つでもあれば、FireLensを検討する価値があります。将来的な拡張性を重視する場合も、FireLensの方が安心かもしれません。
まとめ
ECSからログを送信する方法として、awslogsとFireLensという2つの選択肢を見てきました。awslogsはシンプルで手軽に使える反面、CloudWatch Logsへの送信に限定されます。FireLensは設定がやや複雑になるものの、柔軟なログルーティングが可能で、将来的な拡張性も高いといえます。
どちらを選ぶかは要件次第と思いますが、AWS内で完結できる小規模な案件では簡単に導入できるawslogsが適していますし、ログフィルタを色々書きたいといったような複雑な要件がある場合はFireLensの方が向いていると思います。とりあえず迷ったらawslogsで始めて、もう少し色々やりたいという要件が出てきたらFireLensに移行してみてはいかがでしょうか。コンテナなのでアプリケーション側の改修はせずにタスク定義やAWSの権限周りの設定調整などで簡単に切り替えができるのも、コンテナ運用のメリットだと思います。
この記事がどなたかのお役に立てれば幸いです。
宣伝
弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのお問合せフォームよりお問合せ頂けましたら幸いでございます。
◆ 塩野 正人
◆ マネージドサービス部 所属
◆ X（Twitter）：@shioccii
◆ 過去記事はこちら
前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。
