Elasticコミュニティランチに行ってきました

まえがき

日本のElasticコミュニティメンバーが集まって、
Elastic社メンバーとランチするイベントに招いていただいたので行ってきました!
場所は普段全く縁がないGINZA SIX13FのTHE GRAND GINZA
写真は取れなかったですが、お肉もお魚もめっちゃ美味しかったです!

なぜ呼ばれたの?

Elastic社が用意している、Elastic Stackについての質問することできる掲示板があります。
2016年くらいからここで、分かる範囲でたまに質問を答えていたりしたことをきっかけにお声がけいただきました。

当時はElasticの大谷さんがほとんどの質問に答えるという状況で、
サポート費用を貰っているわけでもないのに大変そうだなーと他人事ながら思っていましたw

ほんとどの質問を大谷さんが頑張る図

f:id:st1t:20181211212253p:plain

Elasticコミュニティとの関わり

そんな中で自分はというと、どうしてもログ解析からElasticsearchという切り口だと社内で仲間が増えづらかったりして頭を抱えていました。
一人でやるとどうしても孤立しがちなので、社内ではなく、社外へ仲間を作るために少しでも関わりを持とうとしたのがきっかけでした。

ささいなPRを出してみたり、

Elastic Stack 6系のPioneer Programでバグ報告や、機能についてのIssueを出したりしていました。

github.com github.com

思い返してみれば、このPRが初めて大規模なOSSへのPRでした。
右も左もわからず、IssueやDiscussで修正内容について意見を求めるわけでもなく、
また、Contribute.mdをきちんと見るわけでもなく無知が故に投げてしまった本当にひどいPRでした。。。

そんなひどいPRにも関わらず無視するわけでもなく、
MetricbeatコミッターのRuflinさんtsgさんはきちんとレビューとコメントをしてくれて今でも本当に感謝しています🙏
このPRからコードを読み書きすることやOSSプロダクトそのものの関わりが増えて、
内容はともかく、人生を変えた一つのターニングポイントといっても過言ではなかったです。

閑話休題

どんな会だったのか

参加者は多分15名〜20名くらいいたかなと思います。
最初に自己紹介をしたのですが、
以下の本を書かれている方や、私と同じくDiscussで良く見かける方が多かったです。
テーブルが分かれていたのですが、反対側の方と話すタイミングがなかったのはちょっと残念。
他にも本を書かれていた方がいらっしゃるのですが、リンクが見つけられなくてすいません💧

acro-engineer.hatenablog.com nextpublishing.jp honto.jp

私の席の周りはDiscussでよくお見かけする、mnozawaさんや、
Elastic Stackを使ったセキュリティの発表で有名なフューチャーアーキテクトの日比野さん
Elasticsearch実践ガイドを執筆された惣道さんがいらっしゃいました。

Logstash周りで色々話しができてめっちゃ面白かったです。
以下、話した内容

  • 本当はBeatsだけ、Logstashだけ、Kibanaだけみたいな部分的なポイントではなく、一気通貫で設定する時のポイントを話せたら良いな
    • やりたいけど、発表時間が2,30分メインの中では話すのは厳しそう
  • BeatsプロダクトからS3にPushする機能があればいいのに
  • 旧X-Packは日本のサイトでは「有償オプション」、海外のサイトでは「Elastic Stack Features」だけど、なんて呼べば良いんだろ
    • 途中からShayさんが自分たちの席に来てもらえて、英語のサイトに記載あるElastic Stack Featuresが正しそうだった(うろ覚え)

おみやげ

f:id:st1t:20181211215735j:plain

左:定期や社員証をいれられるやつ、真ん中:ブルートゥースイヤホン、右:海外でも使えるモバイルバッテリー

ブルートゥースは本当に凄いですね、いくらかかっているんだろう🤔
モバイルバッテリーも、各地対応(U.K/EUROPE/USA/AUST)って初めてみました、すごい。
そして個人的には社員証入れられそうなやつがかっこよくて実は一番うれしかったですw

これだけ色々していただいているだけに、
もっとコミュニティに携われるよう頑張っていこうと思います!

