adtech studio

Google Cloud Pub/Sub にアップロードしたログを Logstash を使って Elasticsearch に流す

By urano

Elasticsearch GCP

みなさんこんにちは。

アドテクスタジオの CIA (Central Infrastructure Agency)でプロダクトサポートとしてインフラの構築・運用を行なっている浦野(@lanocci)と申します。

 

この記事は、CyberAgent Developers Advent Calendar 2017 10日目の記事です。

 

私が構築に携わっているプロダクトでは、GCP 上にシステムを構築しており、ログデータを流通させるために GCP の Cloud Pub/Sub (以下、 Pub/Sub)を利用しています。

Pub/Sub を使うと、一つのアプリケーションから発生したログを複数のサブスクライバーに配布することができるので、ビッグデータ解析のために BigQuery へログをロードさせつつ、 Elasticsearch にも並行してデータを流し、 Kibana を使ってログデータを可視化しておくというようなこともできます。

今回は Pub/Sub から Elasticsearch にデータを流す時に便利な Logstash の Google_pubsub input plugin をご紹介したいと思います。

 

モチベーション・本記事の概要

導入部でご説明した内容と一部重複しますが、 Logstash の Google_pubsub input plugin を導入したモチベーションとしては

  • GCP を使ってサービスを構築していて、 Pub/Sub にログデータをアップロードしており、そのログの可視化を Elasticsearch / Kibana で実現したい
  • 別途バッチジョブを用意して対応することもできるが、 Logstash に Pub/Sub から入力を受け付けるプラグインが用意されている→これを使えば簡単に実現できそう

といったものです。

実際、プラグインの導入はコマンド一つ実行するだけですし、プラグインを利用するための設定もシンプルなのですが、私たちのプロダクトで利用する上ではパフォーマンスの観点で気をつけないといけない点がありました。

本記事は、プラグインの導入方法についてと、私の経験を交えた注意点の二本立てでご紹介いたします。

 

本題に入る前に

Logstash 自体についてのご紹介ができていなかったので、ここで簡単にご説明いたします。

Logstash は、 Elasticsearch で有名な Elastic 社が提供するログ収集ツールで、複数のログの発生元( input )を監視し、発生したログに対してフィルタ処理( filter )を行なった上で様々なデータストアに出力( output )することができます。

Elastic 社が提供しているツールであるということもあり、 Elasticsearch への出力がデフォルトでサポートされていることが特徴の一つです。

詳細は公式サイトをご参照ください。

なお、本記事では GCE のインスタンス上で Linux OS(Debian)  Elasticsearch: 6.0 / Logstash 6.0 を利用することを前提としています。

 

プラグインの導入

Elasticsearch, Kibana, 及び Logstash 自体のインストールについては Elastic 社公式ページにわかりやすく記載されていますのでここでは割愛させていただきます。

 

Logstash に Google_pubsub input プラグインの導入するための作業としては、以下のコマンドを実行するだけです。

なお、参考リンクの手順通りに Logstash をインストールしていれば、上記コマンドの bin/logstash-plugin のフルパスは /usr/share/logstash/bin/logstash となっておりますので適宜読み替えていただければと思います。

 

Pub/Subからの入力の設定

Logstash でログを処理するためには、「パイプライン」を定義する必要があります。Structure of a Config File | Logstash

パイプラインには “input”, “filter”, “output” がありますが、今回の Google_pubsub input plugin は Pub/Sub からの “input” を受け付けるプラグインです。

(他にもStackdriverにログを転送する機能を持っていたりもしますが、今回は割愛します)

今回利用する “input” 定義の例は以下の通りです。

input としたい Pub/Sub トピックとサブスクリプション、及びその Pub/Sub が属しているプロジェクトの ID を指定するだけで特定のトピックに Push されたログを Pull してくることができます。トピックはすでに存在しているものから指定する必要がありますが、サブスクリプションは同名のものがなければ自動で作成してくれます。

なお、今回はコメントアウトしていますが、 GCP 外に logstash を構築した場合は Pub/Sub と連携するために、 GCP にログインするための鍵情報が必要となりますのでご注意ください。

 

パフォーマンス上の注意点

今回このプラグインを導入したプロダクトはまだ開発中ですが、先日負荷試験を実施した際に秒間50件のログを5分間流したところ、 Logstash がログを処理しきるのに15分程度かかってしまっていました。一秒間あたり20件弱程度しか処理できていない計算になります。

さすがに秒間20件では本番運用に耐えられません。

結論から言えば、このプラグインがデフォルトで5件ずつしか Pub/Sub から Pull してこないということがボトルネックとなっていたことが原因で、これを十分に大きな値に変えることで、確認できている限りで秒間1,000件程度を処理できるようになりました。

修正したパイプライン定義は以下のようになっています。

最終行の max_messages が Pub/Sub から一度に Pull してくるメッセージ数の上限を定義しています。

マシンスペックや Logstash の設定にもよる可能性はありますが、確認できている限り、このプラグインでは秒間2~3回 Pub/Sub に対してリクエストを投げるようになっているため、トラフィックに合わせて一度に Pull する量を調整しないとどんどん Pub/Sub にログが累積し続けることになるため、ここで調整をしていく必要があります。

チューニング後、ログを Kibana で可視化した結果(秒間1,000件を処理)

まとめ

今回の記事では Cloud Pub/Sub から Elasticsearch にログをロードするための仕組みとして Logstash の Google_pubsub input plugin をご紹介し、パフォーマンスを上げるための注意点を簡単に共有させていただきました。

ログ収集ツールのパフォーマンスチューニングを行う場合、インプット元、アウトプット先の処理性能にも影響を受けるので診断が難しいことが多いかと思います。

本編ではご紹介しておりませんでしたが、 Logstash での処理が遅いかもしれないと疑うような場面では、 Logstash のスループットを確認できる、 “metrics” という機能が Logstash に付属していますので、 こちらを参考に、計測したいパイプラインに対して metrics を導入してスループット計測をしてみることをお勧めします。

また、本編の最後でご紹介したような、インプットの処理を高速化した後は、後続の処理にかかる負荷が大きくなってきます。

その影響で処理が遅くなっているようでしたら、こちらのガイドを参考に Logstash のスレッド( worker )数や一度に処理する queue の大きさをチューニングすると良いでしょう。

内部構造についてイメージを掴みたい場合は、こちらのブログに少し情報が古いかもしれませんが Logstash の queue や worker の関係が図で紹介されているのでヒントになるかと思います。

Google_pubsub input plugin は Pub/Sub と Elasticsearch を連携させて使いたい場合、設定がシンプルで簡単に導入できるツールだと思いますので、ぜひ機会があれば使ってみてください。