NewRelic / Elasticsearch ではじめるSREに必要な性能監視入門

by katsuhisa_

Slide 1

Slide 1 text

NewRelic / Elasticsearch ではじめる SREに必要な性能監視入門株式会社スタディスト北野勝久 2017/10/26 (木) サポーターズ勉強会

Slide 2

Slide 2 text

前提知識を合わせながらやります。ある程度知識がある方にとっては、回りくどい箇所があるかもしれません。　　　#spzcolab

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

今日のゴール 1. 性能監視の基本的な考え方を理解する 2. NewRelic/Elasticsearch の基本が分かる 3. NewRelic/Elasticsearch を性能監視にどうやって役立てるか分かる　　　#spzcolab

Slide 6

Slide 6 text

今日のゴールまでの道筋 1. 性能監視の基本的な考え方を理解する a. 監視とは b. 性能監視とは c. どんな指標を見れば良いか 2. NewRelic/Elasticsearch の基本が分かる a. NewRelic の基本 b. Elasticsearch の基本 3. NewRelic/Elasticsearch を性能監視にどうやって役立てるか分かる a. NewRelic を現場でどう活用しているか b. Elasticsearch を現場でどう活用しているか　　　#spzcolab

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

今日の話は大事ですよね、という認識合わせができたところで本題　　　#spzcolab

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

性能監視の前に、そもそも監視とは？性能監視入門　　　#spzcolab

Slide 14

Slide 14 text

性能監視入門 ● 死活監視 ● 稼働監視 ● ログ監視 ● ミドルウェア監視 ● 性能監視 ● ,etc. → ◯◯監視というワードは、世の中にあふれている　　　#spzcolab

Slide 15

Slide 15 text

性能監視入門 ● 死活監視 ● 稼働監視 ● ログ監視 ● ミドルウェア監視 ● 性能監視 ● ,etc. → ◯◯監視というワードは、世の中にあふれている調べても、なかなかしっくりくる監視の全体像が見つからない　　　#spzcolab

Slide 16

Slide 16 text

性能監視入門そもそも監視とは何か？ ● 死活監視 ● 稼働監視 ● ログ監視 ● ミドルウェア監視 ● 性能監視 ● ...etc → ◯◯監視というワードは、世の中にあふれているたぶんその理由は・・・システム基盤は、時代とともに変化しているので、今の時代に合った監視のあり方の解釈は、常にアップデートされているからだと思う。　　　#spzcolab

Slide 17

Slide 17 text

性能監視入門そもそも監視とは何か？ ● 死活監視 ● 稼働監視 ● ログ監視 ● ミドルウェア監視 ● 性能監視 ● ...et → ◯◯監視というワードは、世の中にあふれているなので、今時（※）の監視について整理しました。（あくまでも、私の主観に基づきます） ※AWS やGCP などIaaS を使う前提　　　#spzcolab

Slide 18

Slide 18 text

監視全体像切り口を2つ用意すると分かりやすいのでは？という仮説に基づき整理。 1. 監視対象ごとの切り口 2. 監視目的ごとの切り口　　　#spzcolab

Slide 19

Slide 19 text

監視全体像サービス監視リソース監視デーモン監視ログ監視稼働監視エラー監視性能監視　 ◎ 　 - 　 - 　 ◯ 　 - 　 ◎ 　 ◎ 　 - 　 - 　 - 　 ◎ 　 ◎ 　　　#spzcolab 監視対象ごとの切り口

Slide 20

Slide 20 text

監視全体像サービス監視リソース監視デーモン監視ログ監視稼働監視エラー監視性能監視　 ◎ 　 - 　 - 　 ◯ 　 - 　 ◎ 　 ◎ 　 - 　 - 　 - 　 ◎ 　 ◎ 　　　#spzcolab 監視目的ごとの切り口

Slide 21

Slide 21 text

監視全体像切り口を2つ用意すると分かりやすいのでは？という仮説に基づき整理。 1. 監視対象ごとの切り口 2. 監視目的ごとの切り口　　　#spzcolab

Slide 22

Slide 22 text

Slide 23

Slide 23 text

監視対象ごとの切り口監視対象で分けて、監視を捉える 1. サービス監視 2. リソース監視 3. デーモン監視 4. ログ監視　　　#spzcolab

Slide 24

Slide 24 text

