Tweet
Tweet

Slide 1

Slide 1 text

Elastic Stack で 何を可視化すれば性能改善が捗るのか 株式会社スタディスト　北野 勝久 2017/10/11 (水) 第21回 Elasticsearch 勉強会 #elasticsearchjp

Slide 2

Slide 2 text

自己紹介 インドのIT企業で2年半ほど働いた後、 スタディストで、SRE らへんの仕事をしています。 北野 勝久 katsuhisa91 https://github.com/katsuhisa91 Katsuhisa Kitano https://www.facebook.com/katsuhisa.kitano.33 @katsuhisa__ https://twitter.com/katsuhisa__ #elasticsearchjp

Slide 3

Slide 3 text

会社紹介 スタディストという会社からきました。 『Teachme Biz 』というサービスを つくっています。 #elasticsearchjp 弊社のゆるキャラ『マロン』

Slide 4

Slide 4 text

今日のゴール 今日聞いてくださったみなさんが、Elastic Stack を活用して、 1. 〜10/20 (金) ： 性能可視化が完了 2. 11/ 1 (水) 〜 ： 可視化したグラフを見ながら 性能改善に着手開始 できるようになる！ #elasticsearchjp

Slide 5

Slide 5 text

Agenda 性能監視の話 Elasticsearch 導入の詳細 今後の活用 #elasticsearchjp

Slide 6

Slide 6 text

Agenda 性能監視の話 Elasticsearch 導入の詳細 今後の活用 #elasticsearchjp

Slide 7

Slide 7 text

突然ですが、SRE という言葉をご存知ですか？ #elasticsearchjp

Slide 8

Slide 8 text

SRE （Site Reliability Engineering）とは サイトの信頼性に関するエンジニアリングのこと （そのまま） #elasticsearchjp

Slide 9

Slide 9 text

SRE （Site Reliability Engineering）とは サイトの信頼性に関する会話の一例 ● あれ、なんかこのサイト、レスポンス遅くね？ ● チケット申し込もうと思ったら、Web サイト開けなくなっちゃった ● このサイトのSLA は、稼働率99.9% なんだ〜 #elasticsearchjp

Slide 10

Slide 10 text

SRE （Site Reliability Engineering）とは サイトの信頼性を守ったり、より高めたりするお仕事 #elasticsearchjp

Slide 11

Slide 11 text

SRE とモニタリング 「　Googleであれどこであれ、 　　モニタリングはプロダクション環境で 　　やるべきことの中で絶対に欠かせない要素です　」 　※ちなみに英語版は、以下から無料で読めます。 　　http://landing.google.com/sre/book/index.html #elasticsearchjp

Slide 12

Slide 12 text

SRE とモニタリング 「　サービスをモニタリングしていなければ、 　　何が起きているのかを知ることができず、 　　何が起きているのかが見えていなければ、 　　信頼性を保つことはできません。　　　　」 #elasticsearchjp

Slide 13

Slide 13 text

モニタリング大事 #elasticsearchjp

Slide 14

Slide 14 text

では、何を見ればよいのか？ #elasticsearchjp

Slide 15

Slide 15 text

The Four Golden Signals #elasticsearchjp

Slide 16

Slide 16 text

The Four Golden Signals The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four. http://landing.google.com/sre/book/chapters/monitoring-distributed-systems.html #elasticsearchjp

Slide 17

Slide 17 text

The Four Golden Signals （訳） Google さんが 「とりあえず、この4つだけ集中して見ておけばいいよ」 って言ってます。 #elasticsearchjp

Slide 18

Slide 18 text

The Four Golden Signals 1. latency 2. traffic 3. errors 4. saturation #elasticsearchjp

Slide 19

Slide 19 text

The Four Golden Signals 1. latency 2. traffic 3. errors 4. saturation ← How "full" your service is. (e.g., in a memory-constrained system, show memory; in an I/O-constrained system, show I/O) #elasticsearchjp

Slide 20

Slide 20 text

The Four Golden Signals 1. latency 2. traffic 3. errors 4. saturation ← How "full" your service is. (e.g., in a memory-constrained system, show memory; in an I/O-constrained system, show I/O) どれだけサービスがカツカツかを 示す指標 #elasticsearchjp

