tjinjin's blog

インフラ要素多めの個人メモ

ECSのログパターンについて考えている〜ログを送るところまで

AWS log

概要

いくつかパターンと懸念があるので考えた。メモ書きレベル。

考慮事項

  • ログの欠損を最小限にしたい。可能な限り拾いたい
    • fluentdのメモリ内のログが欠損するのは許容（どうにもならない）
    • それ以外のログの欠損を防ぐ

考慮点

  1. fluentdを使うかどうか
  2. ログを一度ファイルにするか

awslogs driver -> CWLogs

  • コンテナのログをCWlogsに送る
  • もろもろの考慮が不要なため初期は一番楽だと思われる
  • とにかく料金がネックになる
  • S3に送るにもCWLogsを一度経由する必要があり大変
  • CWLogsのRatelimit引っかかったことはないがどうか？log streamを分ければある程度スケールするかも。

fluentdパターン

  • 柔軟にログを送ることができる
  • fluentd -> kinesis -> kinesis firestream -> ElasticSearch Serviceなどの構成にできればログが増えてもある程度スケールしそう（ただし、kinesisの料金が高くなりがちなので注意が必要）
  • fluentdを採用する場合にいくつかのパターンが考えられる。

Json-file driver + fluentd forwarder process （every host machine）

  • k8sやdatadog-agentと似たような方式、一度ファイルに書き込む
  • hostマシンにfluentd（td-agent）のプロセスを立ち上げる
    • コンテナのライフサイクルと分離できる
    • コンテナインスタンスがdrainingされたときもprocessは生き続けるので、ログが欠損しにくい
  • fluentd が死んだ場合の再起動などについての考慮が必要
  • fluentdの設定変更に考慮が必要
  • インスタンス終了時にdrainigするだけでいいので気楽
  • スケールしやすい

Json-file driver + fluentd forwarder container

  • k8sやdatadog-agentと似たような方式、一度ファイルに書き込む
  • daemonSetを使ってfluentdを書くホストに起動させる
    • 設定の入れ替えが楽
    • コンテナインスタンスがdrainingされたときにfluentdコンテナも死ぬ。このときにログが欠損する可能性がある。
      • k8sだと--ignore-daemonsetというオプションで除外できるが…
  • スケールしやすい

fluentd driver -> nlb + fargate fluentd

  • fargateで別Serviceを立ち上げる
  • インスタンス入れ替え時の考慮が不要
  • スケールしやすい
  • docker -> nlb -> fluentd間でkeepaliveを貼りそうなので相性はよさそう？
  • fargate が死んだらその分ログが欠損する
    • EFSを利用することで防げるかもしれない？
    • 安定すればそれほど懸念することではないかも
    • 一旦受ける用fluentdがlogに書き込み。tail君を別で立ち上げる？
  • hostのログを取れない
    • cloudwatch-agentでいいんでは？
  • ログが分割されている場合、他のfargeteタスクにログが送られてしまうと復旧できない？（16KBの制限）
    • fluentd側の処理でコンテナIDとかを見ればできるか検証したい
  • fargate使うとしたときのfluentdの監視はどうする？

fluentd driver -> fluentd（sidecar）

  • fluentdをsidecarとして立ち上げる。
  • アプリケーションと1:1にできるのでコンテナライフサイクル管理が楽
  • リソース管理が難しい。

まとめ

fargateパターンが良さそうな気がしているので試したい