今日から始めるfluentd × Elasticsearch × kibana – カジュアルな解析・高速化

目次

1. まえがき

1.1 対象者

  • 気軽にデータ収集をしたいと思っている開発者
  • 基本的なLinuxコマンドの理解がある方

1.2 この記事を読んで分かること

  • fluentd x Elasticsearch x kibana を用いたアクセスログの収集・計測方法
  • pairsのシステム概要
  • 私の好きなアニメ
  • pairs高速化チーム

1.3 この記事を読んでも分からないこと

  • 本格的な統計解析
  • 恋人の作り方

1.4 自己紹介

はじめまして。サービス事業部の森川と申します。

エウレカには今年のはじめ頃にJoinしました。
エウレカに入る前は、半年くらい自宅でフルタイムの警備を行っていました。
また、前職ではマーケティング・リサーチの会社で、主にサービス全体のミドルウェア周りの設定と社内管理システムを作っていました。

現在は、pairsのサーバーサイド側とフロントエンド側をメインに担当しています。
得意な分野は障害対応とJSな気がします。

好きなアニメはエウレカセブン! といいたいところですが、ナデシココードギアスです。
そろそろ超電磁砲Sを見ようかと思ってます。

2. pairsとシステム

2.1 pairsとは

エウレカが開発・運営している“pairs”について、既にご利用してくださっている方もいらっしゃるかもしれませんが、 あまりよく知らない方は、弊社の石橋が書いた前回の記事をご覧いただければ、雰囲気がつかめるのではないかと思います。

リンクをクリックするのが億劫なあなたのために一言で言うと、
男女の恋愛のはじまりを支援するプラットフォームです。

ちなみに、本稿の3%くらいは石橋の記事に奪われています。ジャパニーズパワハラですね。

2.2 システム概要

pairsのシステム面はどうなっているかというと、
前回の記事の図を見てもらえると分かる通り、
スタンダードなAWSスタックの使い方をしていると思います。

また、専任のインフラ担当はいないので
リソース空き状況によって、各人できる開発者がインフラ整備を進めています。

 

pairsはPCブラウザ、スマホブラウザ、iOSアプリ、Androidアプリの、
4種類の環境でサービスを提供しています。

(PCブラウザとスマホブラウザはサーバーサイドチームとして、
基本的には同じメンバーで開発しています。)

昨年までは比較的カジュアルな開発体制でしたが、
今は人員も増えてきたため、効率と安定性を両立できる体制を構築中です。

2.3 メトリクス?

みなさんはデータの収集、計測をしているでしょうか。
おそらく企業や担当者によってまちまちじゃないかと思います。

pairsのデータベースには、様々なデータが記録されています。
性・年代・居住地はもちろんのこと、
使用端末・ログイン頻度・特定ユーザーへの人気の偏りといった、
行動履歴を含む多種多様なマーケティングデータがあります。

これらのデータをうまく活用して、施策や新機能に活かしていくプロセスについては、
他の担当メンバーに執筆を任せるとして、
ここでは、サーバーシステムのメトリクスについて、お話しすることにします。

 

前述の売上に関わるようなマーケティングデータだけではなく、
システムの信頼性・安定性を高めるためにも、
適切な指標となる様々なデータを集め、活用することが有効です。

 

例えば、エウレカではシステムの死活監視に、定番のZabbixを使用しています。
インストールするだけで簡易にサーバーのデータが取得できますし、
CloudWatchのデータはもちろん、
ログイン中のユーザー数のような、必要なデータを蓄積することが出来ます。

アラートメールの他に、チャットツールのSlackへ飛ばすように設定し、
兆候や変化に素早く反応できるようにしています。

また、アプリケーション性能については、New Relic側のアラートでカバーしています。

このように一口にデータ収集といっても色々と幅がありますが、
今回はWebサーバーのアクセスログを題材にいたします。

2.4 アクセスログの活用