Slide 21

Slide 21 text

The Four Golden Signals 1. latency 2. traffic 3. errors 4. saturation この4つをいい感じに 測りたい。 #elasticsearchjp

Slide 22

Slide 22 text

The Four Golden Signals 1. latency 2. traffic 3. errors 4. saturation 今すぐ簡単に測れます #elasticsearchjp

Slide 23

Slide 23 text

#elasticsearchjp

Slide 24

Slide 24 text

#elasticsearchjp ・・・の前に少しだけ脱線

Slide 25

Slide 25 text

#elasticsearchjp

Slide 26

Slide 26 text

NewRelic を使う ● エージェントを入れる。以上。 いい感じのグラフがすぐ出ます。控えめに言って最高。 ● もともと性能改善に特化したモニタリングツールなので、 今日のテーマに関するようなメトリクスが、かんたんに見れる。 #elasticsearchjp

Slide 27

Slide 27 text

が、しかし、 ● ログ保管期間が短い（有料プランの最長でも90日） ● 有料プラン高い。 7〜8台にエージェント導入すると、すぐに80,000円 / 月 とか。 （インスタンスサイズ / 利用プランで値段が変わります。） 以下ページで、APM というNewRelic 主力製品の料金を見積もれます。 https://newrelic.com/application-monitoring/pricing #elasticsearchjp

Slide 28

Slide 28 text

ということで弊社では・・・ ● 無料プラン利用中 ● 他監視ツールの補助的な立ち位置＆ アラートを活用 （最近はほぼ見てないです。昔はよくお世話になりました。） ※ NewRelic は料金体系と製品群が複雑なので、以下を要参照。 　 https://qiita.com/kumatronik/items/e2e09bd3708b00442d9b #elasticsearchjp

Slide 29

Slide 29 text

他にもいくつかの監視ツールを併用 ● いい感じにやってくれる部分が、監視ツールによって違う ● 集約したい気持ちはあるけど、 そこに時間をかけても 目の前の性能改善施策が捗るわけじゃない。 ● このあたりの全体像や、今後の方針は、懇親会でぜひ。 #elasticsearchjp

Slide 30

Slide 30 text

Agenda 性能監視の話 Elasticsearch 導入の詳細 今後の活用 #elasticsearchjp

Slide 31

Slide 31 text

遠回りしましたが、 #elasticsearchjp

Slide 32

Slide 32 text

なぜElasticsearch ？ ● 自分たちで見たい指標を決めて実装すれば、ちゃんと見れる。 （SaaS 型の監視ツールは、楽に、勝手に、可視化してくれるが、 　自分たちが見たいグラフをつくりにくいケースがある。） ● 他にも・・・ ● なんとなくかっこよくてすき ● 今後、他の分野（検索）でも活用したいから、さわってみたかった #elasticsearchjp

Slide 33

Slide 33 text

Elastic Stack の利用 投入データ ● Nginx アクセスログ ● DB のSlowQuery ログ（弊社は、AWS Aurora を利用） ※ Aurora については、以前、別の勉強会でお話しました。 　ご興味ある方はどうぞ！ 　https://speakerdeck.com/katsuhisa91/rds-for-mysql-aurora-yi-xing-falsesubete #elasticsearchjp

Slide 34

Slide 34 text

Elastic Stack の利用 どこに使っているか？ ● レスポンス時間のパーセンタイル表示 ● 正規化済みURIごとのレスポンス時間（レスポンス時間が大きい順） ● 正規化済みURI ごとのカウント数（レスポンス時間が大きい順） ● HTTP ステータスコードの割合 ● スロークエリの表示 ● アクセス元の位置情報表示 #elasticsearchjp

Slide 35

Slide 35 text

Elastic Stack の利用 どこに使っているか？ ● レスポンス時間のパーセンタイル表示 ● 正規化済みURIごとのレスポンス時間（レスポンス時間が大きい順） ● 正規化済みURI ごとのカウント数（レスポンス時間が大きい順） ● HTTP ステータスコードの割合 ● スロークエリの表示 ● アクセス元の位置情報表示 サービス全体の性能を見るために利用 #elasticsearchjp

Slide 36

Slide 36 text

