質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
AWS Lambda

AWS Lambdaは、クラウド上でアプリを実行できるコンピューティングサービス。サーバーのプロビジョニングや管理を要せず複数のイベントに対してコードを実行します。カスタムロジック用いた他AWSサービスの拡張やAWSの規模やパフォーマンスを用いたバックエンドサービスを作成できます。

Amazon Kinesis

Amazon Kinesisは、リアルタイムで動画や音声、IoT機器といったストリーミングデータを収集・処理・分析する完全マネージド型分析サービスです。インサイトを適時に取得できるので迅速な対応が可能になります。

Docker

Dockerは、Docker社が開発したオープンソースのコンテナー管理ソフトウェアの1つです

AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

Fluentd

Fluentdは、オープンソースのログ収集ツールです。ログの収集方法、ログの記録先などのログデータ処理を柔軟にカスタマイズでき、インプットおよびアウトプットが全てプラグインとして実装されています。

Q&A

解決済

4回答

1932閲覧

【遅い】Fluentd→Kinesis Stream→Lambdaの構成だと、LambdaのCloudWatchのログがはかれるのに10秒~12秒かかってしまう

isacRu

総合スコア64

AWS Lambda

AWS Lambdaは、クラウド上でアプリを実行できるコンピューティングサービス。サーバーのプロビジョニングや管理を要せず複数のイベントに対してコードを実行します。カスタムロジック用いた他AWSサービスの拡張やAWSの規模やパフォーマンスを用いたバックエンドサービスを作成できます。

Amazon Kinesis

Amazon Kinesisは、リアルタイムで動画や音声、IoT機器といったストリーミングデータを収集・処理・分析する完全マネージド型分析サービスです。インサイトを適時に取得できるので迅速な対応が可能になります。

Docker

Dockerは、Docker社が開発したオープンソースのコンテナー管理ソフトウェアの1つです

AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

Fluentd

Fluentdは、オープンソースのログ収集ツールです。ログの収集方法、ログの記録先などのログデータ処理を柔軟にカスタマイズでき、インプットおよびアウトプットが全てプラグインとして実装されています。

0グッド

0クリップ

投稿2020/07/04 10:12

編集2020/07/07 12:01

課題

タイトルの通りですが、実際ログ(CloudWatch)に出力されるのに10秒〜12秒かかってしまい、困っています。
私が知りたいのは「これぐらいかかるもん」なのか、「Fluend設定ファイルやKinesisの設定等を変えれば、早くなるよ」なのかです。
FluentdとかKinesisに詳しい方の、意見を頂きたく質問致しました。
Fluentdの環境はローカルPCで構築されたDockerコンテナを立ち上げています

ソース

Dockerfile

1FROM fluent/fluentd:v1.10 2 3USER root 4 5# install plugin 6RUN apk add --update-cache --virtual .build-deps sudo build-base ruby-dev \ 7 && gem install fluent-plugin-kinesis -v 3.0.0 --no-document \ 8 && gem sources --clear-all \ 9 && apk del .build-deps \ 10 && rm -rf /var/cache/apk/* \ 11 /home/fluent/.gem/ruby/*/cache/*.gem 12 13# set timezone (Alpine) 14RUN apk --update-cache add tzdata && \ 15 cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime && \ 16 apk del tzdata && \ 17 rm -rf /var/cache/apk/* 18 19WORKDIR /fluentd 20COPY ./fluent.conf /fluentd/etc/fluent.conf 21 22USER fluent 23

fluent

1<source> 2 @type forward 3 @label @mainstream 4 port 24224 5</source> 6 7<filter **> 8 @type stdout 9</filter> 10 11<label @mainstream> 12 <match kinesis.**> 13 @type kinesis_streams 14 stream_name sample-kinesis-stream 15 aws_key_id "#{ENV['AWS_ACCESS_KEY_ID#']}" 16 aws_sec_key "#{ENV['AWS_SECRET_ACCESS_KEY']}" 17 region ap-northeast-1 18 19 <buffer> 20 @type file 21 path /fluentd/log/kinesis 22 timekey 5 23 timekey_wait 5 24 timekey_use_utc true 25 flush_interval 1 26 chunk_limit_size 1m 27 flush_thread_interval 0.1 28 flush_thread_burst_interval 0.01 29 flush_thread_count 15 30 </buffer> 31 32 <format> 33 @type json 34 </format> 35 </match> 36</label> 37

