SlideShare a Scribd company logo

Fluentdのお勧めシステム構成パターン

•
•
Kentaro Yoshida
Kentaro Yoshida

2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』　出版記念！執筆者が語る大講演会！ での発表スライドです。

1 of 43
Downloaded 321 times
page 9th Sep, 2014 ! Fluentdのお勧めシステム構成パターン 1
page 1. 自己紹介 2
Fluentdのお勧めシステム構成パターン
page 4
page 1. 自己紹介 2. はじめに 3. Fluentdのある世界 4. Fluentd構成パターン 5. まとめ 本日の流れ 5
page 2. はじめに 6
page はじめに 7 第2特集の執筆を担当 「ログ収集ミドルウェアFluentd徹底攻略」 ! 第1章：ログ収集の目的とミドルウェアの特徴 第2章：はじめてみようFluentd 第3章：Fluentd設計のコツ 第4章：Fluentd運用ノウハウ 第5章：逆引きFluentdプラグイン
page はじめに 8 入門記事はネット上に多くあれど、まとまった解説が無い問題を解決 Fluentd運用・監視の方法 安定稼働するためのFluentd構成 逆引きFluentdプラグイン集 約300に及ぶプラグインのソースコードを追った上で分類
page 3. Fluentdのある世界 9
page Fluentdとは 10
page Fluentdとは 11
page Fluentdとは 12 ログ/メッセージの集約を賢く実現するプロダクト Rubyで書かれたミドルウェア 依存ミドルウェア無しで動く、小さなフットプリント 再送処理など、ネットワーク周りの例外処理を任せられる 豊富なプラグインにより様々な要件の集約に対応できる プラグインによる容易な入力/フィルタ/出力機能の拡張 Rubyを用いたプラグイン記述のハードルはとても低い 使い慣れた言語でデータ出力/保存を伴うフィルタ処理も書ける 標準入力で外部プログラムを実行する“exec_filter”を利用する
page Fluentdとは 13 ログ収集コストの最小化 ログ収集を行う定期バッチはFluentdに置き換えると保守が楽になる ファイルのローテーションにも対応するtailプラグインを用ると、 手軽にログの収集を準リアルタイム化できる レインテンシの改善・帯域バーストの緩和という効果もある
page Fluentdの導入前後 14
page Fluentdの導入前後 15 導入前 logディレクトリを踏み台サーバにNFSマウントし、各エンジニアが編 み出した秘伝のワンライナーでtailコマンド出力をフィルタリングする 踏み台サーバのLoad Averageが常時数十越えのため、非常に重たい 意図せぬファイルロックが残り、本番WEBサーバのログローテートに 失敗することもある 本番WEBサーバのNetwork I/O・Disk I/Oが平日勤務中のみ異様に多い 非エンジニアによるログ集計を行うためのハードルが高い
page Fluentdの導入前後 16 導入後 エンジニアの数にスケールしたLoad Averageではなくなる 集約ログを踏み台サーバへファイル出力することで、 tailコマンドという互換性を保ちながらスケールする仕組みを実現 さらに踏み台サーバのファイルバッファに載るため処理が高速化 NFSを使わないため本番WEBサーバのNetwork I/O・Disk I/Oが激減 構造化されたLTSV形式で出力することで、 awkを用いた高機能なログ調査や分析が出来るようになる 集約ログをTreasureData（Hadoop）に格納することで、SQLを用いた 集計が実現し、非エンジニアによる分析や施策が打てるようになる
page Fluentdの基本的な使い方 17
page Fluentdの基本的な使い方 18 基本的な使い方 ログ/メッセージの集約と保存 ネットワーク周りで手間の掛かるリトライ実装を任せられる ! 利用例 アプリログ、アクセスログをFluentdに流し、集約して保存する ファイルやDBといった、複数データストアへの同時保存にも最適
page Fluentd導入後に実現するログ活用 19
page Fluentd導入後に実現するログ活用 20 Fluentd導入による効果 ログ/メッセージ収集の実装や運用保守の手間が激減する 準リアルタイムに収集されたログデータを活用できる 新鮮なデータを用いたストリーミングデータ処理が実現できる 新鮮なログ/メッセージの可視化が行えるデータストアが作れる
page Fluentd導入後に実現するログ活用 21 利用例 Norikraを用いて単位時間毎にSQL集計した結果を収集する ダッシュボードアプリに収集データをグラフ等を用いて可視化する リアルタイム分析によるログの活用 時系列解析によるインシデントの早期予測 不達メールアドレスのクリーニング 不正ユーザ抽出
page Fluentdが適さない使い方 22
page Fluentdが適さない使い方 23 QoSの最高レベル“Exactly Once”を必要とするデータ収集 FluentdはAt Most Onceを採用している メッセージを確実に1回だけ配信するという、 厳密なトランザクション処理を求める要件には不向き 例）取りこぼしが絶対に許されない課金データ ! CPUコア1つでは処理しきれない負荷の掛かるフィルタ処理 複数コア利用や分散処理を行うためのFluentdクラスタ構成が必要
page Fluentdが適さない使い方 24 Fluentdのサービス再起動を伴う設定変更が日常的に発生する使い方 日々変化するビジネスロジックをプラグイン設定に織り込まない Fluentdは基本的に変更のないシンプルな処理のみを担うと良い 扱いやすい形式で集約する所までをFluentdが担うと良い インフラ層とアプリ層の責任範囲を明確化するためにもそうすべき
page Fluentdが適さない使い方 25 メトリクス収集を超えた、死活監視システムとしての利用 複雑になるため、NagiosやZabbixの得意とすることは任せるべき 現実的にはサービスのモニタリングデータ収集に留めてファイル出力 し、閾値やアラート通知部分は一般の監視システムに任せるべき
page 4. Fluentd構成パターン 26
page Fluentdのシングル構成 27
page 構成パターン（シングル構成） 28 シングル構成 任意のソースからデータを集めた後に適宜フィルタ加工を行い、 1つ以上のアウトプット先に保存する用途 ユースケース アプリ等からのメッセージをバッファに蓄えて即座に応答を返し保存 定期的にポーリングすることで収集したデータを保存する APIで収集できるTwitterやAWSなどのログ/メッセージ収集 製造機械や温度センサーデータの収集
page Fluentdクラスタの汎用構成 29 日々の変更がある/負荷の掛かるような加工や 集計を行わない場合は、Aggregatorから各 種データ保存先に入れる構成が一般的です。
page 構成パターン（汎用構成） 30 汎用構成 複数のFluentdからのログ/メッセージを集約する場合に、forward プラグインを用いて一度集約し、適切な保存先へ仕分ける構成 ユースケース 複数サーバのアクセスログなどを収集・集約しバッファした後に適宜 フィルタ加工を行い、1つ以上のアウトプット先に保存する フィルタ加工の例 GeoIPを用いてIPアドレスから位置情報を付与する 別ファイルとして保存するために、サービス毎にタグを分ける elasticsearch + Kibanaを組み合わせたダッシュボードを構築する
page Fluentdクラスタの応用構成 31 負荷や用途に応じてサーバを分けると、保守もしやすくなります。 Aggregatorの後ろをまとめて1台にする構成も良く取られます。
page 構成パターン（応用構成） 32 応用構成 演算コストの掛かるフィルタ処理など行うケースには、相乗りせずに Aggregatorノードの先に専用のFluentdインスタンスを構成する 応答性能の安定化や障害リスクを下げる観点で分けるケースもある 基本的に設定変更が発生しないAggregatorノードと比較して、 Processor/Watcherノードの方が設定変更が多い傾向がある ユースケース フィルタ系プラグインやNorikraを用いた時系列データ集計 Processor/Watcherノードにてファイル出力を行い、監視ミドルウェア (Nagiosなど)を用いて、監視のファイル文字列監視・通知を行う
page 安定運用する上で意識したいこと 33 各ノードは単一責任とすることで、障害に強い構成とする Fowarder：転送元ノード 収集したログ/メッセージをAggregatorへ転送する Aggregator：集約ノード Forwarderからのイベントの集約を行う フProcessor：ィルタ処理ノード イベントの集計や加工を行う Watcher：イベント内容に応じた処理や監視連携、通知を行う 末端のインスタンスからはログをAggregatorへforwardするだけにする ことで、最終保存先を記述する設定ファイルの配布対象サーバが減る これらは単なる用途の呼称のため、それ専用の設定がある訳では無い
page 5. まとめ 34
page まとめ 35 まずは小さくFluentdを導入してみましょう 依存ミドルウェアの無いパッケージインストールで始められます syslog等を用いた既存収集システムがあっても、並行稼働できます ログ/メッセージ管理のDevOpsをFluentdで実現できます 固い運用をするには向き不向きがあるので、適切な使い方をしよう 遊び用途なら、手軽なストリーミングデータプロセッサとして Fluentdを活用して使い倒してみましょう！ 例：Twitterのタイムラインから特定画像を取得し、Tumblrへ投稿する https://speakerdeck.com/bash0c7/fluentd-in-my-sweet-home
page 宣伝 36 より詳細な内容はこの書籍にまとめております。 PDF版はGihyo Digital Publishingにて販売中！ サーバ/インフラエンジニア養成読本 ログ収集～可視化編 [現場主導のデータ分析環 境を構築!] (Software Design plus) 出版社/メーカー: 技術評論社 発売日: 2014/08/08 定価: 本体1,980円＋税
お知らせ
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
page Thanks! 43 ご清聴ありがとうございました。