Elastic Stack の利用 どこに使っているか？ ● レスポンス時間のパーセンタイル表示 ● 正規化済みURIごとのレスポンス時間（レスポンス時間が大きい順） ● 正規化済みURI ごとのカウント数（レスポンス時間が大きい順） ● HTTP ステータスコードの割合 ● スロークエリの表示 ● アクセス元の位置情報表示 基本的に性能改善で使いたい時は、 パーセンタイル表示で見ましょう #elasticsearchjp

Slide 37

Slide 37 text

Average を見るよりサービスの状態 / 改善効果が、分かりやすい。 例：スロークエリをつぶせば、99%tileが下がった 　　99%tileが1s 以内レスポンスを目標にしよう、など。 #elasticsearchjp

Slide 38

Slide 38 text

Elastic Stack の利用 どこに使っているか？ ● レスポンス時間のパーセンタイル表示 ● 正規化済みURI ごとのレスポンス時間（レスポンス時間が大きい順） ● 正規化済みURI ごとのカウント数（レスポンス時間が大きい順） ● HTTP ステータスコードの割合 ● スロークエリの表示 ● アクセス元の位置情報表示 サービスの性能における ボトルネックを探すために利用 #elasticsearchjp

Slide 39

Slide 39 text

Elastic Stack の利用 どこに使っているか？ ● レスポンス時間のパーセンタイル表示 ● 正規化済みURI ごとのレスポンス時間（レスポンス時間が大きい順） ● 正規化済みURI ごとのカウント数（レスポンス時間が大きい順） ● HTTP ステータスコードの割合 ● スロークエリの表示 ● アクセス元の位置情報表示 ここを統一させることが、 ボトルネックの探索において重要 #elasticsearchjp

Slide 40

Slide 40 text

呼び出し回数が大きいリクエストは、 改善効果が出やすい。 #elasticsearchjp

Slide 41

Slide 41 text

呼び出し回数が小さいリクエストは、 改善効果が出やすい。 #elasticsearchjp

Slide 42

Slide 42 text

Elastic Stack の利用 どこに使っているか？ ● レスポンス時間のパーセンタイル表示 ● 正規化済みURIごとのレスポンス時間（レスポンス時間が大きい順） ● 正規化済みURI ごとのカウント数（レスポンス時間が大きい順） ● HTTP ステータスコードの割合 ● スロークエリの表示 ● アクセス元の位置情報表示 サービス全体の健全度を見るために利用。 円グラフで5XX の割合出したり、 割合の推移を追うグラフを出したり。 #elasticsearchjp

Slide 43

Slide 43 text

Elastic Stack の利用 どこに使っているか？ ● レスポンス時間のパーセンタイル表示 ● 正規化済みURIごとのレスポンス時間（レスポンス時間が大きい順） ● 正規化済みURI ごとのカウント数（レスポンス時間が大きい順） ● HTTP ステータスコードの割合 ● スロークエリの表示 ● アクセス元の位置情報表示 ボトルネックの探索に利用 #elasticsearchjp

Slide 44

Slide 44 text

Elastic Stack の利用 どこに使っているか？ ● レスポンス時間のパーセンタイル表示 ● 正規化済みURIごとのレスポンス時間（レスポンス時間が大きい順） ● 正規化済みURI ごとのカウント数（レスポンス時間が大きい順） ● HTTP ステータスコードの割合 ● スロークエリの表示 ● アクセス元の位置情報表示 唐突に謎リクエストが増えたら、 アクセス元をそれとなく把握するために活用予定 （幸い、今は謎攻撃を受けていないため未活用） #elasticsearchjp

Slide 45

Slide 45 text

The Four Golden Signalsが見える！見えるぞ・・・！ #elasticsearchjp

Slide 46

Slide 46 text

レスポンス時間 × カウント数の大きいところから 着手すれば、結果も出やすい。 みんなが性能改善で良い結果を出せますように。 #elasticsearchjp

Slide 47

Slide 47 text

結果が出ることに集中して、盛大に実績をアピール（信頼残高の貯金） ⇩ なんかElasticsearh というのを 使って性能可視化しているらしい。 ⇩ 検索エンジンとしても使いたいです！ ちょっと高いけど、Elastic Cloud っていう楽できるやつ使いたいです！ ⇩ すでに別のところでElasticsearch 使用実績あるっぽいし、いいよ ⇩ ワイ、歓喜 #elasticsearchjp