アクセスログ、取ってますか?
もちろん、みなさん取っているかと思います。

前職ではよく障害対応時に影響企業・ユーザー数を算出したり、
問題の対象となるユーザーを追跡するのによく見ていましたが、
最近はアプリ側のログが多く、アクセスログを直接見る頻度は減ったように思います。

とはいえ、やはりアクセスログには基本のキとも言える情報が詰まっているので、
残さず収集して活用していきたいですね。

そこでアクセスログの中から、
まずはレスポンス速度を計測することを目的として、
データを収集していこうと思います。

2.5 アクセスログの集約

サーバーの台数が一台なら、ログの確認に特に手間は無いですが、
サーバー台数が増えるに従って、いちいち各サーバーにログインして、
色々なログを確認するという作業がうんざりするかと思います。

psshCapistranoを使っても良いですが、ここは集約させたいです。
こんな時に頼りになるのは…

はい、みんな大好きfluentdですね。

 

fluentdは多くのメリットがあるのですが、
既存のログファイル設定を変えずに、データを集約できるという点が、
大きなポイントの一つではないかと思っています。

プラグイン作成の容易さ、豊富なので他システムとも連携がしやすいです。

2.6 アクセスログのビジュアライズ

データを溜め込んだものの、活用しなくては意味が無いですね。
ええ、貯金をしたらパーッと使いましょう。

MySQLやMongoDBにデータを入れてもいいですが、
ログを可視化する仕組みを作らないと、
毎回SQLをコピペして貼り付けるMr.作業マシーンになってしまいます。

最近の世の中は便利になったもので、
私達の怠惰な悩みを、簡単に解決してくれるソリューションがあります。
それがElasticsearchkibanaです。

Elasticsearchはリアルタイム検索・解析エンジンですが、データをRESTで簡単に保存できます。
kibanaはそのElasticsearchに溜めたデータのフロントエンド・グラフ化ツールとして簡単に使用できます。

エウレカで実際に使用しているイメージは下記のような感じです。

 

アクセス速度のセグメンテーション

001_kibana_01_01

 

ステータスコード

001_kibana_01_02

 

どうでしょうか。
グラフを眺めているだけで、なんとなく仕事をしている感がでますね。

でも実際には何もしていないので、ちゃんと仕事してくださいね!
さて、それでは実際にインストールして解析してみることにしましょう。


 

3. kibana サンプルシステム構築

3.1 サンプルシステムのサーバー構成例

  • Webサーバー 1台
  • ログ集約サーバー(兼 解析サーバー) 1台

※ AWS ec2上でAmazon Linux 64bitでの運用を想定

(CentOS6 64bitでもS3の手順以外はほぼ一緒です)

 

こちらの構成で作ってみたいと思います。

なお、本番環境(というよりある程度の規模のサービス)では、
log集約サーバーと解析サーバーは安全性やパフォーマンス的にも、分けたほうが良いと思います。

system

3.2 fluentd

まずはfluentdから設定していきます。

3.2.1 Webサーバー側

apacheのインストール

(省略します。お好きな様に入れてください。)

apache ログ設定

パースしやすくするため、ltsv形式で保存します。
また、アクセス先のURL(path)はどうしても取りたいので、“%r”は使わないようにします。

 

参考サイト様: Y-Ken Studio: ApacheログをLTSV形式にする際の2つの落とし穴と対処法+Apache&FluentdのLTSV設定サンプル

 

ロギング設定

$ sudo vi /etc/httpd/conf.d/01-log.conf

<IfModule log_config_module>
    LogFormat "unixtime:%{%s}t\tdatetime:%{%d/%b/%Y:%H:%M:%S %z}t\tx-forwaded-for:%{X-Forwarded-For}i\thost:%h\tsize:%B\tresponse_time:%D\tstatus:%>s\tserver:%A\tHost:%{Host}i\tmethod:%m\tpath:%U%q\tprotocol:%H\tUA:%{User-Agent}i\treferer:%{Referer}i" ltsv