Kinesis Stream側の設定
Kinesis Stream側の設定

試したこと・調べたこと

その他、ネットで「Kinesis Lambda 遅い」などと検索しまたが、有効な情報が見つかりませんでした。

その他

今はFluentd→Kinesis Stream→Lambdaの構成ですが、Fluentd→DynamoDB→LambdaやFluentd→S3→Lambdaも試そうかなと思います。
いずれにせよ、速度は大事にしていきたいと思うので、その他「速度ならこの構成の方がおすすめだよ」というのがあれば、ご教授頂けると幸いです。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

timekey 5 timekey_wait 5

なので、Lambdaの動作時間等々を考えたらまあまあ妥当な時間のような気がします。
参考
Config: Buffer Section

投稿2020/07/04 13:49

yu_1985

総合スコア7427

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

take88

2020/07/07 09:50

time が設定されてないので、timekey、timekey_wait の設定は無効な気がします。
guest

0

自己解決

私の方でもいろいろ試しましたが、原因わかりました!
CloudWatchにはかれるのに10秒ぐらいかかるだけで、実際処理はすぐに走っていました。
テストとしてやってみたのですが、Lambdaソースで適当なconsole.logを実行してCloudWatchに反映されるまでが10秒かかりました。結果的にFluentdもKinesis側に問題があったわけではなく、CloudWachにログが反映されるまで時間がかかるだけでした

マイナス評価をする場合は必ず理由を書いてください。

投稿2020/07/05 12:04

編集2020/07/07 10:34
isacRu

総合スコア64

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

isacRu

2020/07/06 03:59

何がマイナスなのか、記載頂けると嬉しいですね。
take88

2020/07/07 09:51

回答が書かれてない?ようですが、可能でしたら、どのように解決したか書いていただけるとうれしいです。(マイナス票は私ではありません。念の為…。)
isacRu

2020/07/07 10:32

どうやら誰かマイナス評価すると、強制的に回答が非表示になる仕様みたいです。 追記をして、更新しました。
guest

0

ちょっと違いますが、Githubに類似のIssueがありました。
https://github.com/fluent/fluentd/issues/2766

バッファーの設定を次のようにすると変化はありますか?

<buffer> @type file path /fluentd/log/kinesis flush_mode interval flush_interval 1 chunk_limit_size 1m flush_thread_interval 0.1 flush_thread_burst_interval 0.01 flush_thread_count 15 </buffer>

あと、インスタンスの性能を測定して、CPU負荷、ローカルストレージのIOPSなど、性能が不足してないか確認してみると良いかもしれません。

投稿2020/07/04 13:35

編集2020/07/04 13:36
take88

総合スコア1351

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

isacRu

2020/07/04 14:59

回答ありがとうございます。 バッファー設定の件、ちょっと試しましたがダメでした???? >あと、インスタンスの性能を測定して、CPU負荷、ローカルストレージのIOPSなど、性能が不足してないか確認してみると良いかもしれません。 すみません、インスタンスとはKinesisのインスタンスでしょうか?
take88

2020/07/07 09:57 編集

fluentdが動いているEC2インスタンスのことです。 CPU→短いインターバルで かつ 15個のスレッドで処理してるので CPU負荷が気になります。十分なコア数があって負荷が低ければ問題ないと思います。 ストレージ→バッファーがFileなので、データ量や速度に応じて ストレージのIO負荷が発生します。ディスクのIOPS性能がボトルネックになっていないか 確認してみると良いかもしれません。
isacRu

2020/07/07 10:38

>fluentdが動いているEC2インスタンスのことです。 すみません、説明が足りなかったみたいです。EC2ではなくローカルPCで、Fluentdの環境構築されたDockerコンテナを立ち上げています。質問内容に追記します。
take88

2020/07/07 11:01

なるほど承知しました。EC2だと思いこんでました…。
guest

0

※Fluentd については明るくないので、AWS側の話をします