Slide 48

Slide 48 text

Agenda 性能監視の話 Elasticsearch 導入の詳細 今後の活用 #elasticsearchjp

Slide 49

Slide 49 text

でも、導入たいへんなんでしょう？ #elasticsearchjp

Slide 50

Slide 50 text

いえ、3日でぜんぶ終わりました。 （今やり直すなら、たぶん1日でぜんぶ終わります。） #elasticsearchjp

Slide 51

Slide 51 text

（大したことはやっていませんが、） 詳細をすべてお見せします。 詳しい人いたら、もっと良いやり方を教えてください。 #elasticsearchjp

Slide 52

Slide 52 text

構成 EC2 ( WebApp ) EC2 ( WebApp ) EC2 ( LogAggregator ) Amazon RDS ( Aurora ) Nginx Access Log Nginx Access Log Slow Query Log #elasticsearchjp

Slide 53

Slide 53 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる #elasticsearchjp

Slide 54

Slide 54 text

EC2 ( WebApp ) EC2 ( WebApp ) EC2 ( LogAggregator ) #elasticsearchjp Amazon RDS ( Aurora ) 1. 環境構築＆ダッシュボードへのアクセス制限

Slide 55

Slide 55 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる AWS Elasticsearch Service を利用すれば、 すぐ終わります。 #elasticsearchjp

Slide 56

Slide 56 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる AWS Elasticsearch Service を利用すれば、 すぐ終わります。 ・AWS Elasticsearch Service を使うメリット 　現状、AWS を利用しているのであれば、権限管理がとにかく楽 ・AWS Elasticsearch Service を使うデメリット 　EC2 に直接インストールして使うよりかは割高 　最新バージョンのElasticsearch への追従が今後しんどいらしい #elasticsearchjp

Slide 57

Slide 57 text

EC2 ( WebApp ) EC2 ( WebApp ) EC2 ( LogAggregator ) Amazon RDS ( Aurora ) #elasticsearchjp 2. Nginx のログ形式を変更

Slide 58

Slide 58 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる これもNginx のconfig 書き直すだけなので、 すぐ終わります。（LTSV に変更。） #elasticsearchjp

Slide 59

Slide 59 text

EC2 ( WebApp ) EC2 ( WebApp ) EC2 ( LogAggregator ) Amazon RDS ( Aurora ) Slow Query Log #elasticsearchjp 3. Slow Query Log を受け取る

Slide 60

Slide 60 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる fluentd プラグインを導入して、 データベース接続の認証情報を書くだけ。 #elasticsearchjp

Slide 61

Slide 61 text

EC2 ( WebApp ) EC2 ( WebApp ) EC2 ( LogAggregator ) Amazon RDS ( Aurora ) Nginx Access Log Nginx Access Log Slow Query Log #elasticsearchjp 4. ログを受け取って渡す＆加工

Slide 62

Slide 62 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる ● fluentd の基本的な設定 #elasticsearchjp

Slide 63

Slide 63 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる ● Elasticsearch にデータ投入するための、 IAM設定（AWS の場合） ● Elasticsearch と認証情報の受け渡しをする fluentd プラグインを導入 #elasticsearchjp

Slide 64

Slide 64 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる ● URI の不要情報をぬりつぶすため、正規表現を書く ● geoip （IPアドレス ⇔ 位置情報）の fluentd プラグインを入れる #elasticsearchjp

Slide 65

Slide 65 text

EC2 ( WebApp ) EC2 ( WebApp ) EC2 ( LogAggregator ) Amazon RDS ( Aurora ) Nginx Access Log Nginx Access Log Slow Query Log #elasticsearchjp 5. Kibana の設定

Slide 66

Slide 66 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる ● geoip プラグインで追加した データの型をgeo_point に指定する ● not_analyzed 設定で、 インデックスの要素解析無効化 #elasticsearchjp

Slide 67

Slide 67 text

