Blog
AWS Kinesis Firehoseとkinesis-agentを利用してログをs3に収集する
こんにちは、アドテク本部でインフラエンジニアをしております山下といいます。
去年の話にはなりますが、2017年8月末、待ちに待っていた Kinesis Firehose が東京リージョンでも利用可能になりました。
利用可能になってすぐFirehoseの導入を行い現在運用している状態なので、溜まったノウハウを書いていきたいと思います。
Kinesis Firehoseとは
これまでAWS東京リージョンでKinesisと言えば、唯一利用できていたサービスは Kinesis Stream でした。
Streamに対してデータを流し、別途ワーカーを用意してデータをStreamから出してデータを加工したり
Redshiftに投入したり、そのままs3にputすることで保存を行うといった使い方をされていたかと思います。
8月に利用が可能になったKinesis Firehose は Delivery Stream というデータの受け口にデータをPUTし、その後設定した出力先に対してデータをストアしてくれます。
つまりシンプルにデータを置きたいだけであればワーカーを用意する必要がなくなります。
決められた出力先は以下の4種類です。
- s3
- Redshift
- AWS ElasticSearch
- Splunk
Splunkは最近追加されたようです。
データを加工する必要が無く、s3やRedshiftに保存したいといった場合には最適かと思います。
データの加工やデータの中身によって何かしら行いたい場合にはこれまで通り Kinesis Stream を選択する方が良いのかなと思います。
kinesis-agentを使った送信
Firehoseへデータを送信するにあたり、td-agentを使う方法もありましたが、ログをtailして送信するだけの用途なので
よりシンプルなAmazon謹製のkinesis-agentを使ってみることにしました。
インストールについてや各種設定パラメータ等はドキュメントがあります。
http://docs.aws.amazon.com/ja_jp/streams/latest/dev/writing-with-agents.html
ドキュメントのタイトルの通り、このドキュメントはKinesis Streamへの送信が前提に書かれていますのであくまで参考ですね。
AmazonLinuxの場合、yumでインストールができます。
またgithub上にソースコードもあります。
https://github.com/awslabs/amazon-kinesis-agent
パラメータについては公式ドキュメントがStreamのものなので、載っていなかった
firehose.endpoint やスレッド周りの細かい挙動の設定など、以下のgithubのsampleファイルにしか無いものもチラホラ見受けられます。
基本的な設定としては /etc/aws-kinesis/agent.json に以下のように書くとログを読み込んで送信まで行われます。
またkinesis-agentの機能として送信時のエラーなどのメトリクスをCloudWatchに記録することもできます。
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "cloudwatch.emitMetrics": true, "cloudwatch.endpoint": "monitoring.ap-northeast-1.amazonaws.com", "firehose.endpoint": "https://firehose.ap-northeast-1.amazonaws.com", "flows": [ { "filePattern": "/var/log/syslog*", "deliveryStream": "fh-sample01", } ] } |
送信に失敗した場合、バッファを再送用のキューに溜める挙動となっており、再送処理は行われますが
このキューのサイズはデフォルトで100となっており、この値を超えて送信に失敗すると送信できないデータが発生します。
（キューに入らずdropされる）
デフォルトのログレベルではこの事象の発生を確認する方法はありませんが
ログレベルを TRACE まで落とすと送信できないデータが発生した際にロギングすることができます。
ログレベルの設定は /etc/sysconfig/aws-kinesis-agent 内に AGENT_LOG_LEVEL="TRACE" とすることで設定できます。
運用してみて
kinesis-agentのヒープサイズに注意する
kinesis-agentはjavaで作られており、デフォルトのヒープサイズが512MBとなっているのですが、
大きなログファイルを読み込みパースする際にエラーとなる場合があります。
サイズが大きなログファイルを送信することが見えている場合は
/usr/bin/start-aws-kinesis-agent を編集して先にヒープサイズを上げておくのが無難です。
|
1 2 |
JAVA_START_HEAP=${JAVA_START_HEAP:-32m} JAVA_MAX_HEAP=${JAVA_MAX_HEAP:-512m} |
デフォルトでは上記のようになっていますので、この部分を適当な値に変更しプロセスを再起動します。
Firehoseのキャパシティに注意する
こちらのドキュメントにもあるように、Firehoseの配信ストリームが受け付けられるキャパシティには制限があり、
送信するログの量に応じて順次制限を緩和していく必要があります。
Firehoseの制限緩和ができていない状態で、大量の送信を行うとPUTをなかなか受け付けてくれず、
ログ送信がクライアント側（agent側）で遅延が発生します。
制限緩和については他のAWSサービス同様、サポートケースより行うことができます。
緩和を行う量にもよりますが、緩和までに要する時間はおおよそ 3-4営業日（またはそれ以上）見ておいた方が無難です。
ログのサイズによって計画的に利用する必要があります。
kinesis-agentの状態を確認する（チェックポイントを確認する）
kinesis-agentは自身が読んだファイル名、i-node、オフセット値、チェックポイントの最終更新日時をsqliteで保存しています。
上述のようなキャパシティ不足による遅延が起きた場合にこのチェックポイントを確認して遅延状況を把握します。
デフォルトの保存先は /var/run/aws-kinesis-agent/checkpoints です。
チェックポイントが最新データと乖離してくるとagentのログファイルに以下のようなログが出るようになります。
|
1 |
[WARN] Agent: Tailing is 54.503906 MB (57151716 bytes) behind. |
このbehind値が大きくなる一方の場合、Firehose側の制限緩和が必要な状態になっている可能性が高いです。
トラフィックに注意
Firehoseのエンドポイントへの送信は、インターネットへのアウトバウンド通信となります。
もしNAT Gatewayを経由して大量のログを送信した場合、通常発生するアウトバウンド通信の費用とは別に
以下の通りNAT Gatewayで処理されたトラフィック 1GBにつき費用が発生します。
https://aws.amazon.com/jp/vpc/pricing/
この構成のままログのサイズが増えていくとNAT Gatewayの費用が高騰してしまうため、注意が必要です。
回避策として、ログ送信元のEC2をプライベートサブネットからパブリックサブネットへ移し
EIPを付けることでNAT Gatewayを経由しなくする方法が考えられます。
まとめ
Firehoseを実際に使用してみていくつか注意する点があることが分かりました。
先に挙げた注意点以外にも、Firehoseのキャパシティに対して現状どれくらい使っているかという部分が見えづらく
自分たちで計算・確認を行う点が辛かったりします。
しかし、td-agentのサーバを複数台立ててサービスの規模に合わせて拡張・運用していくことを考えると、
データを送ってさえしまえば適宜保存まで行ってくれるFirehoseは便利なサービスだなと感じています。
今後より使いやすく便利になることを期待します。
Author