</IfModule>

 

上記ロギング設定を使用した、バーチャルホストの設定例

$ sudo vi /etc/httpd/conf.d/vhost.conf

<VirtualHost *:80>
    ServerAdmin webmaster@your_domain.example.com
    DocumentRoot /var/www/html
    ServerName your_domain.example.com

    LogLevel warn
    ErrorLog "|/usr/sbin/rotatelogs -L logs/error.log logs/error.log.%Y%m%d 86400 540"
    CustomLog "|/usr/sbin/rotatelogs -L logs/access.log logs/access.log.%Y%m%d 86400 540" ltsv
</VirtualHost>

 

fluentdのインストール

yum経由で、Treasure Data社が配布しているfluentdパッケージの
td-agentをインストールします。

公式のドキュメントを参考に、
まずは、Treasure Data社のyumレポジトリを追加します。

 

Treasure Data レポジトリの追加

$ sudo vi /etc/yum.repos.d/treasuredata.repo

[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/$basearch
gpgcheck=0

 

これでTreasureDataのレポジトリが追加されたので、 yumでインストール可能になります。

 

fluentdのインストール

$ sudo yum install td-agent 
$ sudo chkconfig td-agent on  # 自動起動設定をOn

関連プラグインのインストール

次にfluentdで使用する、プラグインをインストールします。

 

fluentd プラグインインストール

$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem update
$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-config-expander

ログの権限設定

アクセスログについて権限設定を行い、 tail位置を記録しておくファイルを作成します。

 

ログファイルの権限設定と位置記録ファイルの作成

$ sudo chgrp td-agent /var/log/httpd
$ sudo chmod g+rx /var/log/httpd
$ sudo touch /var/log/httpd/access_log.pos
$ sudo chown td-agent:td-agent /var/log/httpd/access_log.pos

fluentdによるアクセスログの転送設定

fluentdを用いて、
Webサーバーのログを、集約サーバーへ転送する設定をします

 

fluentd設定ファイルの編集(Webサーバー)

$ sudo vi /etc/td-agent/td-agent.conf

# アクセスログの取得
<source>
  type config_expander
  <config>
    type tail
    path /var/log/httpd/access_log
    pos_file /var/log/httpd/access_log.pos
    format none
    tag ${hostname}/apache.access
  </config>
</source>

# 集約サーバーへ送信
<match *.**>
  type forward
  retry_limit 5
  flush_interval 5s
  <server>
    host 172.16.1.100    # <- 集約サーバーのIPアドレス
    port 24224
  </server>
</match>

fluentd 起動

fluentd 起動

$ sudo /etc/init.d/td-agent configtest
$ sudo /etc/init.d/td-agent start

複数台構成でログを流したい場合は、
同様にして2台目、3台目も設定してください。

3.2.2 集約サーバー側

次にログ集約サーバー側の設定をしていきます。

集約サーバーでは、Elasticsearchへデータを送ると同時に、
S3へも保存するようにします。

やはり生ログがあると安心することと、
外部機関からの監査に必要になると思います。

IAM Role の設定

kibanaの利用だけではなく、S3へログを保存する場合は、
IAM Roleを用いて、S3への書き込み権限があるRoleを作成しておくと便利です。

非AWS環境だったり、S3へのログ保存が不要な場合は、この手順は飛ばしてください。
kibanaとはそこまで関係ないので、画像メインでさらっと説明していきます。

IAM Role 作成手順

AWS サービス選択画面

002_iam_01

まずは「IAM」へ移動し..

 

IAM 設定画面

002_iam_02

左ペインより、「Role」を選択。
そして「Create New Role」ボタンを押下します。

 

Role作成画面 名称入力

002_iam_03

すると、Role作成のモーダルが表示されるので、進めていきます。

Role名称を入力し..

 

Role作成画面 Roleタイプ選択画面

002_iam_04

「Select Role Type」の画面では、
「AWS Service Roles」より、「Amazon EC2」を選択します。

 

Role作成画面 権限設定画面

002_iam_05

「Set Permission」の画面で、 「Custom Policy」を選びます。

 

Role作成画面 Custom Policy作成

002_iam_06

 

ポリシー設定の画面になったら、 以下の設定を入力します。

“test-blog-logs” は、S3のバケット名が入ります。
設定に合わせて変えてください。

Custom Policy内容

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::test-blog-logs",
        "arn:aws:s3:::test-blog-logs/*"
      ]
    }
  ]
}

 