Kinesis DataStream がリアルタイム性に欠けるという話はあまり聞いたことがありません。なので、「設定でなんとかなる」なのではないかと思っています。

気になるのはログのボリューム、そしてKinesisのシャード数とバッチサイズです。(スクショにもあるように)1本のシャードで処理できるスループットには限度があります。

ログの '件数' が多いのであれば、シャード数を増やすことを検証してみてはいかがでしょうか。合わせて、適切にシャード分散が図れるようにパーティションキーを設定するよう必要があります(このへんがFluentdからうまく設定できるかは、すみませんが存じ上げません)。

また、バッチサイズの設定も確認した方が良いかもしれません。バッチサイズが極端に小さいとその分lambdaの起動オーバヘッドで CloudWatch logs への配送が遅延することが予想されますし、大きすぎればlambdaの実行時間が伸びてこれもまた遅延する可能性があります。そのへんのチューニングについての良いアイデアはありませんが、Kinesisやlambdaのメトリックを見ながら試行錯誤で調整していくことになるんじゃないかと思います。

投稿2020/07/04 11:57

hassaku_63

総合スコア92

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

isacRu

2020/07/04 12:25

早々の回答ありがとうございます。 >ログの '件数' が多いのであれば、シャード数を増やすことを検証してみてはいかがでしょうか 件数は一件で試しておりますので、シャード数は影響ないかもしれませんね? 念のため変えてみましょうか >バッチサイズの設定も確認した方が良いかもしれません。 バッチ=fluent.confのことでしょうか?
hassaku_63

2020/07/04 12:39 編集

バッチサイズは Kinesis を受ける lambda の設定を指しています。1回あたりに lambda が最大何個のレコードを処理できるかをそこでコントロールできます。 ...とはいえ、ログ1件で試しているのであれば、あまり関係はないかもしれませんね... 1件ずつで試されているのであれば、lambda のコールドスタートに引っかかっているとかも一応可能性はあると思います(薄い気はしますが)。確か今はだいぶ改善していたと思いますが、例えばJavaあたりはコールドスタート時のオーバヘッドが結構重たいです。
isacRu

2020/07/04 15:01

>確か今はだいぶ改善していたと思いますが、例えばJavaあたりはコールドスタート時のオーバヘッドが結構重たいです。 そうなんですね! 今はJSで試しているので、関係なさそうですかね・・
hassaku_63

2020/07/04 18:18

js であればコールドスタート時でも10-12秒にはまず至らないですね。根本原因にはなりえなさそうです。 fluentd がログを flush するタイミングの影響を受けているのでは?というのは割とありそうな線かなという感じはしてました(詳しくなかったので言及できませんでしたが)。で、 yu_1985 様の回答で指摘されている内容がまさしくそれに該当するのではないかと思います。ざっと見た感じ、私もこの方の指摘が正しいように見えます。 ※私自身も後学のため少々調べてみたので少しだけ補足しておきます。細かいパラメータの意味はご自身で確認いただくとして(私には正確に回答できない領域なので)...。 今の fluentd の設定では5秒間のチャンクでログをバッファして、さらに5秒待ってからKinesisに送っているのではないでしょうか? となると、lambdaのコールドスタートも含めたら10-12秒はyu_1985様の指摘通り、妥当だと思います。(コールドスタートがどのくらいかかるかは、lambdaのデプロイパッケージのサイズとか、中のコードの実装にも依存するので一概に言えませんが、多くてもせいぜい数秒程度だと思います)
isacRu

2020/07/05 12:03

調べて頂きありがとうございます。 >今の fluentd の設定では5秒間のチャンクでログをバッファして、さらに5秒待ってからKinesisに送ってい>るのではないでしょうか? ここは関係ないみたいです。ログの送り元から削除する時間のことを指しているかと思います。 私の方でもいろいろ試しましたが、原因わかりました! CloudWatchにはかれるのに10秒ぐらいかかるだけで、実際処理はすぐに走っていました。 実際にLambdaソースで適当なconsole.logを実行して、CloudWatchに反映されるまでが10秒かかるみたいです。結果的にFluentdもKinesis側に問題があったわけではなく、CloudWachにログが反映されるまで時間がかかるだけでした????
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問