来年は技術書展で本書きたいなー

ありがとうございました!

SendGridハンズオンに行ってきた

まえがき

前々から良い評判を聞いていたSendGrid。
アカウントは発行してもらったのですが、まともに触れていませんでした。
時間もできたので日本でSendGridの代理店をされている構造計画研究所さんでハンズオンをやってるのを見かけたので参加させてもらいました。

基本的にはクラスメソッドの濱田さんが書かれていることの通りだったので、
それ以外でいくつか良かった点を上げていこうと思います。

設定等の細かい部分については記載しませんので、興味がある方はぜひ参加してみてください😃

dev.classmethod.jp

良かった点@最初のつまづきポイントを教えてくれる

  • テキストメールを送るための設定
  • Activity機能の注意事項
  • バウンスメールの管理方法
  • Event Webhookの簡易的な動作確認

良かった点@SendGridを使うと何ができるか、便利になるかを把握しやすい

  • 大量のメール送信をテストするためのテスト用ドメインが用意されている
    • 大量メルマガにありがちな数百万通のテストとか実際にやろうとすると相当大変。 かといって、モックでやるとネットワークや負荷、送信処理のライブラリ等の正常性確認ができないので非常にありがたいもの。
  • メール受信機能がある
    • メールボックス機能はないが、受信メール内容をHTTPSでPOSTしてくれる
      これによって空メール受信によるユーザ登録やチケットを切る等の連携ができる。

良かった点@質問しやすい

濱田さんも書かれている通り、サポートされている方の人数が無料とは思えないくらい多かったです。
それもあっていくつか聞いてみました。

メール送信後のステータスがDeferredの場合、最長72時間再送を試みるがどのようにリトライするのか

  • 例えば、100万通投げて100通リトライになったときのことを考えてみる
    • リトライ間隔はどうなるのか
    • いっきに100通リトライするのか、SendGridがよしなに分割して再送するような制御がはいっていたりするのか
  • リトライ方法の仕様はSendGridでは非公開
    • ただし、以前動きを確認してみたら以下の通りだった。
    • リトライ間隔は最初は短かったが、徐々に間隔が長くなっていった。
    • 宛先に応じてSendGridがよしなにリトライを行う動きをしてた。
      • 仮にリトライの一部が受信できても他のリトライメールが受信できているとはみなせない認識で良いか。
        • その通り。

Stats画面から確認できるステータスはアラートで通知できたりするか

  • 現状ではできない。
    Event WebhookでステータスをDBに貯めておいて、そこから確認するしかない。

悩ましかった点@インフラ視点とアプリ視点でのメリットについて

  • 今回のハンズオンは開発者向けではあるけど、メール運用の経験がない人にとってはDKIMやSPFの意味や、Link BrandingやReverse DNSの良さが伝わりづらいかも。
    口頭ではメール到達率を上げるためと説明してもらえたし、インフラ屋からすると、確かにすげー楽、SendGrid神かな?って思うけど、コードを書くのがメインの人にとってはひょっとしたらイメージがつきづらいかも。
    DNSやメールみたいなものの運用は地味に手間がかかって職人芸なところが出てくるうえにインパクトが大きいから少人数でインフラやってたりする人には結構良いアピールになるんじゃないかなーと思いました。 特にSREみたいにコードを含めてサイトの信頼性を担保しなきゃいけないチームにはかなりハマるんじゃないかなと。 そういう意味ではSRE向けにメールシステム効率化のハンズオン?資料?があっても良いかなーと思いました。

今後やってみたいこと

Elastic Stackと相性良さそうな印象を受けたので、Event Webhookで飛んできたJSONをElasticsearchにいれてKibanaのCanvasに入れて可視化したらマーケティング担当の人に喜ばれそうなのでやってみたい

総括

今まで時間がなくてSendGrid触れていなかったですが、もっと早く触っておけばよかったです。
そしてハンズオンをやってもらえた上に、質問もサクッと答えていただいてありがとうございました!!

SMTPサーバの運用で苦しんでいる人や、メールシステムを効率化したい人は悩みやイメージを持ってハンズオンに参加するときっと幸せになれると思うのでオススメです!