Role作成画面 最終確認

002_iam_07

最後に確認画面が表示されます。
よければ「Create Role」で作成を完了させてください。

 

 

作成したIAM Roleは、
EC2インスタンスの新規作成時に設定できます。
S3を使う場合は、EC2インスタンス作成時に忘れずに設定しましょう。

EC2インスタンス 作成画面

002_iam_08

 

fluentdのインストール

fluentdに関しては、
Webサーバーにfluentdを入れた時と同じ手順を行ってください。

プラグインのインストール

Elasticsearch用のプラグインを含む、各種プラグインを追加します。
ありがたく活用させていただきましょう!

fluentd プラグインのインストール

$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-filter
$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-forest
$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-config-expander
$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch
$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-typecast
$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-parser

$ sudo yum install gcc-c++ libcurl-devel
$ sudo /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch

fluentd アクセスログの保存設定

fluentd設定ファイル編集

$ sudo vi /etc/td-agent/td-agent.conf

# ログの受信
<source>
  type forward
  port 24224
</source>

# パースしたデータをintegerにキャストする
<match parsed.*apache.access**>
  type typecast
  item_types response_time:integer,size:integer,unixtime:integer
  prefix casted
</match>

# パース・キャスト済みのデータをElasticsearchへ格納する
<match casted.parsed.*apache.access**>
  type_name apache
  type elasticsearch
  include_tag_key true
  tag_key @log_name
  host localhost
  port 9200
  logstash_format true
  flush_interval 10s
  buffer_type file
  buffer_path /var/log/td-agent/buffer/casted.apache.access.buffer
</match>

# 1) Elasticsearch用にパース処理 
# 2) S3へ保存
<match **apache.**>
  type copy

  <store>
    type parser
    format ltsv
    time_key datetime
    time_format %d/%b/%Y:%H:%M:%S %z
    add_prefix parsed
    key_name message
  </store>

  <store>
    type forest
    subtype s3
    <template>
      # aws_key_id    // <- IAM Roleで権限設定する場合は不要
      # aws_sec_key   // <- 同上
      s3_bucket my-funky-cool-logs
      s3_endpoint s3-ap-northeast-1.amazonaws.com
      path ${tag}/
      buffer_path /var/ /td-agent/buffer/${tag}
      time_slice_format %Y/%m/%m-%d/access_log-%Y-%m-%d-%H
      flush_interval 1m
    </template>
  </store>
</match>

3.3 Elasticsearch

3.3.1 インストール

こちらもyum経由でインストールします。
まずは、Elasticsearchのブログを参考に、yumレポジトリを追加します。

yumレポジトリの追加

$ sudo vi /etc/yum.repos.d/elasticsearch.repo

[elasticsearch-1.0]
name=Elasticsearch repository for 1.0.x packages
baseurl=http://packages.elasticsearch.org/elasticsearch/1.0/centos
gpgcheck=1
gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearch
enabled=1

レポジトリを追加したらインストールをします。

Elasticsearchインストール

$ sudo yum install elasticsearch
$ sudo chkconfig elasticsearch on # 自動起動設定をOn

3.3.2 メモリ設定

デフォルトでは 256MB〜1GBに設定されているようなので、
最適な値に設定を変更しましょう。

Elasticsearchのメモリ設定

$ sudo vim /etc/sysconfig/elasticsearch

