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

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

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

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

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

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

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

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

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

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

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

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

モニタリング大事 #elasticsearchjp

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

The Four Golden Signals #elasticsearchjp

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

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

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

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

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

4. saturation この4つをいい感じに測りたい。 #elasticsearchjp

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

#elasticsearchjp

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

#elasticsearchjp

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

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

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

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

遠回りしましたが、 #elasticsearchjp

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

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

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

ごとのカウント数（レスポンス時間が大きい順） • HTTP ステータスコードの割合 • スロークエリの表示 • アクセス元の位置情報表示サービス全体の性能を見るために利用 #elasticsearchjp

ごとのカウント数（レスポンス時間が大きい順） • HTTP ステータスコードの割合 • スロークエリの表示 • アクセス元の位置情報表示基本的に性能改善で使いたい時は、パーセンタイル表示で見ましょう #elasticsearchjp

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

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

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

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

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

ごとのカウント数（レスポンス時間が大きい順） • HTTP ステータスコードの割合 • スロークエリの表示 • アクセス元の位置情報表示サービス全体の健全度を見るために利用。円グラフで5XX の割合出したり、割合の推移を追うグラフを出したり。 #elasticsearchjp

ごとのカウント数（レスポンス時間が大きい順） • HTTP ステータスコードの割合 • スロークエリの表示 • アクセス元の位置情報表示ボトルネックの探索に利用 #elasticsearchjp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ハマったことというわけで、使ったプラグインを公開しておく。 • 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

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

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

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

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

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

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

We are hiring!!! #elasticsearchjp

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

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

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

More Decks by katsuhisa_

Other Decks in Technology

Featured

Transcript

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

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