実際にやったこと ● Elasticsearch / Kibana 環境構築 ● Kibanaへのアクセス制限 ● Nginx アクセスログの出力形式変更 ● SlowQuery 取得設定（fluentd plugin） ● fluentd のセットアップ ○ 受け取って渡す当たり前のことをやらせる設定 ○ Elasticsearch に送信する認証情報設定 ● ログ加工する設定（正規表現 / geoip 導入とかとか） ● Kibana にtemplate入れる ● Kibana でダッシュボードつくる ぽちぽちやる。 #elasticsearchjp

Slide 68

Slide 68 text

ハマったこと あんまりない気がする。 認証情報の書き方が間違っているのに気付かずに、 1時間詰まったとか、そのくらい。 強いて言うなら、やりたいことを実現するための プラグインを探すのが多少めんどうだった。 #elasticsearchjp

Slide 69

Slide 69 text

ハマったこと というわけで、使ったプラグインを公開しておく。 ● fluent-plugin-aws-elasticsearch-service AWS Elasticsearch Service にログを送るための 認証情報の受け渡しをよしなにやってくれる ● fluent-plugin-rds-slowlog データベースからスロークエリのログを抜く ● fluent-plugin-parser 見ての通り、受け取ったログをparse させる ● fluent-plugin-filter_typecast 見ての通り、typecast するプラグイン ● fluent-plugin-geoip 見ての通り、geoip のプラグイン ● fluent-plugin-record-reformer 正規表現で加工済みのフィールドを追加するために導入 みんなが幸せにログ分析できますように。 #elasticsearchjp

Slide 70

Slide 70 text

まとめ Elastic Stack で何を可視化すれば性能改善が捗るのか ⬇ The Four Golden Signals を見よう ⬇ 具体的には、 1. 「レスポンス時間のパーセンタイル表示」 2. 「URI ごとのレスポンス時間＆呼出回数表示」 3. 「HTTP ステータスコードの割合」 あたりを可視化するのがオススメ。 #elasticsearchjp

Slide 71

Slide 71 text

まとめ また、実装は3日あれば終わるボリュームです。 これは、素晴らしいfluentd プラグインを公開してくださっている 偉人たちのおかげです。 彼らに感謝しつつ、 今すぐElastic Stack でログ可視化をはじめましょう。 #elasticsearchjp

Slide 72

Slide 72 text

今日のゴール（おさらい） 今日聞いてくださったみなさんが、Elastic Stack を活用して、 1. 〜10/20 (金) ： 性能可視化が完了 2. 11/ 1 (水) 〜 ： 可視化したグラフを見ながら 性能改善に着手開始 できるようになる！ #elasticsearchjp

Slide 73

Slide 73 text

今日のゴール（おさらい） 今日聞いてくださったみなさんが、Elastic Stack を活用して、 1. 〜10/20 (金) ： 性能可視化が完了 2. 11/ 1 (水) 〜 ： 可視化したグラフを見ながら 性能改善に着手開始 できるようになる！ #elasticsearchjp たぶんできます。 （なぜなら、うちもほんの三ヶ月前は、 　Elasticsearch 導入検討すらしていなかったから。）

Slide 74

Slide 74 text

Agenda 性能監視の話 Elasticsearch 導入の詳細 今後の活用 #elasticsearchjp

Slide 75

Slide 75 text

今後の活用 ● useragent を分類して、 どのプラットフォームからのアクセスかを出し分けたい ● Kibana の運用ルールや認証強化（セキュリティ面） ● 検索エンジンとしてElasticsearch を導入したい #elasticsearchjp

Slide 76

Slide 76 text

今後の展望 ● useragent を分類して、 どのプラットフォームからのアクセスかを出し分けたい ● Kibana の運用ルールや認証強化（セキュリティ面） ● 検索エンジンとしてElasticsearch を導入したい と、いう感じのことができる人Wanted!! #elasticsearchjp

Slide 77

Slide 77 text

We are hiring!!! #elasticsearchjp

Slide 78

Slide 78 text

We are hiring!!! #elasticsearchjp

Slide 79

Slide 79 text

ご清聴ありがとうございました！ 採用にご興味ある方は、 お気軽にご連絡ください！ スタディスト 北野 勝久 katsuhisa.kitano@studist.jp ご清聴ありがとうございました #elasticsearchjp