ES_HEAP_SIZE=2g  # <- 2GBに設定する場合

3.3.3 起動

Elasticsearchを起動させます。

Elasticsearchの起動

$ sudo /etc/init.d/elasticsearch start

3.3.4 Curatorの設定

このままだとデータが溜まっていく一方なので、
定期的に削除する設定を入れていきます。

Python製のCuratorというツールを使えば、
Elasticsearch上のデータを簡単にクリアできます。

参考サイト様: Qiita: curator で Kibana 用の elasticsearch のインデックスを定期的に削除する

pipのインストール

Curatorを入れるために、
Python用パッケージ管理ツールのpipをインストールします。
前までは少し億劫だったpipのインストールも、直接できるようになっているようです。

参考サイト様: Qiita: いつの間にかpipのインストールが楽になってた件

pip インストール

$ curl https://bootstrap.pypa.io/get-pip.py | sudo python

これでpipがインストールされました。

今回はPythonアプリを作らないので、virtualenv等は設定せず、
システム用のPythonを使ったまま進めます。

Curatorのインストールと設定

インストール

Curator インストール

$ sudo pip install elasticsearch-curator

 

cron設定

$ sudo vi /etc/cron.d/curator

# Elasticsearch index整理
15 4 * * * root curator --host localhost --prefix logstash- -b 2 -c 14 -d 21

3.4 kibana

最後にkibanaをインストールします。

3.4.1 インストール

kibanaにはWebサーバーが必要となるので、apacheをインストールします。
またインストールにはgithubのレポジトリを利用するため、gitもインストールします。

kibanaのインストール

$ sudo yum install git httpd
$ cd /var/www
$ sudo git clone https://github.com/elasticsearch/kibana.git kibana
$ sudo ln -s kibana/src kibana_public

3.4.2 apacheの設定

9200番ポートをわざわざ開放するのも手間なので、
/elasticsearch でアクセスした際に、
Elasticsearchがリッスンしている 9200番へ転送する設定を入れておきます。

apache設定の追加

$ sudo vim /etc/httpd/conf.d/kibana.conf

# config for kibana
Alias /kibana /var/www/kibana_public

<Directory "/var/www/kibana">
    Options FollowSymLinks
    AllowOverride None
#    Require ip 172.16.1.xxx  # <- 必要であればIP制限を行ってください
</Directory>

ProxyPass /elasticsearch http://localhost:9200
ProxyPassReverse /elasticsearch /es http://localhost:9200

<Location "/es">
#     Require ip 172.16.1.xxx  # <- 必要であればIP制限を行ってください
</Location>

# ※ Apache2.4系の書式で記述しています。

3.4.3 kibana config設定

apacheの設定に合わせて、kibanaの設定も変更します。

kibanaのElasticsearch連携の設定

$ sudo vi /var/www/kibana/src/config.js

# 24行名付近を修正
    elasticsearch: "http://"+window.location.hostname+"/elasticsearch",

3.5 データの蓄積と確認

Webサーバーにブラウザからアクセスしてみます。
うまく成功すれば、kibanaからデータを確認することが出来ます。

fluentdはデフォルトではTCP/UDP 両方の24224番ポートを使用します。
まず、こちらの疎通の確認が正常にできているかどうか疑ってください。

疎通ができている場合は、何かしらエラーが起きているので、
最初の部分で、ログに記録してデバッグしてみましょう。

fluentd デバッグ用設定

$ sudo vi /etc/td-agent/td-agent.conf

# 1) Elasticsearch用にパース処理
# 2) S3へ保存
<match **apache.**>
  type copy

###### ↓を追加 ##########

  <store>
    type stdout
  </store>