監視対象ごとの切り口監視対象で分けて、監視を捉える 1. サービス監視 2. リソース監視 3. デーモン監視 4. ログ監視サービス＝ IaaS 上で稼働するサーバーなど例：AWS だと、EC2 やS3 の状態を監視　　　#spzcolab

Slide 25

Slide 25 text

監視対象ごとの切り口監視対象で分けて、監視を捉える 1. サービス監視 2. リソース監視 3. デーモン監視 4. ログ監視サーバーの中のいろんなリソースの監視（CPUや、メモリなど）　　　#spzcolab

Slide 26

Slide 26 text

監視対象ごとの切り口監視対象で分けて、監視を捉える 1. サービス監視 2. リソース監視 3. デーモン監視 4. ログ監視サーバーの中で動くデーモン（プロセス）の監視　　　#spzcolab

Slide 27

Slide 27 text

監視対象ごとの切り口監視対象で分けて、監視を捉える 1. サービス監視 2. リソース監視 3. デーモン監視 4. ログ監視ログから、様々な情報を拾う　　　#spzcolab

Slide 28

Slide 28 text

監視全体像切り口を2つ用意すると分かりやすいのでは？という仮説に基づき整理。 1. 監視対象ごとの切り口 2. 監視目的ごとの切り口　　　#spzcolab

Slide 29

Slide 29 text

Slide 30

Slide 30 text

監視目的ごとの切り口目的で分けて、監視を捉える 1. 稼働監視 2. エラー監視 3. 性能監視　　　#spzcolab

Slide 31

Slide 31 text

監視目的ごとの切り口目的で分けて、監視を捉える 1. 稼働監視 2. エラー監視 3. 性能監視動いているか、そうでないかの検知　　　#spzcolab

Slide 32

Slide 32 text

監視目的ごとの切り口目的で分けて、監視を捉える 1. 稼働監視 2. エラー監視 3. 性能監視アプリケーションのエラー検知など　　　#spzcolab

Slide 33

Slide 33 text

監視目的ごとの切り口目的で分けて、監視を捉える 1. 稼働監視 2. エラー監視 3. 性能監視パフォーマンスに関する検知　　　#spzcolab

Slide 34

Slide 34 text

監視全体像サービス監視リソース監視デーモン監視ログ監視稼働監視エラー監視性能監視　 ◎ 　 - 　 - 　 ◯ 　 - 　 ◎ 　 ◎ 　 - 　 - 　 - 　 ◎ 　 ◎ 　　　#spzcolab

Slide 35

Slide 35 text

監視全体像サービス監視リソース監視デーモン監視ログ監視稼働監視エラー監視性能監視　 ◎ 　 - 　 - 　 ◯ 　 - 　 ◎ 　 ◎ 　 - 　 - 　 - 　 ◎ 　 ◎ ● まずは、サービスが動いていることが前提 ● 一部のサーバーリソースは、枯渇するとサービス稼働に直接的に影響が生じるため、リソース監視も稼働監視に含んでいます ● デーモンも動いているか動いていないかの確認は必要　　　#spzcolab

Slide 36

Slide 36 text

監視全体像サービス監視リソース監視デーモン監視ログ監視稼働監視エラー監視性能監視　 ◎ 　 - 　 - 　 ◯ 　 - 　 ◎ 　 ◎ 　 - 　 - 　 - 　 ◎ 　 ◎ ログの中身（メッセージ/ステータスコード）を監視　　　#spzcolab

Slide 37

Slide 37 text

監視全体像サービス監視リソース監視デーモン監視ログ監視稼働監視エラー監視性能監視　 ◎ 　 - 　 - 　 ◯ 　 - 　 ◎ 　 ◎ 　 - 　 - 　 - 　 ◎ 　 ◎ ● ロードアベレージが詰まると性能悪化する ● ログからレスポンスタイムと、 URI を確認する　　　#spzcolab

Slide 38

Slide 38 text

監視全体像まとめ ● 意外と、監視の全体像については、どこにもまとまっていないので、（ひとまず）私の考える全体像をみなさんに共有しました。 ● 監視目的と監視対象で監視の全体像を捉えるとすっきりするのでは？というアイデアを共有しました。　　　#spzcolab

Slide 39

Slide 39 text

Slide 40

Slide 40 text