Kibanaのキホンのキ@Elastic stack Advent Calendar 2017 3日目

はじめに

意外とKibanaにフォーカスした記事をみない気がしたので、
今回はKibanaの簡単なハンズオン的なブログを書いていこうと思います。
また、Kibanaの操作にフォーカスを当てるため、それ以外の設定等についてはなるべく簡略化しています。

※書いている最中に記載量が膨大になってきたので、前後編にわけていきます・・・

全体を通して、Elastic Stackでわからないところがあれば、こちらへ質問どうぞ! :) discuss.elastic.co

今回試す構成について

1台のVirtualBox上のサーバで以下ミドルウェアをインストールして試しています。

  • OS:CentOS 7.4 x86-64
  • JDK: jdk1.8-1.8.0_151-fcs
  • Elasticsearch: 6.0.0
  • Metricbeat: 6.0.0
  • Kibana: 6.0.0

構築手順

詳細手順は公式サイト見るのが一番なので、リンクの紹介だけしておきます。

ElasticsearchとKibanaを構築する時のTips

設定の説明は公式サイトにもありますが、
初めて触る方がいきなり全ての英語のドキュメントの意味を把握するのはハードルが高いかと思います。
そのため、ここではよくつまづきそうなポイントだけ紹介します。

Elasticsearch、Kibanaへの接続IPの変更

KibanaやElasticsearchはデフォルトだとlocalhostからしか繋がりません。
VirtualBox等でサーバ構築した上でListen IPを修正するには以下を修正してください。

$ vim /etc/elasticsearch/elasticsearch.yml --cmd "set nu"
  55 #network.host: 192.168.0.155 network.host: _local_,_site_
$ vim /etc/kibana/kibana.yml --cmd "set nu"
  7 #server.host: "localhost"7 server.host: "サーバのIPアドレス"
$

ElasticsearchとMetricbeatの動作確認

Elasticsearchの動作確認

$ curl localhost:9200
{
  "name" : "-kDPg7S",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "8I6dEp6fQhyi2nOcYcBLpA",
  "version" : {
    "number" : "6.0.0",
    "build_hash" : "8f0685b",
    "build_date" : "2017-11-10T18:41:22.859Z",
    "build_snapshot" : false,
    "lucene_version" : "7.0.1",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

Metricbeatの動作確認

MetricbeatはElasticsearchインストール後にインストールして起動するだけでデータがすぐに入ります。

# データが入っていないことを確認
$ curl localhost:9200/_cat/indices

# Metricbeatを起動してデータが入ることを確認
# Index名はKibanaを使うときに使うので覚えておいてください
$ sudo systemctl start metricbeat
$ curl "localhost:9200/_cat/indices?s=index:asc&v"
health status index                       uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   metricbeat-6.0.0-2017.12.01 1aPqivtrTfWKQSFhKEE9gg   1   1        380            0    234.9kb        234.9kb

Tips

  • cat APIについて
    様々なステータスを表示するための便利なAPIです。
    試しに「curl localhost:9200/_cat」を叩いてみると色々出るので試してみてください:)
    また、12/9に@muraken720さんが「cat APIs にまじめに入門する話」というお話をされる予定とのことですので詳細はこちらで乞うご期待!!

Kibanaの基礎設定

IndexをKibanaに認識させる

Elasticsearchへデータ投入も終わったので、Kibanaへログインしてみましょう。 ブラウザに「http://KibanaのサーバのIP:5601」と入力してアクセスしてみます。

画像のように投入したmetricbeatのIndex名を入力します。 f:id:st1t:20171201222013p:plain

Indexが読み込まれると認識されているField名と、データの型が一覧表示されます。 f:id:st1t:20171201222026p:plain

Discoverについて

Indexのデータを表示する画面

Discover画面の概要

f:id:st1t:20171201222055p:plain

Discover画面でデータ詳細を見る

f:id:st1t:20171201225906p:plain

表示させたいFieldを指定する

f:id:st1t:20171201230259p:plain

表示させたいデータをクエリで絞り込む

試しにsystem.process.cmdlineにjavaを含んでいて、system.process.fd.openが10より大きいデータを表示させてみます。
テキストボックスに 「system.process.cmdline: java AND system.process.fd.open: (>10)」と入力してみましょう。 f:id:st1t:20171201231339p:plain

せっかくなので、この検索条件を「search-process-java」として保存してみましょう。
後でDashbordに表示させてみます。 f:id:st1t:20171201232558p:plain

Add a filterを試してみる

上記項目では手動でクエリを書きましたが、
Field名が多かったりすると正確な名前が思い出せないことが多々あります。
また、まずはボタンをぽちぽちして手軽に絞り込みを試したいときもあるかもしれません。
そんなときは「Add a filter」を試してみると良いかもしれません。
複雑な条件はできませんが、単純な値比較等はできます。 f:id:st1t:20171202120603p:plain 上記画像の「is」の部分はFilterが数値型なのか、文字列なのかで項目が変わります。
色々試してみてください:)