######### ここまで #######

  <store>
    type parser
    format ltsv
    time_key datetime
    time_format %d/%b/%Y:%H:%M:%S %z
    add_prefix parsed
    key_name message
  </store>

  <store>
    type forest
    subtype s3
    <template>
      s3_bucket test-blog-logs
      s3_endpoint s3-ap-northeast-1.amazonaws.com
      path ${tag}/
      buffer_path /var/log/td-agent/buffer/${tag}
      time_slice_format %Y/%m/%m-%d/access_log-%Y-%m-%d-%H
      flush_interval 1m
    </template>
  </store>
</match>

上記の type stdout を追加することで、 マッチしたログが標準出力に吐き出されます。

td-agentの起動スクリプト経由で起動している場合は、
ログファイルに書き込まれるので、そちらを確認してみましょう。

$ tail -f /var/log/td-agent/td-agent.log

この状態でWebサーバーにブラウザからアクセスして、

  • Webサーバー上のアクセスログが更新されているかどうか
  • ポジションファイル(access_log.pos)が更新されているかどうか
  • 集約サーバー側のfluentdログファイルにログの中身が出力されているかどうか、エラーがでていないかどうか

を確認してみてください。

 

ネットワーク疎通が怪しい場合は、 netcat等のポート指定可能なコマンドでアクセスしてみてください。
集約サーバー側のfluentdログファイルに

[warn]: no patterns matched

のような表示が確認できたら正常に疎通できています。

ネットワーク疎通確認の例

$ nc <集約サーバーのIPアドレス> 24224
a # <- 適当にタイプ 
b # <- 適当にタイプ 
a # <- 適当にタイプ

4. kibanaを使う

正常にデータが溜まっているかどうか、kibanaへアクセスしてみましょう。

http://<集約サーバーのIPアドレス>/kibana/

正常にインストールされていれば、エンジニアが好きそうな、黒基調のCOOLな画面が表示されます。

 

kibanaのトップ画面

003_kibana_02_01

4.1 新規ダッシュボードの作成

ページ下部にある
「3. Blank Dashboard I’m comfortable figuring it out on my own」
から新しいダッシュボードを作成してみます。

ヒストグラムの追加

こんな感じのヒストグラムを追加します。

 

kibana ヒストグラムの例

003_kibana_02_02

行の追加

  • 中央右部の「ADD A ROW」を押下すると、行追加画面が出てきます。
  • 右側の「Add Row」の部分の「Title」に適当な行の名前を入力し、紫色の「Create Row」を押下してください。
  • 左側の「Rows」の部分に一行追加されれば成功です。「Save」を押下して保存します。

パネル(ヒストグラム)の追加

  • 中央左側の「Add Panel to empty row」を押下すると、行設定画面が出てきます。
  • 左側の「Select Panel Type」より、「histogram」を選択してください。
  • 何やら色々な設定項目がでてきます
  • 「Title」に適当なパネルの名前を入力し、「Span」を10程度にして下部の緑色の「Save」を押下して保存します。

上記手順を終えると、ヒストグラムのパネルが追加されます。 ここではまだ「QUERY」で条件設定をしていないので、緑色のグラフが表示されます。
グラフが空で、全く表示されない場合は、 Elasticsearchへうまくデータが溜まっていない可能性が高いです。
画面上部の「Time Filter」から「Last 6h」辺りを選択し、過去6時間分のデータを見ても、 全く表示されない場合は、「データの蓄積と確認」の項を参考に、確認してみてください。

テーブルの追加

データの中身を出力するテーブルを追加します。

 

kibana テーブルの例

003_kibana_02_03

行の追加

(先ほどと同様の手順で、行を追加してください)

パネル(テーブル)の追加

  • 中央左側の「Add Panel to empty row」を押下すると、行設定画面が出てきます。
  • 今度は、「table」を選択します。
  • 何やら色々な設定項目がでてきます
  • 「Title」に適当なパネルの名前を入力し、「Span」を12にして下部の緑色の「Save」を押下して保存します。

上記手順を終えると、テーブルのパネルが追加され、
データが溜まっている場合は、JSONドキュメントデータがずらずらーっと確認できます。
ヒストグラムとテーブルを追加した後のイメージは下記のようになっています。

 

