AWSのEKSのログを(ニア)リアルタイムでBigQuery連携するアーキテクチャ調査メモ

背景

• AWSのEKSのアクセスログやアプリケーションログをリアルタイムにBigQueryに連携したい
• 現状の最適アーキテクチャ調査をしたのでメモ

方法

1. Fluentd -> BigQuery

Fluentd と BigQuery を使用したリアルタイムのログ分析

• 最もシンプルな構成、BQでのアドホックな分析要求だけであればこれで良い
• 割り当て上限: テーブル毎にデフォルト100,000/secondのinsertの上限だが、追加リクエストで増やすこと可能 (割り当てと上限)
• ストリーミングインサートなので費用がかかる
  • $0.010 per 200MB (データ取り込みの料金)
• kubenetesクラスタで設定するにはDeamonSet/SidecarContainerとしてエージェントを導入する
  • [sambaizさんブログ]Kubernetesの1PodでAppとfluentdコンテナを動かしてBigQueryに送る
  • [kube公式]Logging Architecture#cluster-level-logging-architectures
• (※)正確な分析のためには重複排除処理が必要な場合はviewなどを使って解決する必要がありそう

その他参照

• [DevelopersIO]Fluentdのコネクタを使ってBigQueryへのストリーミング挿入を試してみる
  • AWSインスタンスからの連携の情報あり。SA使う。

2. fluentd -> PubSub → Dataflow →  BigQuery

• 1の構成にPubSub + Dataflow を追加
• PubSubを挟むことにより複数のDestinationに分けられる
• Dataflowを挟むことにより、リアルタイムにログを処理するパイプラインも作成可能
• リアルタイムデータの活用やBQやGCSやMLなど複数に渡っていく場合は1ではなくこちらの方が良い

参照

• [メルカリ]GCPでStreamなデータパイプライン始めました
• ZOZOTOWNを支えるリアルタイムデータ連携基盤
• [zozo]OSSにコントリビュートしてログ収集基盤におけるCloud Pub/Subのリージョン間通信費用を削減した話

3. Cloud Logging Agent -> Cloud Logging -> BigQuery

• Fluentdではなく、Cloud Logging Agentを経由するところが1との違い
• 一旦Cloud Loggingを経由するため、Cloud Loggingの機能(検索、モニタリング設定)が使えることがメリット
• デメリットとしては、Cloud Loggingの費用がかさむ
• Cloud Logging エージェントの実体は Fluentd + fluent-plugin-google-cloud

参照

• [studistブログ]GCP Cloud Logging でつくる EKS on EC2 のログ収集基盤

結論

シンプルに1のFluentd + BigQueryが良さそう。要求によって2,3などを考える。