すべてのデータはAWSに通ず: Fluentdを介したストリーミングアップロード
本日は、特別な御馳走があります! Treasure Dataの田村清人氏がFluentdを紹介する顧客向けに本当に面白い記事を記載しています。データを収集し、蓄積し、加工するAWSサービスの広い多様性において、Fluentdをどのように使うことができるのかを示しています。
-- Jeff;
データストレージは安い、データ収集はそうではない！
データストレージは、信じられないほど安くなりました。安いと言ったとき、ハードウェアだけを意味せず、運用費や人件費も含みます。AWSのようなIaaSの出現のおかげで、もはやキャパシティプランニングに日単位、週単位で費やす必要が無く（より良い方法として自動拡張管理機能でリソースを自動配置もできます）、サーバのラッキングや発火の心配も不要になりました。
安いストレージとは、我々のアイディアがデータを蓄積するのにいくら費用がかかるのか、ということに縛られなくなることを意味します。一握りのエンジニアは、Redshiftインスタンスを実行し、日次のEMRバッチジョブを供給するためにAmazon Simple Storage Service (S3)にバックアップされた数千億のログファイルを管理することができます。大規模なデータセットを分析することは、もはやハイテクに精通した企業のみの特権ではありません。
しかしながら、データ収集にはまだ大きな挑戦が残っています。データはストレージシステムやその組織内で独自に管理されており、魔法のように配信はできません。それゆえに、多くのスクリプトは構文解析するために書かれ、データをロードします。これらのスクリプトは、扱いにくく、エラーが発生しやすく、拡張するのは不可能に近くなります。
これは、Fluentdが解決しようとする課題（拡張的で柔軟なリアルタイムでのデータ収集）です。このブログ投稿の残りの部分で、Fluentdの基本構成を通して、AWS上でのユーザー事例を共有することにします。
Fluentd : 大量のデータ配信向けのオープンソースのデータ収集機能
Fluentdは、元々はTreasure Data社によって書かれたオープンソース収集機能です。2011年10月にオープンソース化し、少なくとも2年半が経過し着実に牽引してきています。本日では、本番環境に反映しているSlideshareや任天堂のような会社と一緒に、GitHub上に50未満の提供者と2100を超える人々による盛況なコミュニティを形成しています。
入出力
上位の考え方として、Fluentdは入力と出力から成り立ちます。入力では、どこからどのようにFluentdがデータを取得するかを特定します。
一般的な入力は次のとおりです。:
- ログファイルのを追跡(Tail)および各行（または一度に複数行）の解析
- syslogメッセージのListen
- HTTPリクエストの受け入れおよび、メッセージBodyの解析
入力に関しては、JSONとタギングという2つの重要な機能があります。
- Fluentd は核となるデータフォーマットとしてJSONを対象とし、各入力処理は入ってくるデータを一連のJSON"イベント"に変換する責任を担います。
- 各入力は、取得するデータにタグを提供します。タグに基づいて、Fluentdは異なる入力から来たデータで何をすべきか決定します。（以下参照）
一度、データが入力経由でFluentdに流れたら、Fluentdは各イベントタグ（上記2つの例）を見て、ローカルファイルシステム、RDBMS、NoSQLデータベースやAWSサービス群のような出力対象に送ります。
オープンでプラガブルなアーキテクチャー
Fluentd はどのような入力と出力が可能なのでしょうか？ その極意は、オープンでプラガブルなアーキテクチャであることになります。 Rubyの最低限の知識で、数時間のうちに新しいプラグインをビルドできます。 当然、多くのFluentdユーザは、AWS愛好家であり、我々は既に次のようなAWSサービスに対応したプラグインを用意しています。:
- Amazon Simple Storage Service (S3) (出力)
- Amazon Redshift (出力)
- Amazon Simple Queue Service (SQS) (入出力)
- Amazon Kinesis (出力)
- Amazon DynamodB (出力)
- AWS CloudWatch (入力)
性能と信頼性
FluentdがほとんどRubyで書かれていることを表明しているため、性能の懸念があると思われるかもしれません。 心配することはありません。Fluentdはとても高速に動作します。 近年のサーバであれば、シングルコアで15000 event/secまで処理できますし、マルチコアでFulentdを動作させれば、より良いスループットを得られるでしょう。
Fluentdはソフトウェアの中の性能が重要である箇所にはC言語で書かれた低レベルのライブラリを使うことで高速性を保持しています。 例えば、Fluentdは、イベントループ向けにはCool.io（Fluentdの主担当の中川 真宏によってメンテナンスされています）、内部データフォーマット向けにはMessagePack for Ruby（Fluentdのオリジナル作成者である古橋貞之によってメンテナンスされています）を使っています。
高速性は素晴らしいですが、ログ収集には信頼性が必須です。 データ損失は、不良データとなり、更に悪い決断に導いてしまいます。 Fluentdはバッファリングすることで信頼性を保ちます。出力プラグインは、インメモリかディスク上にデータをバッファーするよう設定することができるため、仮にデータ転送が失敗した場合でもデータ損失なくリトライされます。 バッファリングの仕組みは、高度なチューニングができ、様々なスループット/レイテンーの要件に応じて修正することができます。
例：ApacheのログをS3にアーカイブする
これからFluentdの特徴の全体像を把握するため、1つの例を深堀していきましょう。 ApacheウェブサーバーのログをS3にアーカイブするためのFluentdの設定方法を見ていきます。
Step 1: Fluentdを取得する
FluentdはRuby Gem（gem install fluentd）として利用可能です。 また、Treasure Dataは、td-agentに依存性を全て持たせた形でパッケージ化しています。ここでは、td-agentで実行してみましょう。Ubunts 12.04上での動作を仮定していますが、td-agentは今後もUbunts の信頼のためにUbuntu LucidとCentOS 5/6でもサポートされ、利用できます。
次のコマンドを実行します。:
curl -L http://toolbelt.treasuredata.com/sh/install-ubuntu-precise.sh | sh以下のコマンドでtd-agentのインストールが成功したか確認することができます。:
$ which td-agent
/usr/sbin/td-agentStep 2: 入力と出力を設定する
td-agent用の設定ファイルは /etc/td-agent/td-agent.confに配置されます。Apache ログファイルを取得できるように再設定してみましょう。
<source>
type tail
format apache2
path /var/log/apache2/access_log
pos_file /var/log/td-agent/apache2.access_log.pos
tag s3.apache.access
</source>このように、Apacheログファイルの入力を設定します。これは、/var/log/apache2/access_log にあるログファイルを追跡するようにFluentdに伝え、Apache の統合されたログ形式に応じてそれを解析し、s3.apache.accessとタグ付けします。
次に、以下のようにS3への出力を設定します。:
<match s3.*.*>
type s3
s3_bucket YOUR_BUCKET_NAME
path logs/
buffer_path /var/log/td-agent/s3
time_slice_format %Y%m%d%H
time_slice_wait 10m
utc
format_json true
include_time_key true
include_tag_key true
buffer_chunk_limit 256m
</match><match s3.*.*> は、1) 3つのパーツで構成され、2) s3で始まっている、タグをもった全てのイベントにマッチするように、Fluentdに伝えます。 Apacheのアクセスログから来ている全てのイベントはs3.apache.accessというタグを持っているので、これにマッチし、S3に送信されます。
最後に、更新した設定でtd-agent を起動してみましょう。:
$ sudo service td-agent start
* Starting td-agent td-agent [OK]バッファリング（“time_slice_wait ”を見てください）のためにS3にデータが出現されるまで、約10分程度かかるかもしれませんが、やがてYOUR_BUCKET_NAME/logs/yyyyMMddHHにログが出現するでしょう。また、FluentdがS3バケットにアクセスを書き込みできることを確認する必要があります。このためにはIAM role用に次の設定をしておく必要があります。:
{
"Effect": "Allow",
"Action": [
"s3:Get*", "s3:List*","s3:Put*", "s3:Post*"
],
"Resource": [
"arn:aws:s3:::YOUR_BUCKET_NAME/logs/*", "arn:aws:s3::: YOUR_BUCKET_NAME"
]
}What's Next?
上記概要と例は、Fluentdで何ができるのかのほんの一部を垣間見たに過ぎません。 website 、documentationからFluentdについてさらに詳しく学ぶことができますし、GitHub repository上のプロジェクトに貢献することもできます。 もし、質問があれば、我々に、Twitterでツイートとして頂くか、mailing listに質問をしてください！
-- 清人
この記事はAWSシニアエバンジェリスト Jeff BarrのAmazon Web Services Blogの記事、 All Data Are Belong to AWS: Streaming upload via Fluentdを 平山毅 (Facebook, Twitter)が翻訳したものです。
コメント