監視全体像サービス監視リソース監視デーモン監視ログ監視稼働監視エラー監視性能監視　 ◎ 　 - 　 - 　 ◯ 　 - 　 ◎ 　 ◎ 　 - 　 - 　 - 　 ◎ 　 ◎ 　　　#spzcolab 先ほどの情報をふまえて・・・

Slide 41

Slide 41 text

性能監視まとめ 1. サービス全体にまたがるパフォーマンスの監視 2. 性能監視のためには、サーバーリソースや、ログの監視が重要 ※これは、あくまでも私の解釈で、議論の余地は多いにあると思います。　　　#spzcolab

Slide 42

Slide 42 text

性能監視まとめ 1. サービス全体にまたがるパフォーマンスの監視 2. 性能監視のためには、サーバーリソースや、ログの監視が重要 ※これは、あくまでも私の解釈で、議論の余地は多いにあると思います。今日は、主にログを活用した性能監視の話をします（懇親会で、他の領域の話もぜひ！）　　　#spzcolab

Slide 43

Slide 43 text

Slide 44

Slide 44 text

監視の大枠と性能監視の概要は分かった。でも、具体的な指標として何を見ればいいの？　　　#spzcolab

Slide 45

Slide 45 text

The Four Golden Signals 　　　#spzcolab

Slide 46

Slide 46 text

The Four Golden Signals The four golden signals of monitoring are latency, traﬃc, 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 　　　#spzcolab

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

The Four Golden Signals 1. latency 2. traﬃc 3. errors 4. saturation 　　　#spzcolab

Slide 49

Slide 49 text

The Four Golden Signals 1. latency 2. traﬃc 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) 　　　#spzcolab

Slide 50

Slide 50 text

Slide 51

Slide 51 text

The Four Golden Signals この4つをいい感じに測りたい。 1. latency 2. traﬃc 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) 　　　#spzcolab

Slide 52

Slide 52 text

1. latency 2. traﬃc 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) The Four Golden Signals NewRelic とElasticsearch おすすめです　　　#spzcolab

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

　　　#spzcolab

Slide 56

Slide 56 text

NewRelic ● 特徴 ○ 主にパフォーマンス改善に特化した性能監視ツール ○ OSS ではなく、SaaS ■ なので・・・ NewRelic 社にログが収集され、 NewRelic 社が管理するダッシュボードにて情報が可視化される ● 料金/プラン ○ 代表的な製品（APM）の有料プランは高め（有料プランは、 2種類） ○ 無料プランあり ○ 目的に応じたいくつかの製品群がある　　　#spzcolab

Slide 57

Slide 57 text

NewRelic ● 特徴 ○ 主にSRE に特化した性能監視ツール ○ OSS ではなく、SaaS ■ なので・・・ NewRelic 社にてログが収集され、 NewRelic 社が管理するダッシュボードにて情報が可視化される ● 料金 ○ （代表的な製品は、）高め ○ 無料プラン、有料プラン、フル機能有料プラン ○ 目的に応じたいくつかの製品群がある製品群/プランがわりと複雑なので、ここでは深掘りしません。以下ページが、すごくおすすめです。 https://qiita.com/kumatronik/items/e2e09bd3708b00442d9b 　　　#spzcolab

Slide 58

Slide 58 text

メインの製品群と、それらの機能を理解し、 NewRelic で何ができるかの深掘りはもちろん必要というわけで、とりあえずこの3つ 1. APM 2. BROWSER 3. ALERT とは言え・・・　　　#spzcolab

Slide 59

Slide 59 text

APM ● Application Performance Monitoring の略 ● NewRelic といえばコレのことを示すことが大半 ● 何ができるか ○ Transaction や、そこから勝手に Apdex（後半で補足します）を算出してくれたり。 ○ また、DB に投げているQuery の統計を勝手に出してくれたり。 ○ さらには、Error 集計も勝手にやってくれたり。　　　#spzcolab

Slide 60

Slide 60 text

Slide 61

Slide 61 text

APM の導入 ● ライブラリをアプリに導入して、ライセンスキーの情報を入れるだけ。 ● 以上。いい感じのグラフがすぐ出ます。控えめに言って最高。 ● ちなみに対応しているライブラリの言語は以下 ○ Ruby  ○ Java  ○ .NET  ○ Node.js  ○ PHP  ○ Go  ○ Python 　　　#spzcolab

