k-masatany.com

2019. 12. 14

ECS 再入門 vol.4 ECS とログ

この記事は Fusic その 2 Advent Calendar 2019 14 日目の記事です。

はじめに

前回は、ECS でオートスケールを組んだ際に気になる共有ストレージについて書きました。

今回は、アプリケーションを運用していくにあたり必要になる、ログの取り扱い について書きたいと思います。

ECS におけるログ出力

ECSはつまるところDockerコンテナなので、スケールやデプロイのたびに、破棄と生成が行われます。

前回説明した通り、永続ボリュームを用意しなければ、コンテナ内で生成した各種ファイルはデプロイのたびに破棄されてしまいます。

そのため、ECSコンテナ内で生成されるログも、永続ボリューム等の非揮発性のストレージに保持をする必要があります。

今回は大きく分けて3つの方法を紹介したいと思います。

awslogs ログドライバーを使用して、CloudWatchLogsに集約する

メリット

  • AWSが提供しているフルマネージドな機能
  • DloudWatchLogGroup を作成して、タスク定義に設定を追加するだけという手軽さ
  • アプリケーション側でも、標準出力にログを吐き出すだけ
  • CloudWatchLogGroup の設定で、ログの保持期間が簡単に設定可能
  • Elasticsearch と連携も簡単にできる

デメリット

  • 素のCloudWatchLogsだけでは、内容を確認するのにかなり手間がかかる
  • ログが1行ずつ出力されるので、情報を追い辛い。
  • 上記の問題があるので、ログの内容を精査してアラートを投げるような処理が難しい
  • コストが割高（？）

細かい使用法については、公式サイト の手順を確認していただくとして、ざっくりと説明すると、

  1. CloudWatchLogGroup を作成する
  2. タスク定義に logConfiguration パラメータを追加する

の2つの作業で終わりです。

超お手軽なので、私は特別な理由がなければこちらの方法を利用しています。

コストが割高との声をよく聞きますが、自前のログ集約機構をメンテナンスしたりするコストを考えると、意外とトータルのコストはそこまで安くならないのでは？と思ったりしています。

ランニングコストを固定化したい等の要件がある場合は、自前のクラスタを組んでしまう方が良いでしょうね。

その他のログドライバを使用してログを集約・解析する

awslogs ドライバの他にも、下記の通りかなりの量のログドライバが存在しています。

  • fluentd
  • gelf
  • journald
  • json-file
  • logentries
  • splunk
  • sumologic
  • syslog

１つ１つ説明はしませんが、例えば fluentdログドライバであれば、fluentdのクラスタ等を自前で用意して、そこへアプリケーションログを送信して、煮るなり焼くなりするような流れになります。

公式ドキュメントをみると、一部のログドライバは Fargate では使用できないようなので、注意が必要でしょう。

FireLens を使用してログを集約する

こちらは利用したことがないので、公式ドキュメント を要約した結果のみ記載しておきます。

FireLens は ECS/Fargateタスクのログ出力先をカスタマイズ(ルーティング) できる機能です。

  • 出力先を用意する（CloudWatchLogGroupや Amazon Kinesis Data Firehose + S3バケット）。
  • Fluentd または Fluent Bit コンテナをタスク定義に追加
  • 利用するFluentd または Fluent BitイメージはAWSが提供しているものを使用しても良いし、自前で用意したイメージを使用してもよい（AWSが提供しているものは、Fluent Bit から AWS の関連サービスに連携するプラグインを追加したもののようです）。
  • ログを出力するコンテナの logConfiguration パラメータの logDriver オプションを awsfirelensに設定し、出力先（CloudWatchLogGroup or Amazon Kinesis Data Firehose）を設定。

実際に構築したことがないので、実情がどうかは不明ですが、こうして項目を書き出してみると、割と簡単に使うことができそうです。

まとめ

今回はECSを使うに際して必要になるログ集約機構について簡単に説明しました。

  • 何か起きたときのためにログを保持しておきたいだけであれば awslogs ログドライバを使用する。
  • 独自の処理や、リアルタイムなアラート等が必要で、多少の運用コスト増を許容できる場合はその他のログドライバを使用して、ログの集約・解析用の基盤を自前で構築する、。
  • awslogs ほど簡略化すると問題があるが、運用コストは抑えたい場合は awsfirelens ドライバを使用して Amazon Kinesis Data Firehose に投げて処理を行う。

といった使い分けが良さそうですね。