Visualizeについて

Discoverで確認したデータをグラフ化するためのものです。
Kibanaを使う上で肝となるVisualizeについですが、
全てのVisualizeを説明するのはページ数が膨大になりますので、
まずはメモリの使用率が多いプロセストップ5を時系列で可視化してみようと思います。
その代わり、なるべく他のVisualizeを使うときでも使いまわしが効くよう解説していきたいと思います。

今回使うVisualize

Create a Visualizationを押して、
今回はAreaチャートでmetricbeat-*のIndex patternを可視化していきます。 f:id:st1t:20171202131734p:plain f:id:st1t:20171202131746p:plain f:id:st1t:20171202131755p:plain

Areaチャートの設定

まず、殆どのVisualizeで共通するMetricsとBucketsという2種類の設定があります。
少し乱暴かとは思いますが、ざっくりと最初のイメージとしては
Metrics=グラフの縦軸
Buckets=グラフの横軸
と思ってもらえれば良いかなと思います。

このイメージを持ってもらった上で今回可視化したいグラフの集計を整理してみます。

可視化したい内容を整理してみる

やりたいこと:メモリの使用量を多く消費しているプロセストップ5を時系列に積み上げグラフで可視化したい

このやりたいことを実際の設定に落とし込むと以下のようなものになります。
この時Buckets内の順番には注意してください。
特にサーバ単位でグラフを分けていてBarグラフを設定した時に大きく変わります。

  1. Metrics
    1. メモリの使用量平均値を表示させる
  2. Buckets(Metricsのデータを細かく集計)
    1. 1.1のデータを時系列に集計
    2. 2.1のデータをプロセス名毎にグラフを分岐させトップ5で絞る
    3. 2.2のデータをホスト単位でデータを分岐させる

Metricsの設定

Aggregationは縦軸で表示させるデータをどのように集計するかを設定するものになります。
今回はメモリ使用量の平均値を表示させたいので、
AggregationはAverageでFiledにsystem.process.memory.rss.byteを使います。
また、Custom Labelを使うことでグラフの縦軸に好きなラベルを設定出来ます。 f:id:st1t:20171202151758p:plain

Bucketsの設定

時系列の集計@X-Axis

横軸は時系列に表示させるため、
X-AxisのAggregationはDate Histogram、Fieldには@timestampを設定します。
また、右上の表示時間帯を変更すると、
IntervalがAutoになっているためデータの表示される粒度が変わります。
より細かい粒度で見たいときはIntervalを秒単位や分単位で設定しても良いかもしれません。
ただし、あまりにも長い期間を表示する時(1ヶ月や半年、1年など)は手動で設定指定も自動でIntervalが設定されるので注意してください。 f:id:st1t:20171202152141p:plain

プロセス名毎にグラフを分岐させトップ5で絞る@Split Series

プロセス名別に表示を分けるため、SubAggregationにTermsとsystem.process.nameを設定します。
TermsはひとまずField名のイメージを持っておいてもらえれば良いかと思います。 f:id:st1t:20171202153422p:plain

ホスト単位でデータを分岐させる@Split Chart