Slide 62

Slide 62 text

BROWSER ● ブラウザ経由のパフォーマンスを可視化してくれる ● ページの読み込み時間とかが分かる。また、アクセス元の国ごとの読み込み時間も可視化してくれる。 ● APM のエージェントを導入すれば、 HTML にJS が埋め込まれる ○ 埋め込まれたJS 経由で情報をNewRelic に送信してくれる　　　#spzcolab

Slide 63

Slide 63 text

ALERT ● 製品をまたぐ1つのサービス ○ なので、個別の導入作業は不要 ● ぽちぽち設定するだけ ○ メトリクスと閾値を決める ○ サーバーごとにON / OFF できたり、けっこうかゆいところに手が届きます。　　　#spzcolab

Slide 64

Slide 64 text

ほかにも・・・ ● Mobile ○ モバイルまわりのメトリクス監視 ● Infrastructure ○ インフラまわりのメトリクス監視 ● Synthetics ○ 障害監視サービス ● Insights ○ ダッシュボード　　　#spzcolab

Slide 65

Slide 65 text

NewRelic まとめ ● 基本的には、ライブラリをアプリケーションに入れるだけでグラフを出してくれて、すぐ使い始められる → なので、個別実装もがんばらなくていいし、文句なし ● ただ、もちろん万能薬ではないので、見たいデータ見れないなあ、って時もあります。 ● そういう時のために、Elasticsearch と併用すると幸せになれる気がする、というお話をこれからします。　　　#spzcolab

Slide 66

Slide 66 text

Slide 67

Slide 67 text

　　　#spzcolab

Slide 68

Slide 68 text

突然ですが、以降は、 Elastic Stack という用語を主に使用します　　　#spzcolab

Slide 69

Slide 69 text

Elastic Stack 概要 ● Elastic Stack とは？ ○ Elastic Stack ＝ Elasticsearch と周辺ツールの総称（Kibana / Logstash / Beats ） ○ OSS ● Elastic Stack Family ○ Elasticsearch ■ 検索エンジン ○ Kibana ■ Elasticsearch をバックエンドに構えることができるダッシュボード ○ Logstash / Beats ■ 今日の本題にあまり詳しく関わらないため、詳細は割愛 ■ fluentd でできるようなことができる（語弊あります）　　　#spzcolab

Slide 70

Slide 70 text

Slide 71

Slide 71 text

検索エンジンが性能監視？ん？？初学者は、混乱するかと思うので、念のため先に補足。 Elasticsearch は、もともと検索エンジンのOSS ですただし、 1. 検索エンジンとしての機能は、ログの中身の検索にも有用 2. また、Elasticsearch と合わせて使用するダッシュボードツールのKibana が非常に優秀なため、ログ解析基盤としても使われます。　　　#spzcolab

Slide 72

Slide 72 text

ログ基盤としてのElastic Stack ● 前述したNewRelic と違い、SaaS ではなくOSS なので、基本的には、自分たちで面倒を見る必要がある ○ ただ、ログ可視化だけをやらせるのであれば、初期構築さえ終われば、運用コストはほとんどない印象 ● 投入したデータに関する可視化はたいていなんでもできる ○ Kibana がとにかく使いやすく、少し慣れが必要ですが、初心者でもかんたんに見たいデータをグラフ化できる ○ URI をベースにデータを可視化することが多いので、自社サービスのURI の設計思想によっては苦労することがある ■ 例：ユーザーの所属するグループごとに情報を集計したいが、　　各URI に、必ずしもグループ情報が含まれていない場合など。 ■ これは残念ながら弊社の現在の URI の例です・・・　　　#spzcolab

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Elastic Stack の導入 ● 基本的なやることは、 1. Elasticsearch / Kibana の環境構築 2. ログをElasticsearch に投入する 3. Kibana のダッシュボードでグラフ化する　　　#spzcolab

Slide 75

Slide 75 text

Elastic Stack の導入 ● 基本的なやることは、 1. Elasticsearch / Kibana の環境構築 2. ログをElasticsearch に投入する 3. Kibana のダッシュボードでグラフ化するマネージドサービスを使えばすぐ終わります。（AWS Elasticsearch Service , Elastic Cloud） OSS なので、もちろんサーバーにインストールしてがんばって構築してもOK 　　　#spzcolab

