ログ収集基盤の（再）設計

はじめに

個人的に考えていることのメモです。真似してやけどしても責任持てません。

データサイエンティストに聞いてわかったデータ分析基盤アーキテクチャの勘所ってのを以前書きましたが、その続きのようなポストです。

おことわり

現在関わっている案件の要件を前提とした設計です。常にこれが正しいとは思えないので、参考程度にどうぞ。

前提（非機能要件的なもの）

• ログは可視化したいし、ビジネスサイドが気軽にそれを参照したい
  • Elasticsearchにつっこんで、kibanaで可視化しておく。
  • それをビジネスサイドに共有しておけば気軽に参照してもらえる（はず）
• 生ログは全件残す
  • つまり、S3に未整形のまま全件をputしておく必要がある
• Elasticsearch Serviceに高いお金は払いたくない（というか払えない）
  • Indexを細かく分けて不要なログは一定期間経過後にローテートすることで容量を落としてコストを削減する
    • syslogとappのindexはわけておいて、syslogは1週間程度残しておく（障害調査用）、appはずっと消さない、とかをやりたい。

思いついたもの

この非機能要件を満たすアーキテクチャで思いついたのは以下の2つです。

fluentd -> S3 + elasticsearch形式

アーキテクチャ

fluentd -> S3 + elasticsearch

ETL

• fluentdでログの仕分けをしてindexにわける
  • pod-{namespace}-{application name}-YYYY.MM.DDあたりのindex名にすればいいんじゃなかろうか
    • istio関係のログはnamespaceで仕分けられるので、culatorでローテートできるようになるはず
    • kube-system関係のログも同上
• syslogの取得を忘れずに
  • syslog-{tag}-YYYY.MM.DDあたりのindex名にすれば良いんじゃなかろうか
  • fluentd-elasticsearchのhelm chartのconfigmaps.yamlが参考になりそう
    • ただ、この例だとsyslog全部は取得しているわけではない（特に/var/log/dmesgがないのが気になる）っぽいけど、それで良いのかはわからない

メリット

• シンプル
• fluentdさえ理解していれば全体像が把握できる

デメリット

• fluentdを理解して、設定ファイルを作り込む必要がある
• ログデータの永続化先が増えたときにfluentdの設定ファイルを更新する必要があり、設定が肥大化＆複雑化していきそう
• バックプレッシャーが効く箇所がfluentdだけのため、ログ欠損の可能性が高いかもしれない。またスケールしないかもしれない。かもしれないだけで、規模が小さければ問題にならないかもしれない。

fluentd -> kinesis形式

アーキテクチャ

fluentd -> kinesis

ETL

• やることはログの中身に応じてindex名を動的に決める
  • つまりfluentd -> S3 + elasticsearch形式と同じことをlambdaで必要がある

メリット

• ログデータの永続化先が増えたとしても、lambdaを拡張していけばいい
  • lambdaから別のlambdaを読んだりできるので、好きなようにできる
• kinesis streamsでバックプレッシャーが効くしスケールするサービスなのでアクセスがいくら増えても捌ける（はず）
  • 今の案件だと将来も含めて大量アクセスされることはまずないけど…

デメリット

• 利用するサービスが増えるので全体像の理解に苦労しそう
• lambdaの箇所でコケると詰まるかも？検証したほうが良い。
• lambdaでindexを動的に指定したり、elasticsearchが解析できるように構造化してあげたりと、実装が大変そう