kibana ヒストグラムとテーブル

003_kibana_02_04

ダッシュボードの保存

作成したダッシュボードは、 画面上部のフロッピーディスクアイコンを押下し、
名前を入力して、左側のアイコンを押下すると保存できます。

ダッシュボードは自動で保存されないので、
間違えてリロードをしてしまうと、一から作りなおしになるので注意してください!

 

kibana ダッシュボードの保存

003_kibana_02_05

レスポンス速度のセグメンテーション

さて、次は単調なグラフ表示から、 レスポンス速度別のセグメンテーションを行っていきましょう。200msから始めて、200msごとにセグメント分けしていきます。
グラフのデータをするためには、画面上部の「QUERY」に、条件を入力していきます。
kibanaのクエリでは、Apache Luceneのシンタックスが使えます。

参考サイト様: Qiita: kibanaで使えるlucene query

 

例: レスポンスタイムが200ms以下

response_time:<200000

例:レスポンスタイムが200ms〜400ms

response_time:[200000 TO 400000]

 

上記のようなクエリを、2sまで入力していくと、
次の図のようになります。

 

kibana レスポンス速度セグメンテーション

004_kibana_03_01

 

この状態でabをかけてみると…

 

kibana ab結果

004_kibana_03_02

 

あれ…?
全てのレスポンスが緑(0.2s以下)で捌いています。(-_-;)
さすが静的ファイル。ec2のt1.microなのに早いですね。

これだとkibanaのグラフが単調で面白く無いので、

いい感じにデータをバラけさすために、簡単なPHPプログラムを置いて、実験してみました。
その結果、↓の画像のようなグラフになりました。

 

kibana サンプルプログラムのab結果(5分スケール)

004_kibana_03_03

 

ちょっと細かいので、15分間の表示にしたグラフが↓です。

 

kibana サンプルプログラムのab結果(15分スケール)

004_kibana_03_04

 

いい感じの積み上げ棒グラフになってますね。

これをリクエスト先パスごとに比べてみます。

 

kibana /index.htmlへのアクセス(1時間スケール)

004_kibana_03_05

上の画像の、青い枠の部分がフィルタ設定部分で、
通常は枠外の左端のタイムスタンプの項目のみが設定されており、
期間でフィルタリングされた結果が表示されています。

この場合は、“path”に“index.html”を含むリクエストでフィルタリングしました。
ご覧のとおり、緑のデータが多くなっており、ここがボトルネックではなさそうです。

 

kibana /api/ へのアクセス(1時間スケール)

004_kibana_03_06

続いて上の画像は、“path”に“api”を含むリクエストです。
“index.html”に比べるとやや遅くなっていることが分かります。

 

kibana /blog/ へのアクセス(1時間スケール)

004_kibana_03_07

最後に、“path”に“blog”を含むリクエストです。
こいつが病巣でした。
明らかに遅いレスポンス速度になっています。

実際にボトルネックを取り除く作業は、本番でしか再現しなかったり、
高負荷状態で初めて問題になることがあり、難しい作業となることも多いですが、
レスポンスの遅さは、解約率や収益にも響きますし、
何より「pairs」を気持ち良く使っていただけるように、
ここは粘り強く改善を続けていきます。


 

5. エウレカでの実際の活用事例

最後に、エウレカでの事例を紹介します。

 

これからお話する内容は、pairsの高速化を担う、
「pairs高速化チーム」のとある一日のお話です。
(↑そのままのネーミングですね…)

高速化チームはpairsチームのみならず、エウレカ全社で憧れのチームです。
エウレカで働く人間なら、誰もが高速化チームに行きたいと思っています。

そんな人気をよそに、
生粋のスピード狂しかいない高速化チームは、毎回高い目標を設定しています。
高速化チームの一員である、弊社の山下はいつもこう言ってます。

 