今回は1台分のデータしかElasticsearchへ登録していないのでわかりづらいのですが、
添付画像のように設定すると緑色の枠の部分がホスト単位で複数できるようになります。 f:id:st1t:20171202154829p:plain

Metrics&Axes

Metrics

f:id:st1t:20171202155632p:plain

Y-Axes

Y-Axesは設定項目が多くてスクショできなかったので、
使いそうなところを少しだけ紹介します。 Scale to Data Bounceを設定すると、表示されるデータの下限値が動的に変更されます。
この設定をONにすることによって、桁数の多い数値のデータの変化に気が付きやすくなります。
f:id:st1t:20171202155942p:plain

Panel Settings

Legend Positionを設定するとプロセス名の部分を別の場所に表示することが出来ます。
横枠を少しでも広げたい方には設定しても良いかなと思います。
また、ちょっとわかりづらいですが、X-Axis LinesやY-Axis Linesを設定するとグラフの後ろに縦線や横線を設定することも出来ます。 f:id:st1t:20171202190322p:plain

保存しておく

作成したグラフをDiscoverのときと同じように保存しておきます。
ここではused-memory-processとしておきます。 f:id:st1t:20171202190844p:plain

Tips

グラフからElasticsearchへのクエリを確認する

私はElasticsearchのクエリの書き方を忘れることがあるのですが、そんなときはVisualizeからクエリを確認したりしています。
f:id:st1t:20171202232408p:plain f:id:st1t:20171202232452p:plain f:id:st1t:20171202232622p:plain

グラフのデータをCSVでダウンロードする

上記のクエリ確認の画面と同じように、Visualizeの左下に出てくる小さい三角を押して、ExportのRawかFormattedを使うことでCSVファイルをダウンロード出来ます。
f:id:st1t:20171202232408p:plain f:id:st1t:20171202232759p:plain

Dashbordについて

DiscoverやVisualizeで保存したものをまとめて表示させます。

Visualizeを追加する

f:id:st1t:20171202191329p:plain

Discoverで保存した検索を追加する

f:id:st1t:20171202192040p:plain

ダッシュボードの色を白から黒に変更してみる

f:id:st1t:20171202192008p:plain

次回予告

残念ながら本来書こうと思っていた詳細は全然書ききれませんでした・・・
KibanaだけでもVisualbuilder、Dev Tools、Grok Debugger、LogstashのPipilineの処理時間の可視化などなど紹介したい機能はたくさんあります。
他にもVisualizeを使ううえでログの設計や送信する際に考えておくべき箇所などなど。
今月のAdvent Calendarが最後の方まで残っていたら追加別記事にTips集的な感じで書こうと思います。
明日は@_bsooさんから書いていただけるようですので、乞うご期待!!

builderscon tokyo 2017行ってきた@前夜祭編

行ってきました、builderscon、略してびるこん。

builderscon.io


今日は前夜祭なので18時から慶應義塾大学日吉キャンパスの協生館にお邪魔しました。

f:id:st1t:20170803220908j:plain
みんなだいすきカジュアルウォーター👍

【前夜祭】オンプレミスデータセンター撤退! - 大人のビルコン 〜撤退技術スペシャル〜(1)

すごーい!
後半は自分も同じような経験が・・・うっ、頭がっ

【前夜祭】データストア撤退の歴史 - 大人のビルコン 〜撤退技術スペシャル〜(2)

すごーい!
昔よく怪我したなぁ・・・

【前夜祭】PaaS完全撤退の歴史 - 大人のビルコン 〜撤退技術スペシャル〜(3)

すごーい!
かなしみ。合掌。
でもどこかでバトンが渡ってると思うと良いおはなし。

【前夜祭】ブロックストレージとの戦い、そして撤退 - 大人のビルコン 〜撤退技術スペシャル〜(4)

すご・・・やべえ
信頼関係って大事。
内容はたぶんインフラ屋さんならあるあるネタかな。
うっ、お腹が痛い・・・。

というわけで、非常に充実した前夜祭でした!!
前夜祭の内容は完全オフレコなので書けませんでした、すいません!!

