page

Sep, 20149th

!

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

1

page

1. 自己紹介

2

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円＋税

お知らせ

page

Thanks!

43

ご清聴ありがとうございました。