FluentdとObjectRocketで実現するハイブリッドクラウドのログ集約

本記事は Hart Hoover と Ryan Walker による共著です。

New RelicアラートをRackspaceサポートへ連携するサービス

Rackspace の DevOps Automation チームは最近、New Relic から発せられたアラートを Rackspace サポートに通知する新しいサービスを発表しました。このサービスでは、アラートが発生すると自動的にチケットが作成され、DevOps エンジニアが対応します。たとえ深夜3時にアラートが発生しても、お客様は安心して眠ることができるのです。さらに、お客様の環境から収集した他のデータポイントと組み合わせることで、エンジニアは問題の所在を素早く特定し、適切な対応策を実行できます。

設計上の課題：セキュリティと公開エンドポイントの両立

このサービス向けのインフラを設計する際、私たちが直面したのはよくあるものの興味深い問題でした。セキュリティ確保のため Rackspace 内部システムへのアクセスを制限しつつ、New Relic が通信できる公開エンドポイントも維持する必要があったのです。

そこで私たちは、公開APIエンドポイントとプライベートなワーカーを完全に分離したサービス設計を採用しました。公開APIエンドポイントが New Relic からアラートを受け取り、キューとして機能する ObjectRocket Redis インスタンスへ渡します。一方、ワーカーサービスは RackConnect ファイアウォールの内側で内部稼働しており、キューからメッセージを取り出してアラートを作成します。

この方式により環境はきれいに分離されましたが、ログ集約の面で新たな課題が生じました。私たちはプライベート環境内で ElasticSearch/Kibana スタックを運用しており、ファイアウォールの内側では fluentd を使ってログを直接 ElasticSearch に送信しています。しかし、ファイアウォールの外側からは EK スタックに到達できません。

この問題を解決するために、私たちは fluentd を使って公開APIサービスのログを ObjectRocket MongoDB インスタンスへ送信する仕組みを導入しました。そして内部では再び fluentd を使い、ObjectRocket からログを取り出して ElasticSearch に投入します。これにより、環境全体のアクティビティを単一の場所で確認できるようになったのです。

Fluentdとは？

Fluentd はオープンソースのデータコレクタで、可能な限りデータをJSONとして構造化することを目指しています。これにより、ログデータを共通フォーマットに整えるために大量のスクリプトを書いて保守する必要がなくなり、すべてをJSONで扱えます。

Fluentd の強みは、複数の入力元（ソース）と出力先（デスティネーション）をサポートしている点にあります。たとえば、Twitter のストリームからデータを収集し、IRC で通知するといったことも可能です。コミュニティ提供のプラグインも非常に豊富に揃っています。

DockerとFluentdの連携

MongoDB 用の fluentd プラグインを使えば、ObjectRocket へのログ送信は簡単に行えます。まず、入力元となるソースを定義する必要があります。私たちのサービスはすべて Docker 上で動いているため、コンテナのログを fluentd に取り込む必要があります。Jason Wilder 氏による docker-gen と fluentd を使ったログ集約手法の記事が本記事と相性が良いので、併せて参照することをおすすめします。fluentd コンテナが起動し（docker-gen が fluentd 設定を生成した後）、稼働中の各コンテナに対して次のようなセクションが生成されているはずです：

<source>
  type tail
  format json
  time_key time
  path /var/lib/docker/containers/abcdef/abcdef-json.log
  pos_file /var/lib/docker/containers/abcdef/abcdef-json.log.pos
  tag docker.container.abcdef
  rotate_wait 5
</source>

この設定はコンテナのログを tail し、位置ファイル（pos file）によって読み取り位置を記録します。重要な点として、この設定セクションにあるタグは fluentd タグであり、集約したデータをどう処理するかを fluentd に伝えるために使われます。

MongoDBへのログ送信（公開側の設定）

公開側では、「match」ディレクティブを使って、fluentd にデータの処理方法を指示します。同じ設定ファイル内で、変数をお使いの ObjectRocket データベースの実際の情報に置き換えてください：

<match docker.**>
  type mongo
  database $DBNAME
  collection prod
  host $HOSTNAME
  port $PORT
  ssl
  capped
  capped_size 100m
  user $MONGOUSER
  password $MONGOPASS
  include_tag_key true
</match>

include_tag_key の設定により、fluentd は MongoDB 内のログレコードにタグを含めるようになります。これにより、どのログエントリがどのコンテナに属するのかを正確に把握できます。Fluentd は MongoDB へのデータ投入を開始し、その後アプリケーションのプライベート側でそのデータを取得することになります。

MongoDBからElasticSearchへ（プライベート側の設定）

プライベート側でも引き続き fluentd の MongoDB プラグインを使用しますが、今回はソース（入力元）として設定します：

<source>
  type mongo_tail
  database $DBNAME
  collection prod
  host $HOSTNAME
  port $PORT
  user $MONGOUSER
  password $MONGOPASS
  ssl
  time_key time
  wait_time 5
  tag prod
  id_store_file /app/prod_last_id
</source>

次に、ログを ElasticSearch に送り込むための「match」を定義します：

<match **>
  type forest
  subtype elasticsearch
  <template>
    host elasticsearch.domain.com
    port 9200
    index_name fluentd
    logstash_format true
    buffer_type memory
    type_name ${tag}
    flush_interval 3
    retry_limit 17
    retry_wait 1.0
    num_threads 1
  </template>
</match>

また、私たちは forest という fluentd プラグインも使用しています。これにより、複数環境にまたがるタグ設定が大幅にシンプルになります。

まとめ

Fluentd は、複数ホストに分散した Docker ログを集約し、MongoDB データベースへ送信するのに最適な手段です。今回のケースでは、ObjectRocket が公開環境とプライベート環境をつなぐログ集約の中継地点として機能しました。その他のユースケースとしては、収集したデータに対するリアルタイム分析などが考えられます。私たちのチームにとって何より嬉しいのは、ObjectRocket の高い信頼性と専門知識のおかげで、MongoDB を自前で管理する必要がないという点です。