見た人にだけわかるように一言だけ感想書いときました。
題名の下に白文字で書いたので反転して見てください😇
懐かしいと思った人はきっとインターネット老人

明日はもう少しきちんと書きます💪

先日起きたNetwork疎通のおはなし@自戒をこめて

ある日のこと

Aさん「んー?切り出したサーバがpingすら上手く通らない。。。Firewall絡みかな?」
自分「telnetでつなげて対向先サーバでtcpdumpしてパケットは来てる?」
Aさん「来ていますね」
自分「iptablesは?」
Aさん「落としてます」
自分「んー・・・?デフォゲも設定&疎通出来ているされているしな・・・はて・・・」

先日こんなことがあったのですが、
わかると単純なんですがハマってしまって解決するのに30分ほどかかってしまいました。
恐らくわかる方はすぐわかってしまうかと思います。
自戒をこめて今回書き記しておこうと思います。

状況を整理すると以下の通り。

接続イメージ

Xサーバ(データ送信元) -> 🔥Firewall🔥 -> Zサーバ(データ送信先)

聞き取り調査状況

  • XとZサーバはNWセグメントは別
  • XからZサーバへpingを投げても応答を返さない。また、その逆のZからXサーバも応答が返ってこない。
  • Xサーバからtelnet接続するとtcpdumpで見る限りパケットはZサーバに問題なく来ている
  • ZサーバでiptablesはOFFにしている
  • X及びZサーバのデフォルトゲートウェイ(以下DG)は適切に設定されている。また、DGに対してpingは返ってくる
  • Zサーバでtsharkでパケットの中身を眺めてみても異常はなさそう

その後...

自分「んー・・・iptablesは切ってるし、そもそもパケットフィルタが原因ならtcpdump上は返すように見えると思うんだよなぁ」
自分「そもそも自分のパケットと認識していないような挙動だし・・・」

Xサーバ以外のNWからpingを投げてみたら応答が返ってきました。
ここまでを振り返ると、どうやらFirewallやpingそのものがおかしいわけではなさそうでした。

ふと何気なくルーティングを見ていたら、

自分「ん?XサーバのNWアドレスとバッティングしたNWアドレスがZサーバ内のブリッジに向けてある・・・なんだこりゃ」
ex. XサーバのNWアドレス(192.168.0.0/24)、Zサーバ内のルーティング(192.168.0.0/16)のようなイメージ

ということで、
応答を返さない原因はルーティングテーブルが原因でした。
後にAさんに事情を聞いてみたところ、
どうやらコンテナを設定するのに以前使っていたのが残ったままになってしまっていたようでした。
既に使っていなかったようで、削除してもらったら無事に疎通出来るようになりました。

ここまでは単なるルーティングミスのおはなしですが、
ふと思いました。
時間かけすぎてしまった、と。
ここからは、どうしたらもっと早く気がつけたのか振り返ってみようと思います。

振り返り

  1. DGの設定確認したときに、ルーティングテーブルもきちんと見るべきだった
  2. FWやiptables等のパケットフィルタは調査当初から問題なさそうという認識はあったが、いまいち断言しきれずにtsharkでパケットの中身を見ることを優先しすぎてしまった
  3. パケットが着信しているにもかかわらず自分のものと認識していないのはアプリレイヤの設定に何かあるのかと壮大な勘違いをしていた

正直1を徹底するにつきてしまうのですが、
3も個人的に結構な反省点だと思っています。

もっとパケットの気持ちになって
デバイス -> Kernel -> ユーザランドでどういう風にデータが流れていくのか、
そもそも、パケットフィルタとルーティングの処理される位置関係がどうだったのか
再認識してみようとおもいます。

Linux Kernel Networkingについて

www.slideshare.net

こちらのスライドのp.40を見るとデバイスに着信してから上位レイヤに渡されるまでの概要が記載されています。

せっかくですので、linux-3.10.105のip_input.cの中身を追いかけて書いていたのですが、
別のブログで既に整理して記載がありましたのでここではご紹介に留めておこうと思います。

ip_input.cを見てからブログを拝見するとスッキリしました。

enakai00.hatenablog.com

