Elastic Stack で 何を可視化すれば性能改善が捗るのか?

C0479b152c326746e911be790617f75b?s=47 katsuhisa_
October 11, 2017

Elastic Stack で 何を可視化すれば性能改善が捗るのか?

2017/10/11 (水) 第21回Elasticsearch 勉強会で話したスライドです。
https://www.meetup.com/Tokyo-Elastic-Fantastics/events/243671140/

C0479b152c326746e911be790617f75b?s=128

katsuhisa_

October 11, 2017
Tweet

Transcript

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

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

    https://www.facebook.com/katsuhisa.kitano.33 @katsuhisa__ https://twitter.com/katsuhisa__ #elasticsearchjp
  3. 会社紹介 スタディストという会社からきました。 『Teachme Biz 』というサービスを つくっています。 #elasticsearchjp 弊社のゆるキャラ『マロン』

  4. 今日のゴール 今日聞いてくださったみなさんが、Elastic Stack を活用して、 1. 〜10/20 (金) : 性能可視化が完了 2.

    11/ 1 (水) 〜 : 可視化したグラフを見ながら 性能改善に着手開始 できるようになる! #elasticsearchjp
  5. Agenda 性能監視の話 Elasticsearch 導入の詳細 今後の活用 #elasticsearchjp

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

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

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

  9. SRE (Site Reliability Engineering)とは サイトの信頼性に関する会話の一例 • あれ、なんかこのサイト、レスポンス遅くね? • チケット申し込もうと思ったら、Web サイト開けなくなっちゃった

    • このサイトのSLA は、稼働率99.9% なんだ〜 #elasticsearchjp
  10. SRE (Site Reliability Engineering)とは サイトの信頼性を守ったり、より高めたりするお仕事 #elasticsearchjp

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

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

  13. モニタリング大事 #elasticsearchjp

  14. では、何を見ればよいのか? #elasticsearchjp

  15. The Four Golden Signals #elasticsearchjp

  16. 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
  17. The Four Golden Signals (訳) Google さんが 「とりあえず、この4つだけ集中して見ておけばいいよ」 って言ってます。 #elasticsearchjp

  18. The Four Golden Signals 1. latency 2. traffic 3. errors

    4. saturation #elasticsearchjp
  19. 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
  20. 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
  21. The Four Golden Signals 1. latency 2. traffic 3. errors

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

    4. saturation 今すぐ簡単に測れます #elasticsearchjp
  23. #elasticsearchjp

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

  25. #elasticsearchjp

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

  27. が、しかし、 • ログ保管期間が短い(有料プランの最長でも90日) • 有料プラン高い。 7〜8台にエージェント導入すると、すぐに80,000円 / 月 とか。 (インスタンスサイズ

    / 利用プランで値段が変わります。) 以下ページで、APM というNewRelic 主力製品の料金を見積もれます。 https://newrelic.com/application-monitoring/pricing #elasticsearchjp
  28. ということで弊社では・・・ • 無料プラン利用中 • 他監視ツールの補助的な立ち位置& アラートを活用 (最近はほぼ見てないです。昔はよくお世話になりました。) ※ NewRelic は料金体系と製品群が複雑なので、以下を要参照。

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

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

  31. 遠回りしましたが、 #elasticsearchjp

  32. なぜElasticsearch ? • 自分たちで見たい指標を決めて実装すれば、ちゃんと見れる。 (SaaS 型の監視ツールは、楽に、勝手に、可視化してくれるが、  自分たちが見たいグラフをつくりにくいケースがある。) • 他にも・・・ •

    なんとなくかっこよくてすき • 今後、他の分野(検索)でも活用したいから、さわってみたかった #elasticsearchjp
  33. Elastic Stack の利用 投入データ • Nginx アクセスログ • DB のSlowQuery

    ログ(弊社は、AWS Aurora を利用) ※ Aurora については、以前、別の勉強会でお話しました。  ご興味ある方はどうぞ!  https://speakerdeck.com/katsuhisa91/rds-for-mysql-aurora-yi-xing-falsesubete #elasticsearchjp
  34. Elastic Stack の利用 どこに使っているか? • レスポンス時間のパーセンタイル表示 • 正規化済みURIごとのレスポンス時間(レスポンス時間が大きい順) • 正規化済みURI

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

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

    ごとのカウント数(レスポンス時間が大きい順) • HTTP ステータスコードの割合 • スロークエリの表示 • アクセス元の位置情報表示 基本的に性能改善で使いたい時は、 パーセンタイル表示で見ましょう #elasticsearchjp
  37. Average を見るよりサービスの状態 / 改善効果が、分かりやすい。 例:スロークエリをつぶせば、99%tileが下がった   99%tileが1s 以内レスポンスを目標にしよう、など。 #elasticsearchjp

  38. Elastic Stack の利用 どこに使っているか? • レスポンス時間のパーセンタイル表示 • 正規化済みURI ごとのレスポンス時間(レスポンス時間が大きい順) •

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

    正規化済みURI ごとのカウント数(レスポンス時間が大きい順) • HTTP ステータスコードの割合 • スロークエリの表示 • アクセス元の位置情報表示 ここを統一させることが、 ボトルネックの探索において重要 #elasticsearchjp
  40. 呼び出し回数が大きいリクエストは、 改善効果が出やすい。 #elasticsearchjp

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

  42. Elastic Stack の利用 どこに使っているか? • レスポンス時間のパーセンタイル表示 • 正規化済みURIごとのレスポンス時間(レスポンス時間が大きい順) • 正規化済みURI

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

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

    ごとのカウント数(レスポンス時間が大きい順) • HTTP ステータスコードの割合 • スロークエリの表示 • アクセス元の位置情報表示 唐突に謎リクエストが増えたら、 アクセス元をそれとなく把握するために活用予定 (幸い、今は謎攻撃を受けていないため未活用) #elasticsearchjp
  45. The Four Golden Signalsが見える!見えるぞ・・・! #elasticsearchjp

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

  47. 結果が出ることに集中して、盛大に実績をアピール(信頼残高の貯金) ⇩ なんかElasticsearh というのを 使って性能可視化しているらしい。 ⇩ 検索エンジンとしても使いたいです! ちょっと高いけど、Elastic Cloud っていう楽できるやつ使いたいです!

    ⇩ すでに別のところでElasticsearch 使用実績あるっぽいし、いいよ ⇩ ワイ、歓喜 #elasticsearchjp
  48. Agenda 性能監視の話 Elasticsearch 導入の詳細 今後の活用 #elasticsearchjp

  49. でも、導入たいへんなんでしょう? #elasticsearchjp

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

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

  52. 構成 EC2 ( WebApp ) EC2 ( WebApp ) EC2

    ( LogAggregator ) Amazon RDS ( Aurora ) Nginx Access Log Nginx Access Log Slow Query Log #elasticsearchjp
  53. 実際にやったこと • Elasticsearch / Kibana 環境構築 • Kibanaへのアクセス制限 • Nginx

    アクセスログの出力形式変更 • SlowQuery 取得設定(fluentd plugin) • fluentd のセットアップ ◦ 受け取って渡す当たり前のことをやらせる設定 ◦ Elasticsearch に送信する認証情報設定 • ログ加工する設定(正規表現 / geoip 導入とかとか) • Kibana にtemplate入れる • Kibana でダッシュボードつくる #elasticsearchjp
  54. EC2 ( WebApp ) EC2 ( WebApp ) EC2 (

    LogAggregator ) #elasticsearchjp Amazon RDS ( Aurora ) 1. 環境構築&ダッシュボードへのアクセス制限
  55. 実際にやったこと • Elasticsearch / Kibana 環境構築 • Kibanaへのアクセス制限 • Nginx

    アクセスログの出力形式変更 • SlowQuery 取得設定(fluentd plugin) • fluentd のセットアップ ◦ 受け取って渡す当たり前のことをやらせる設定 ◦ Elasticsearch に送信する認証情報設定 • ログ加工する設定(正規表現 / geoip 導入とかとか) • Kibana にtemplate入れる • Kibana でダッシュボードつくる AWS Elasticsearch Service を利用すれば、 すぐ終わります。 #elasticsearchjp
  56. 実際にやったこと • 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
  57. EC2 ( WebApp ) EC2 ( WebApp ) EC2 (

    LogAggregator ) Amazon RDS ( Aurora ) #elasticsearchjp 2. Nginx のログ形式を変更
  58. 実際にやったこと • Elasticsearch / Kibana 環境構築 • Kibanaへのアクセス制限 • Nginx

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

    LogAggregator ) Amazon RDS ( Aurora ) Slow Query Log #elasticsearchjp 3. Slow Query Log を受け取る
  60. 実際にやったこと • Elasticsearch / Kibana 環境構築 • Kibanaへのアクセス制限 • Nginx

    アクセスログの出力形式変更 • SlowQuery 取得設定(fluentd plugin) • fluentd のセットアップ ◦ 受け取って渡す当たり前のことをやらせる設定 ◦ Elasticsearch に送信する認証情報設定 • ログ加工する設定(正規表現 / geoip 導入とかとか) • Kibana にtemplate入れる • Kibana でダッシュボードつくる fluentd プラグインを導入して、 データベース接続の認証情報を書くだけ。 #elasticsearchjp
  61. EC2 ( WebApp ) EC2 ( WebApp ) EC2 (

    LogAggregator ) Amazon RDS ( Aurora ) Nginx Access Log Nginx Access Log Slow Query Log #elasticsearchjp 4. ログを受け取って渡す&加工
  62. 実際にやったこと • Elasticsearch / Kibana 環境構築 • Kibanaへのアクセス制限 • Nginx

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

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

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

    LogAggregator ) Amazon RDS ( Aurora ) Nginx Access Log Nginx Access Log Slow Query Log #elasticsearchjp 5. Kibana の設定
  66. 実際にやったこと • Elasticsearch / Kibana 環境構築 • Kibanaへのアクセス制限 • Nginx

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

    アクセスログの出力形式変更 • SlowQuery 取得設定(fluentd plugin) • fluentd のセットアップ ◦ 受け取って渡す当たり前のことをやらせる設定 ◦ Elasticsearch に送信する認証情報設定 • ログ加工する設定(正規表現 / geoip 導入とかとか) • Kibana にtemplate入れる • Kibana でダッシュボードつくる ぽちぽちやる。 #elasticsearchjp
  68. ハマったこと あんまりない気がする。 認証情報の書き方が間違っているのに気付かずに、 1時間詰まったとか、そのくらい。 強いて言うなら、やりたいことを実現するための プラグインを探すのが多少めんどうだった。 #elasticsearchjp

  69. ハマったこと というわけで、使ったプラグインを公開しておく。 • 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
  70. まとめ Elastic Stack で何を可視化すれば性能改善が捗るのか ⬇ The Four Golden Signals を見よう

    ⬇ 具体的には、 1. 「レスポンス時間のパーセンタイル表示」 2. 「URI ごとのレスポンス時間&呼出回数表示」 3. 「HTTP ステータスコードの割合」 あたりを可視化するのがオススメ。 #elasticsearchjp
  71. まとめ また、実装は3日あれば終わるボリュームです。 これは、素晴らしいfluentd プラグインを公開してくださっている 偉人たちのおかげです。 彼らに感謝しつつ、 今すぐElastic Stack でログ可視化をはじめましょう。 #elasticsearchjp

  72. 今日のゴール(おさらい) 今日聞いてくださったみなさんが、Elastic Stack を活用して、 1. 〜10/20 (金) : 性能可視化が完了 2.

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

    11/ 1 (水) 〜 : 可視化したグラフを見ながら 性能改善に着手開始 できるようになる! #elasticsearchjp たぶんできます。 (なぜなら、うちもほんの三ヶ月前は、  Elasticsearch 導入検討すらしていなかったから。)
  74. Agenda 性能監視の話 Elasticsearch 導入の詳細 今後の活用 #elasticsearchjp

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

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

    を導入したい と、いう感じのことができる人Wanted!! #elasticsearchjp
  77. We are hiring!!! #elasticsearchjp

  78. We are hiring!!! #elasticsearchjp

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