Slide 76

Slide 76 text

Elastic Stack の導入 ● 基本的なやることは、 1. Elasticsearch / Kibana の環境構築 2. ログをElasticsearch に投入する 3. Kibana のダッシュボードでグラフ化するこのあたりは、もし前提知識がなければ、社内の分かる人に聞いて下さい。（もし、社内にそういう人がいなければ、懇親会でぜひお声がけください。） fluentd がオススメです。　　　#spzcolab

Slide 77

Slide 77 text

Elastic Stack の導入 ● 基本的なやることは、 1. Elasticsearch / Kibana の環境構築 2. ログをElasticsearch に投入する 3. Kibana のダッシュボードでグラフ化するぽちぽち設定する。はじめ詰まるかもしれませんが、 Kibana は使いやすいので少しやれば慣れます。ダッシュボードへのアクセス権限管理などにもご注意を。　　　#spzcolab

Slide 78

Slide 78 text

Elastic Stack の導入 ● 基本的なやることは、 1. Elasticsearch / Kibana の環境構築 2. ログをElasticsearch に投入する 3. Kibana のダッシュボードでグラフ化する　　　#spzcolab 初学者には、それなりにたいへんかもしれません。ただ、ポイントをはずさなければ、そこまで時間はかからないはず。導入に至る実装の詳細を別の勉強会で話したので、ご参照ください。 https://speakerdeck.com/katsuhisa91/elastic-stack-de-he-woke-shi-hua-surebaxi ng-neng-gai-shan-gabu-rufalseka

Slide 79

Slide 79 text

Elastic Stack まとめ ● Elasticsearch / Kibana を合わせて使用します ● 自分たちで面倒を見る必要があるので、多少運用コストがかかります ● 見たいデータを投入すれば、Kibana を使って、きれいなグラフをかんたんにつくることができます ○ 具体的にどんなグラフをつくればよいかは、後半でお話します！　　　#spzcolab 　　　#spzcolab

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

　　　#spzcolab

Slide 83

Slide 83 text

NewRelic の活用弊社での、NewRelic の主な活用 ● Apdex ● Web transaction percentiles ● Database response time ● External services ● Errors ● Apdex , Error Rate に応じたALERT 活用　　　#spzcolab

Slide 84

Slide 84 text

NewRelic の活用弊社での、NewRelic の主な活用 ● Apdex ● Web transaction percentiles ● Database response time ● External services ● Errors ● Apdex , Error Rate に応じたALERT 活用 APM を使用すると、Apdex を算出してくれます。 ※Apdex ＝アプリケーション性能指標　http://apdex.org/overview.html 後述するALERT のトリガーの1つにしています。　　　#spzcolab

Slide 85

Slide 85 text

NewRelic の活用弊社での、NewRelic の主な活用 ● Apdex ● Web transaction percentiles ● Database response time ● External services ● Errors ● Apdex , Error Rate に応じたALERT 活用レスポンス時間の可視化現在は、Elastic Stack で、同じ情報を可視化しているため、あまり見ていません。　　　#spzcolab

Slide 86

Slide 86 text

NewRelic の活用弊社での、NewRelic の主な活用 ● Apdex ● Web transaction percentiles ● Database response time ● External services ● Errors ● Apdex , Error Rate に応じたALERT 活用データベースを移行した際に、before/after の、性能比較をするために活用しました。　　　#spzcolab

Slide 87

Slide 87 text

NewRelic の活用弊社での、NewRelic の主な活用 ● Apdex ● Web transaction percentiles ● Database response time ● External services ● Errors ● Apdex , Error Rate に応じたALERT 活用外部サービスの性能を可視化してくれます。例：AWS だとSES（メール送信サービス）などシステム全体の性能監視をしている安心感を得ています。　　　#spzcolab

Slide 88

Slide 88 text

NewRelic の活用弊社での、NewRelic の主な活用 ● Apdex ● Web transaction percentiles ● Database response time ● External services ● Errors ● Apdex , Error Rate に応じたALERT 活用エラーレートを計測しています後述するALERT のトリガーの1つにしています。　　　#spzcolab

Slide 89

Slide 89 text