その他参考

ElasticsearchでXFSとBtrfsを容量削減目的で比較してみた

Elasticsearchでなるべく長期間データ保存をしておきたいけど、データ容量が結構大きい。。。
ということで、圧縮できないかXFSとBTrfsを試してみました。

目的

  • データ圧縮してストレージ容量の削減をしたい

観点

  • どの程度容量が圧縮されるのか
  • 検索速度はどの程度違うのか
  • 負荷はどのレイヤがどの程度変わるのか

注意

今回紹介するBtrfsの圧縮機能の状態はまだmostly OKなので利用時はデータの破損等自己責任でお願いします。
備考には(needs verification and source) auto-repair and compression may crashとの記載あり。
Status - btrfs Wiki

XFSとBtrfsについて

各ファイルシステムの紹介は細かく記載してくださっているサイトがあるので、
ご紹介程度にとどめておきます。

試したファイルシステムの設定種類

サーバ名 OS Instance Type ファイルシステム ファイルシステムオプション(fstab)
ec2-xfs-default CentOS Linux release 7.2.1511 t2.medium xfs defaults
ec2-btrfs-default CentOS Linux release 7.2.1511 t2.medium btrfs defaults
ec2-btrfs-force-lzo CentOS Linux release 7.2.1511 t2.medium btrfs noatime,autodefrag,compress-force=lzo,space_cache
ec2-btrfs-force-zlib CentOS Linux release 7.2.1511 t2.medium btrfs noatime,autodefrag,compress-force=zlib,space_cache

試した環境イメージ

f:id:st1t:20170408162353p:plain

投入したデータについて

ec2-dsrc01,02からmetricbeatを使って毎秒以下の通りデータを投入。

$ sudo cat /etc/metricbeat/metricbeat.yml
metricbeat.modules:

#------------------------------- System Module -------------------------------
- module: system
  metricsets:
    # CPU stats
    - cpu

    # System Load stats
    - load

    # Per CPU core stats
    - core

    # IO stats
    - diskio

    # Per filesystem stats
    - filesystem

    # File system summary stats
    - fsstat

    # Memory stats
    - memory

    # Network stats
    - network

    # Per process stats
    - process

    # Sockets (linux only)
    - socket
  enabled: true
  period: 1s
  processes: ['.*']

ディスク容量の推移

f:id:st1t:20170408164453p:plain
ec2-xfs-defaultとec2-btrfs-defaultではあまり大きな容量の差は見られませんでした。
しかし、ec2-btrfs-force-lzoはec2-btrfs-defaultと比較して3割強、
ec2-btrfs-force-zlibに至っては6割のデータ容量が削減されていることが確認できました。

CPU使用率(USER)の推移

f:id:st1t:20170412200544p:plain
予想に反してbtrfs-zlibの使用率が低い結果になりました。
※全台たまに使用率が跳ねているのは恐らくSegment Mergeが起きていたのではないかと思います。
今回は検証の範囲外のため行っていませんが、もし本当にSegment Mergeであるか確認するなら、
_cluster/settingsのindices.store.throttle.max_bytes_per_sec等を修正すると影響があるかもしれません。

www.elastic.co
blog.mikemccandless.com

簡単なクエリを投げ続けてみた

以下のような直近1日のCPU使用率を取得するクエリを投げてみました。
なお、get-cpu.shを叩く前に全台Elasticsearchを再起動してメモリキャッシュをクリアさせています。

get-cpu.sh

#!/bin/bash

LOG=/tmp/get-average-cpu-24hour-`date +%Y%m%d-%H%M%S`.log

# Warmup
date >> $LOG
echo "start warmup." >> $LOG
for i in {1..500}
do
  (time curl -s -XGET {{ ansible_default_ipv4.address }}:9200/metricbeat-*/_search -d @get-average-cpu-24hour.json | jq .) > /dev/null 2>&1
done
date >> $LOG
echo "stop warmup." >> $LOG

date >> $LOG
echo "sleep 1m." >> $LOG
sleep 60
date >> $LOG