More Related Content

Fluentdのお勧めシステム構成パターン

  • 1. page 9th Sep, 2014 ! Fluentdのお勧めシステム構成パターン 1
  • 5. page 1. 自己紹介 2. はじめに 3. Fluentdのある世界 4. Fluentd構成パターン 5. まとめ 本日の流れ 5
  • 7. page はじめに 7 第2特集の執筆を担当 「ログ収集ミドルウェアFluentd徹底攻略」 ! 第1章：ログ収集の目的とミドルウェアの特徴 第2章：はじめてみようFluentd 第3章：Fluentd設計のコツ 第4章：Fluentd運用ノウハウ 第5章：逆引きFluentdプラグイン
  • 8. page はじめに 8 入門記事はネット上に多くあれど、まとまった解説が無い問題を解決 Fluentd運用・監視の方法 安定稼働するためのFluentd構成 逆引きFluentdプラグイン集 約300に及ぶプラグインのソースコードを追った上で分類
  • 12. page Fluentdとは 12 ログ/メッセージの集約を賢く実現するプロダクト Rubyで書かれたミドルウェア 依存ミドルウェア無しで動く、小さなフットプリント 再送処理など、ネットワーク周りの例外処理を任せられる 豊富なプラグインにより様々な要件の集約に対応できる プラグインによる容易な入力/フィルタ/出力機能の拡張 Rubyを用いたプラグイン記述のハードルはとても低い 使い慣れた言語でデータ出力/保存を伴うフィルタ処理も書ける 標準入力で外部プログラムを実行する“exec_filter”を利用する
  • 13. page Fluentdとは 13 ログ収集コストの最小化 ログ収集を行う定期バッチはFluentdに置き換えると保守が楽になる ファイルのローテーションにも対応するtailプラグインを用ると、 手軽にログの収集を準リアルタイム化できる レインテンシの改善・帯域バーストの緩和という効果もある
  • 15. page Fluentdの導入前後 15 導入前 logディレクトリを踏み台サーバにNFSマウントし、各エンジニアが編 み出した秘伝のワンライナーでtailコマンド出力をフィルタリングする 踏み台サーバのLoad Averageが常時数十越えのため、非常に重たい 意図せぬファイルロックが残り、本番WEBサーバのログローテートに 失敗することもある 本番WEBサーバのNetwork I/O・Disk I/Oが平日勤務中のみ異様に多い 非エンジニアによるログ集計を行うためのハードルが高い
  • 16. page Fluentdの導入前後 16 導入後 エンジニアの数にスケールしたLoad Averageではなくなる 集約ログを踏み台サーバへファイル出力することで、 tailコマンドという互換性を保ちながらスケールする仕組みを実現 さらに踏み台サーバのファイルバッファに載るため処理が高速化 NFSを使わないため本番WEBサーバのNetwork I/O・Disk I/Oが激減 構造化されたLTSV形式で出力することで、 awkを用いた高機能なログ調査や分析が出来るようになる 集約ログをTreasureData（Hadoop）に格納することで、SQLを用いた 集計が実現し、非エンジニアによる分析や施策が打てるようになる
  • 18. page Fluentdの基本的な使い方 18 基本的な使い方 ログ/メッセージの集約と保存 ネットワーク周りで手間の掛かるリトライ実装を任せられる ! 利用例 アプリログ、アクセスログをFluentdに流し、集約して保存する ファイルやDBといった、複数データストアへの同時保存にも最適
  • 20. page Fluentd導入後に実現するログ活用 20 Fluentd導入による効果 ログ/メッセージ収集の実装や運用保守の手間が激減する 準リアルタイムに収集されたログデータを活用できる 新鮮なデータを用いたストリーミングデータ処理が実現できる 新鮮なログ/メッセージの可視化が行えるデータストアが作れる
  • 21. page Fluentd導入後に実現するログ活用 21 利用例 Norikraを用いて単位時間毎にSQL集計した結果を収集する ダッシュボードアプリに収集データをグラフ等を用いて可視化する リアルタイム分析によるログの活用 時系列解析によるインシデントの早期予測 不達メールアドレスのクリーニング 不正ユーザ抽出
  • 23. page Fluentdが適さない使い方 23 QoSの最高レベル“Exactly Once”を必要とするデータ収集 FluentdはAt Most Onceを採用している メッセージを確実に1回だけ配信するという、 厳密なトランザクション処理を求める要件には不向き 例）取りこぼしが絶対に許されない課金データ ! CPUコア1つでは処理しきれない負荷の掛かるフィルタ処理 複数コア利用や分散処理を行うためのFluentdクラスタ構成が必要
  • 24. page Fluentdが適さない使い方 24 Fluentdのサービス再起動を伴う設定変更が日常的に発生する使い方 日々変化するビジネスロジックをプラグイン設定に織り込まない Fluentdは基本的に変更のないシンプルな処理のみを担うと良い 扱いやすい形式で集約する所までをFluentdが担うと良い インフラ層とアプリ層の責任範囲を明確化するためにもそうすべき
  • 25. page Fluentdが適さない使い方 25 メトリクス収集を超えた、死活監視システムとしての利用 複雑になるため、NagiosやZabbixの得意とすることは任せるべき 現実的にはサービスのモニタリングデータ収集に留めてファイル出力 し、閾値やアラート通知部分は一般の監視システムに任せるべき
  • 28. page 構成パターン（シングル構成） 28 シングル構成 任意のソースからデータを集めた後に適宜フィルタ加工を行い、 1つ以上のアウトプット先に保存する用途 ユースケース アプリ等からのメッセージをバッファに蓄えて即座に応答を返し保存 定期的にポーリングすることで収集したデータを保存する APIで収集できるTwitterやAWSなどのログ/メッセージ収集 製造機械や温度センサーデータの収集
  • 29. page Fluentdクラスタの汎用構成 29 日々の変更がある/負荷の掛かるような加工や 集計を行わない場合は、Aggregatorから各 種データ保存先に入れる構成が一般的です。
  • 30. page 構成パターン（汎用構成） 30 汎用構成 複数のFluentdからのログ/メッセージを集約する場合に、forward プラグインを用いて一度集約し、適切な保存先へ仕分ける構成 ユースケース 複数サーバのアクセスログなどを収集・集約しバッファした後に適宜 フィルタ加工を行い、1つ以上のアウトプット先に保存する フィルタ加工の例 GeoIPを用いてIPアドレスから位置情報を付与する 別ファイルとして保存するために、サービス毎にタグを分ける elasticsearch + Kibanaを組み合わせたダッシュボードを構築する
  • 31. page Fluentdクラスタの応用構成 31 負荷や用途に応じてサーバを分けると、保守もしやすくなります。 Aggregatorの後ろをまとめて1台にする構成も良く取られます。
  • 32. page 構成パターン（応用構成） 32 応用構成 演算コストの掛かるフィルタ処理など行うケースには、相乗りせずに Aggregatorノードの先に専用のFluentdインスタンスを構成する 応答性能の安定化や障害リスクを下げる観点で分けるケースもある 基本的に設定変更が発生しないAggregatorノードと比較して、 Processor/Watcherノードの方が設定変更が多い傾向がある ユースケース フィルタ系プラグインやNorikraを用いた時系列データ集計 Processor/Watcherノードにてファイル出力を行い、監視ミドルウェア (Nagiosなど)を用いて、監視のファイル文字列監視・通知を行う
  • 33. page 安定運用する上で意識したいこと 33 各ノードは単一責任とすることで、障害に強い構成とする Fowarder：転送元ノード 収集したログ/メッセージをAggregatorへ転送する Aggregator：集約ノード Forwarderからのイベントの集約を行う フProcessor：ィルタ処理ノード イベントの集計や加工を行う Watcher：イベント内容に応じた処理や監視連携、通知を行う 末端のインスタンスからはログをAggregatorへforwardするだけにする ことで、最終保存先を記述する設定ファイルの配布対象サーバが減る これらは単なる用途の呼称のため、それ専用の設定がある訳では無い
  • 35. page まとめ 35 まずは小さくFluentdを導入してみましょう 依存ミドルウェアの無いパッケージインストールで始められます syslog等を用いた既存収集システムがあっても、並行稼働できます ログ/メッセージ管理のDevOpsをFluentdで実現できます 固い運用をするには向き不向きがあるので、適切な使い方をしよう 遊び用途なら、手軽なストリーミングデータプロセッサとして Fluentdを活用して使い倒してみましょう！ 例：Twitterのタイムラインから特定画像を取得し、Tumblrへ投稿する https://speakerdeck.com/bash0c7/fluentd-in-my-sweet-home
  • 36. page 宣伝 36 より詳細な内容はこの書籍にまとめております。 PDF版はGihyo Digital Publishingにて販売中！ サーバ/インフラエンジニア養成読本 ログ収集～可視化編 [現場主導のデータ分析環 境を構築!] (Software Design plus) 出版社/メーカー: 技術評論社 発売日: 2014/08/08 定価: 本体1,980円＋税
  • 43. page Thanks! 43 ご清聴ありがとうございました。