NewRelic の活用弊社での、NewRelic の主な活用 ● Apdex ● Web transaction percentiles ● Database response time ● External services ● Errors ● Apdex , Error Rate に応じたALERT 活用 Apdex が70% を下回る、もしくは、 Error Rate が1% を上回ると ALERT がSlack にきます。初期対応の迅速化に利用中。最近はまったく本番環境からのALERT はきていません。　　　#spzcolab

Slide 90

Slide 90 text

NewRelic 活用まとめ ● 主に、アプリケーション全体の性能を監視してもらっています ● また、ALERT を活用し、何か起きているかどうかの判断に使用 ● エラーが発生した時に、どんなエラーが起きているかの初動の内容確認にも使用　　　#spzcolab

Slide 91

Slide 91 text

NewRelic 活用まとめ ● 主に、アプリケーション全体の性能を監視してもらっています ● また、ALERT を活用し、何か起きているかどうかの判断に使用 ● エラーが発生した時に、どんなエラーが起きているかの初動の内容確認にも使用　　　#spzcolab ALERT が非常に使い勝手がいいです。弊社では、Elastic Stack を導入するまでは、 APM には非常にお世話になっていました。

Slide 92

Slide 92 text

Slide 93

Slide 93 text

　　　#spzcolab

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

Elastic Stack 活用まとめ ● 性能改善する際に必要な情報は、基本的にすべてここに集まっている状態 ○ ただ、本プレゼン前半で話したようにあくまでも性能監視の中でもログ監視のみで、リソース監視の部分は、現状は別ツールに依存 ● ここで話した内容以外にも、クライアントごとのレスポンス比率可視化や、アクセス数の多い企業さまの把握など、ユーザーの行動解析に近いグラフも作成しています　　　#spzcolab

Slide 106

Slide 106 text

Slide 107

Slide 107 text

まとめ　　　#spzcolab

Slide 108

Slide 108 text

まとめ ● モニタリングは大事ですね ○ The Four Golden Signals を見るといいよって Google さんが言ってます ● 性能監視には、リソース監視やログ監視が大事 ● NewRelic / Elastic Stack で性能監視がかんたんにできる ● NewRelic ○ SaaS なので、めんどうな管理もいらず、すぐ使い始められる ○ いろいろいい感じにグラフを出してくれる ● Elastic Stack ○ 自分たちで、めんどう見ないといけない ○ 構築や運用にかかる、わずかな労力をはらえば、性能改善に必須の情報を集約するツールとしてがんがん活用できます　　　#spzcolab

Slide 109

Slide 109 text

今日のお話のまとめ ● モニタリングは大事ですね ○ The Four Golden Signals を見るといいよって Google さんが言ってます ● 性能監視には、リソース監視やログ監視が大事 ● NewRelic / Elastic Stack で性能監視がかんたんにできる ● NewRelic ○ SaaS なので、めんどうな管理もいらず、すぐ使い始められる ○ いろいろいい感じにグラフを出してくれる ● Elastic Stack ○ 自分たちで、めんどう見ないといけない ○ 構築や運用にかかる、わずかな労力をはらえば、性能改善に必須の情報を集約するツールとしてがんがん活用できますと、こういう感じのことを一緒にやってくれる人を探しています。　　　#spzcolab

Slide 110

Slide 110 text

今日のお話のまとめ ● モニタリングは大事ですね ○ The Four Golden Signals を見るといいよって Google さんが言ってます ● 性能監視には、リソース監視やログ監視が大事 ● NewRelic / Elastic Stack で性能監視がかんたんにできる ● NewRelic ○ SaaS なので、めんどうな管理もいらず、すぐ使い始められる ○ いろいろいい感じにグラフを出してくれる ● Elastic Stack ○ 自分たちで、めんどう見ないといけない ○ 構築や運用にかかる、わずかな労力をはらえば、性能改善に必須の情報を集約するツールとしてがんがん活用できます特に・・・ ● Rails を使いこなせる ● ざっくりとインフラに関わる仕事をしてる ○ SRE/DevOps の知識がある ○ AWS を使いこなせる ↑こんな人を募集しています。　　　#spzcolab

Slide 111

Slide 111 text

We are hiring!!! 　　　#spzcolab

Slide 112

Slide 112 text

We are hiring!!! 　　　#spzcolab

Slide 113

Slide 113 text

ご清聴ありがとうございました！採用にご興味ある方は、お気軽にご連絡ください！ご清聴ありがとうございました　　　#spzcolab