# exe
date >> $LOG
echo "start benchmark." >> $LOG
for i in {1..1000}
do
  (time curl -s -XGET {{ ansible_default_ipv4.address }}:9200/metricbeat-*/_search -d @get-average-cpu-24hour.json | jq .) 2>&1 | grep ^real >> $LOG
done
date >> $LOG
echo "stop benchmark." >> $LOG

get-average-cpu-24hour.json

{ 
  "size": 0,
  "query": {
    "bool": {
      "must": [
        { 
          "query_string": {
            "query": "*",
            "analyze_wildcard": true
          }
        },
        { 
          "range": {
            "@timestamp": {
              "gte": 1491554333990,
              "lte": 1491640733990,
              "format": "epoch_millis"
            }
          }
        }
      ],
      "must_not": []
    }
  },
  "_source": {
    "excludes": []
  },
  "aggs": {
    "2": {
      "date_histogram": {
        "field": "@timestamp",
        "interval": "30m",
        "time_zone": "Asia/Tokyo",
        "min_doc_count": 1
      },
      "aggs": {
        "1": {
          "avg": {
            "field": "system.process.cpu.total.pct"
          }
        }
      }
    }
  }
}

実行時間

トータル実行時間

btrfsは一度読み込むとメモリ乗っかるせいか、
圧縮オプションによる実行時間はほとんど変わりませんでした。
XFSは2倍強くらいになってしまいました。。。

サーバ名 実行時間
ec2-btrfs-force-zlib 1m 55s
ec2-btrfs-default 1m 56s
ec2-btrfs-force-lzo 1m 56s
ec2-xfs-default 4m 51s
単一実行時間の散布図

f:id:st1t:20170410120406p:plain
縦軸:処理時間(秒)
横軸:回数

CPU負荷のかかり方(USER)

f:id:st1t:20170412204854p:plain
ユーザランドのCPU使用率だけ見てみると全台綺麗にCPUを使い切っていて、
負荷のかかりかた自体は大きな違いがあるようではなさそうでした。

DISK IOの負荷のかかり方

f:id:st1t:20170412203632p:plain

  • 11:54 - 11:56周辺の山:Elasticsearchを再起動実施タイミング
  • 11:59 - 12:01周辺の山:ベンチマーク中

DISKの圧縮が効いていればいるほどDISKのIO Waitが小さく、かつIOが出ているようです。

参考:timelionのクエリ(ec2-xfs-default)

※以下クエリは意図的になるべく見やすくするために意図的に改行を付加してますが、
実際はワンライナーで記載する必要があります。

(
  .subtract(
    .es(index=metricbeat-*,metric=max:system.diskio.read.count,q=beat.hostname:ec2-xfs-default),
    .es(index=metricbeat-*,metric=max:system.diskio.read.count,q=beat.hostname:ec2-xfs-default,offset=-1s)
  ).label("ec2-xfs-default:read i/o"),
  .subtract(
    .es(index=metricbeat-*,metric=max:system.diskio.write.count,q=beat.hostname:ec2-xfs-default),
    .es(index=metricbeat-*,metric=max:system.diskio.write.count,q=beat.hostname:ec2-xfs-default,offset=-1s)
  ).label("ec2-xfs-default:write i/o")
).bars(width=1).yaxis(1,max=1500,label="DISK IO Count"),
.multiply(
  .es(index=metricbeat-*,metric=max:system.cpu.iowait.pct,q=beat.hostname:ec2-xfs-default),
  100
).lines(width=1).label("ec2-xfs-default:cpu i/o wait").yaxis(2,max=100,label="CPU IO wait(%)")

念のため3回ほど回してみた

f:id:st1t:20170412204234p:plain
DISKやCPUの負荷傾向は同じ傾向となりました。

結論

  • btrfsをデフォルト設定で使ってもDISK容量削減だと意味がなさそう
    • 圧縮率を求めるならcompress-forceでlzoかzlibを使う必要がある
  • 今回みたいな小さいクエリの場合はXFSよりBtrfsのほうが早い模様
    • なぜそうなるのかが追求できていないので全体的な傾向としてBtrfsが早いのか、今回の条件に限りなのかは要確認