概要
Fluent BitとAmazon Kinesis Data Firehoseを使って、サーバーからログをストリームし、S3に保存する基盤を作成したのでまとめました。
本編は概要編で、次の記事で実装編を書きます。
ログを保存の方法は様々
ログには
- アプリケーションから吐かれるエラーログ
- アプリケーションから吐き出す障害調査用に備えたログ
- アプリケーションから吐き出すユーザー行動分析用のログ
などなど、用途に応じて様々なものがあるでしょう。
エラーログや障害調査用ログはAWSを使う場合、CloudWatch Agentをインスタンスに立てて、CloudWatchに吐き出すのが良くあるのではないでしょうか。
また、ユーザー行動分析用のログであればRDBにログ用のDBスキーマを作って保存したり、DynamoDBに保存したり、S3に保存したりなどがパターンとしてあるのかなと思います。
ユーザー行動ログは結局どうするのが良いの？
RDBに保存する
RDBを使っている場合、ユーザーデータと結合させて分析することを考えると、RDBにユーザー行動ログ保存するのがよくあるパターンですね。
しかし、スケールアウトしにくく、アプリケーションのボトルネックになりやすいRDBにログを保存するという手段は、どうしてもという理由がない限りはなるべく避けたいです。
RDBを使う理由としては、例えば
- 他のテーブルとjoinしなければならない
- 元々RDBを使っていて、急遽ログを取ることになったが、時間が足りずとりあえずRDBに突っ込む
あたりでしょうか。
ただ、前者のjoinしなければならない場合でも「ログに何を入れるか」の設計によってはある程度回避もできるのかなと思います。
この辺りを回避できれば、ログの保存先にRDBを使うという手段も無くなってきますね。
ログ収集ツールを使ってRDB以外の場所に保存する
DBとは別の経路で保存するようにすれば、ボトルネックになりやすいDBへのconnectionを増やすことなくログを保存することができます。
例えば、パッと思いつくのはFluentd、FluentBit、Logstashなどのログ収集ツールを使って、Webサーバー内に吐かれたログを別の場所に送るという手段です。
ログ収集ツールのプロセスはWebサーバー上で動かすので、この部分はWebサーバーをスケーリングすれば負荷には対応できます。
そうすると、次に気にするべき点は収集先となるログの保存場所です。
ログの保存先として使うサービスにもいろいろありますが、今回は2つ紹介します。
Elasticsearch
保存場所をElasticsearchなどの全文検索エンジンに流すようにすれば、Kibanaを組み合わせるなどして柔軟なログの検索ができます。
ElasticsearchはAWSでもマネージドなサービスが出ているので、ログを別の場所に送る部分をWebサーバー側で意識するだけで、ログを保存する基盤が構築できますね。
S3
一方、S3に保存するという手段もあります。
S3だと下記のメリットがあるのかなと思います。
- Web開発において、AWS上にインフラを構築している場合に使用されるシーンが多く、追加の学習コストがかからない
- 料金コストが安価であり、数ヶ月や数年は使わないログをS3 Glacierに移動させることによって、さらに料金コストが減る
- 組織の都合で、「ログ分析用のAWSアカウントに既存のログを移動させたい」となった場合、AWS CLIを使ってクロスアカウントでも簡単に移行できる
S3にログを保存した場合は、AWSのマネージドサービスであるAthenaとGlueを組み合わせることで、SQLでログを検索、及び分析することができます。
今回はこちらのS3に保存する方を採用し、実装しました。
使用技術
保存先はS3と決まレバ、あとはS3までの経路を実現させるための技術選定です。
その経路の中で
- サーバーに吐かれたログを読み込み、AWS上の何かしらのサービスにログを送る
- AWS上でログをキャッチし、S3に書き込む
の2点を何かしらの技術で実現する必要があります。
普段はWebサーバーとして、DockerコンテナをECS上で動かしていたのでコンテナと相性が良いサービスを前提としました。
Fluent Bit
C言語で実装されたログ収集ツールです。
Fluentdと同じ類のツールですが、Fluentdよりも軽量でその分できることが少なくなっています。
FluentdとFluentBitの比較は[こちら]。(https://fluentbit.io/documentation/0.8/about/fluentd_and_fluentbit.html)
今回はログ収集ツールでは、ログが書き込まれたファイルからログを読み込み、AWSのマネージドなサービスにログを送ることさえできれば良かったのでFluentBitを使いました。
コンテナイメージが用意されていて、かつコンテナが軽量だったというのも選定理由の1つとしてありました。
Amazon Kinesis Data Firehose
https://aws.amazon.com/jp/kinesis/data-firehose/
Webサーバーなどのデバイスから送られてきたデータをキャッチし、S3やRedshiftなどのデータストアに書き込むストリーミングサービスです。
Kinesisにはリアルタイムデータ分析用だったり、動画をストリーミングしたりなど、用途に応じたサービスがいくつかあります。
今回はリアルタイム分析は要件としてはなく、将来的に分析をかけられるようにS3にログを保存しておくというものでした。
そのため、データストアにログをストリーミングしてくれるだけのシンプルなAmazon Kinesis Data Firehoseを選定しました。
アーキテクチャ
分析基盤も含め、下記の図のアーキテクチャとしました。
ECSでアプリケーションコンテナと、FluentBitのコンテナが動いていて、
- アプリケーションコンテナにログが吐かれる
- Fluent Bitがtailでファイルを監視し続け、ログファイルにログが吐かれたことを検知する
- Fluent BitがKinesis Data Firehoseにログを送る
- Kinesis Data FirehoseがS3にログを書き込む
~~ ここから分析基盤 ~~
- GlueがS3からパーティションとしてログデータをロードする
- ユーザーがAthenaを使ってGlueでロードされたデータにクエリをかける
と言った感じです。
ただし、今回は説明のためECSのホスト部分をローカル環境に置き換え、下記のアーキテクチャとします。
ECSの部分がローカルのDockerエンジンに置き換わった形です。
最後に
今回はFluentBit × Kinesis × S3でログ保存基盤を作るための概要とさせていただきました。
次回、実装編を書きたいと思います。