「検索のピリオドの向こうへ」

 

そんなファンキーな彼とともに働いているためか、
インターンの子もこう語るようになってしまいました。

「次のIntelのCPUが14nmで作られたら、僕らは14msでレスポンス返しますよ。
(※ ただしmedianに限る)」

さすが東大生、何をいっているのかわかりませんが、いうことが違いますね?!

 

さて、そんな彼らには高すぎる目標を維持するため、
「丸刈り」及び「ボウズ」という嬉しいご褒美を用意しています。

そう、高速化チームの人気の秘密は、この自分へのご褒美なのです。

ボウズは選ばれた人間しかなることが出来ないという事実は、もはや社会人としての基礎常識です。
ボウズになることによって、取引先やお客様に威圧感を与えてしまいますよね。
これは良くありません。イッパンピープルにはもっての外です。

エウレカ内でも、ボウズは基本NGなのですが、
特別に高速化チームのみ、ボウズで就業することを許可されています。

これは社外秘ですが、彼らは経営層に次ぎ、非公式ながら特権階級として君臨しています。

 

そう、その日も0.2s強の改善をその日中に行わないと、目標未達となってしまい、
ボウズにはなれないところでした。
高速化チームでのリリース予定の修正は、 事前の計測では、0.15s–0.3sの速度改善を見込んでおり、
十分に期待できる修正でしたが、この日より前の一週間は何も進捗していませんでした。

目標達成までいける手応えは十分にあるものの、やはり不安がつきまといます。
言うなれば、自分に特別な好意を寄せているような素振りを見せる相手に、思いの丈を告白する気分でしょうか。

ああ、思い出したくない…

 

そんな中、ちょうどお昼すぎの13時前くらいに、
検索API関連の修正を含むpairsのリリースを行いました。

その結果が下記の画像となります。

 

リリース結果を比較した、実際のkibanaのグラフ

004_kibana_04_01

 

004_kibana_04_02

 

この画像は、その日のリリースでの、実際のアクセスデータで、
社内グループに改善報告としてポストした画像となります。
(一部、数字や文字をぼかしていますm(__)m)

実際の数字をマスクしているため分かりづらいのですが、
グラフを見ると、データの色の傾向が、
リリース前とリリース後で異なっており、
何かの効果があったことが見て取れると思います。

 

kibana導入前は、わざわざ各Webサーバーに入って、
アクセスログから平均値や中央値を算出していました。

kibana導入後は、KPIとなるグラフさえ作っておけば、
直近のデータや、少し前までのデータであれば、
そこまで時間をかけずに確認することができるようになりました。

 

これで、計測や報告用の数字出しに無駄な時間をかけずに済み、
本来のやるべき業務にフォーカスしやすくなったのではないかと思います。

 

目標を達成し続けている、高速化チーム

005_blog_01

 


 

6. 〜終章〜

本記事は、kibanaによるアクセスログ解析の簡単な構築例と、
弊社での実例の中から一つだけご紹介いたしました

使用者は、全員がDev側ということもあり、
今のところは深い解析を行うというよりも、
アプリケーションのボトルネックとなっている部分や、
リアルタイムエラーの把握、
時間軸で見たサービスの簡単な傾向把握という使い方がメインとなっています。

kibanaには様々なログを入れたりして、もっと夢がある使い方ができると思います。
データ解析をメインに行っている方には少し物足りない内容かもしれませんが、本記事がみなさまの参考になれば幸いです。

 

また、記事の内容については、関係各所から怒られないように、
簡単な検証を済ませていますが、
間違いや誤記がありましたらコメント等で教えて頂けると助かりますm(__)m

 

なお、エウレカでは「サービス視点でのデータ解析をしてみたい」、
「解析結果を受けて、有効な施策立案、機能開発を行いたい!」という、
意欲的なエンジニアを大募集しています。<3

話だけでもちょっと聞きたいシャイな方もお待ちしてます。 ;)