AWSと監視SaaSの動向から探る監視（モニタリング）の「いま」

Slide 1

Slide 1 text

#akibaaws

Slide 2

Slide 2 text

"84ͱ؂ࢹ4BB4ͷಈ޲͔Β୳Δ  ؂ࢹʢϞχλϦϯάʣͷʮ͍·ʯ ",*#""84؂ࢹ ϞχλϦϯά ฤ

Slide 3

Slide 3 text

渡辺聖剛 ‣ʼ17/01⼊社 ‣AWS事業本部オペ部所属 ‣インターネット⽼⼈会 ‣前職までは所謂インフラエンジニア ‣汎⽤機(ʼ95~) -> ISP (Y2K~) -> SIer (~ʼ10) -> ⾃他社Web構築運⽤ ‣(特に)好きなAWSサービス ‣Route 53、AWS Systems Manager ࣗݾ঺հ

Slide 4

Slide 4 text

19xx〜 ‣ 汎⽤機（ダム端末 - 中央集権型） ‣ オープンシステム（UNIX + TCP/IP, CS型） ‣ インターネット（PC UNIX, x86） ‣ Web2.0（⾔語フレームワーク, モバイル） ‣ 4G(LTE) + スマートフォン ‣ クラウド（アプリ, インフラ）

Slide 5

Slide 5 text

(PBM

Slide 6

Slide 6 text

‣ 六本⽊のバーで「最近『監視』ってどうなの︖」と聞かれた時に、適切なウンチクで返せるようになること Goal ※ը૾͸ΠϝʔδͰ͢

Slide 7

Slide 7 text

͸ͳ͢͜ͱ ‣ はなすこと（Agenda） ‣ はなさないこと

Slide 8

Slide 8 text

はなすこと（Agenda） ‣ そもそも「監視」って何さ︖ ‣ 監視される対象が変化している ‣ 監視する⽬的と価値も変化している ‣ 監視する側の⽴場と価値観も（ｒｙ ‣ それに合わせてツールも（ｒｙ ‣ いまどんなものがある︖

Slide 9

Slide 9 text

はなさないこと ‣ 特定ツール・サービス(SaaS)の使い⽅ ‣ 各サービス(SaaS)の星取り表的⽐較 ‣ 「このサービス(SaaS)を使えばok︕」 ‣ セキュリティに特化した話

Slide 10

Slide 10 text

ͦ΋ͦ΋ʮ؂ࢹʯͬͯԿ͞ʁ ‣ 監視 vs monitoring

Slide 11

Slide 11 text

「⼊⾨」︖ ‣ ⼊⾨「監視」―モダンなモニタリングのためのデザインパターン ‣ @hamako9999 の記事 -> ‣ 原題 : Practical Monitoring: Eﬀective Strategies for the Real World ‣ Practical = 実⽤的・実践的 ‣ “relating to real situations and events rather than ideas, emotions etc”（ロングマン現代英英辞典より） ‣ Eﬀective = 効果的な（「⼊⾨」...? https://dev.classmethod.jp/cloud/aws/practial-monitoring-bookreview/

Slide 12

Slide 12 text

監視︖ monitoring? (cont.) ‣ 監視のイメージ ‣ 監視カメラ ‣ モニタリングのイメージ ‣ ○○ウォッチング、モニタリング(観測・計測)ポスト英語と⽇本語で⾔葉のイメージがずいぶんと違う →翻訳物を読むときに気をつけたいポイント →（…⾔語の違いだけだろうか︖）

Slide 13

Slide 13 text

ʮ؂ࢹʯΛͱΓ·͘؀ڥͷมԽ ‣ 監視される対象 ‣ 監視する⽬的と価値 ‣ 監視する側の⽴場と価値観

Slide 14

Slide 14 text

「F1に例えたら︖」 ‣ 岡⽥良太郎（アスタリスク・リサーチ） ‣ hbstudy（主催・株式会社ハートビーツ） ‣ #87「Hardening に参加しよう︕」 ‣ 1:43:00〜 https://youtu.be/liPWCeB0lw0?t=6180 ‣ ハードニングというセキュリティイベントの話をしているとき

Slide 15

Slide 15 text

もしもシステムがF1だったら︖ ‣ F1 = サーキット周回カーレース ‣ F1ドライバー、ピットクルー ‣ ピットではタイヤ交換、ガソリン補給、簡単なメンテなど ‣ ⾞(F1マシン)からピットへ常時データを送信（テレメトリ） ‣ ドライバーとクルーは無線でやりとり ‣ 規定の周回で速度を競う（完⾛しないとはじまらない） ‣ 年間20数戦、毎年あたらしい⾞で戦う https://commons.wikimedia.org/wiki/File:2011_Australian_GP_pit_lane.jpg

Slide 16

Slide 16 text

もしもシステムがF1だったら︖(cont.) ‣ とっさに考えた例え ‣ ⾞ +ドライバー = アプリケーション ‣ ピットクルー = 運⽤担当者 ‣ ⾞の製造 = 開発担当者 ‣ レース（サービス運⽤）はアプリが動作させる ‣ ⾞の調⼦はピットクルー（運⽤担当）が⾒る

Slide 17

Slide 17 text

もしもシステムがF1だったら︖(cont.) ‣ 岡⽥⽒の答え︓ ‣ ⾞ +ドライバー =Ops（運⽤担当者） ‣ ピットクルー = Dev（開発担当者） ‣ 運⽤して初めて価値が⽣まれる ‣ Ops「(⾞の調⼦の)何かがおかしい」 ‣ Dev(ピット) : タイヤ交換(etc.) -> 次の周回へ

Slide 18

Slide 18 text

もしもシステムがF1だったら︖(深掘り) ‣ ドライバー = Ops、ピットクルー = Dev ‣ ⾞のテレメトリ(メトリック)を ‣ ドライバー(Ops) = いまその⾞を⾛らせ続ける(運⽤)ために使う ‣ ピットクルー(Dev) = 次のピットストップ(deploy)でどんなケアをするかを判断する材料 ‣ OpsよりDevのほうに多く⾶んでくる ‣ DevとOpsが⼀緒になってレースを戦うのがDevOps

Slide 19

Slide 19 text

もしもシステムがF1だったら︖(再掲) ‣ とっさに考えた例え ‣ ⾞ +ドライバー = アプリケーション ‣ ピットクルー = 運⽤担当者 ‣ ⾞の製造 = 開発担当者 ‣ レース（サービス運⽤）はアプリが動作させる ‣ ⾞の調⼦はピットクルー（運⽤担当）が⾒る →（よく考えたら）ウォーターフォール的な考え⽅

Slide 20

Slide 20 text

「DevOpsが正義」というわけではない ‣ 道具は環境にあわせて作られる（既製品は特に） ‣ これまでは : 主にウォーターフォール向け、Opsのために ‣ 最近のは : DevOps念頭、イテレーションを回すために ‣ 技術的進化は Dev・Ops どちらにも恩恵がある

Slide 21

Slide 21 text

DevOps時代のモニタリング ‣ DevOps時代において ‣ 「システムが動いて初めて価値を⽣む」(岡⽥⽒) ‣ メトリックを「次のイテレーション（周回）を回す判断材料として」取得することが重要 ‣ 蓄積 -> 分析 ‣ ならば「アラート」とは︖ ‣ アラート : 何かしらの「好ましくない事態」を検知したことによる通知 ‣ アラート(通知)を受け取るのは誰だろう

Slide 22

Slide 22 text

再掲 : 198x〜 ‣ 汎⽤機（ダム端末 - 中央集権型） ‣ オープンシステム（UNIX + TCP/IP, CS型） ‣ インターネット（PC UNIX, x86） ‣ Web2.0（⾔語フレームワーク, モバイル） ‣ 4G(LTE) + スマートフォン ‣ クラウド（アプリ, インフラ）

Slide 23

Slide 23 text

汎⽤機環境 ‣ ダム端末、中央集権型 ‣ CUI ‣ ジョブの正常性監視 -> 異常終了時にアラート ‣ ハードウェアの⾒回り（⽬視） ‣ ⽇次〜の⾃⼰診断（diagnostics） ‣ ⽉次〜でAct/Std切り替え・定期メンテナンス

Slide 24

Slide 24 text

オープンシステム環境 ‣ UNIX + TCP/IP, クライアント・サーバ型 ‣ OpenView/NMM (Network Node Manager) ‣ UNIXワークステーションによるGUI表⽰ ‣ X-Window System、Sun/Solaris、HP-UX、AIX ‣ ノード間の疎通確認、トラフィック監視 ‣ LoadAverageのミニグラフ(xload) https://ja.wikipedia.org/wiki/X_Window_System

Slide 25

Slide 25 text

インターネット環境 ‣ UNIXからPC UNIX(FreeBSD,Linux)へ ‣ x86アーキテクチャ（32bit,64bit） ‣ NW・トラフィック : SNMP、MRTG ‣ ノード : BigBrother, Hobbit ‣ ブラウザベースのUI ‣ ⼿製の監視システム ‣ 外から⾒た監視の重要性（メール着信等） https://oss.oetiker.ch/mrtg/ https://nnc3.com/mags/LM10/Magazine/Archive/2008/92/022-024_hobbit/article.html

Slide 26

Slide 26 text

Web2.0環境の運⽤・モニタリング ‣ ⾔語フレームワーク（Ruby on Rails） ‣ モバイル（フィーチャーフォン） ‣ ビッグデータ（⼤量データの⾼速分析） ‣ WebAPI ‣ OSSツールの進化 ‣ MRTG -> RRDTool、Cacti ‣ BigBrother, Hobbit -> Zabbix ‣ NetSaint -> Nagios ‣ APM（Application Performance Management） ‣ Webアプリケーションの複雑化とパフォーマンスチューニングの必要性 ‣ NewRelic (2008〜)

Slide 27

Slide 27 text

ここ5年10年の運⽤・モニタリング ‣ LTE + スマフォ、⼤陸間/⼤帯域/⾼速/低遅延通信 ‣ UI/UX、リッチコンテンツ ‣ 売り切りパッケージ -> スマフォアプリ・Webサービス ‣ 動画配信、インタラクティブコンテンツ（30fps↑ゲームコンテンツ） ‣ クラウドインフラ ‣ サーバ側 : Infrastructure as Code、コンテナ ‣ クライアント側 : マルチデバイス、IoT ‣ ML（機械学習による⼤容量データの準リアルタイム分析・予測）

Slide 28

Slide 28 text

四半世紀の変化 ‣ 需要（市場の要求）と供給（技術的な進歩） ‣ コンピュート能⼒の向上 ‣ インフラのソフトウェア化（Software-Deﬁned anything[*1](SDx)、クラウドインフラ） ‣ ネットワークの⾼速化（⼤帯域、低遅延、CDNの⼤衆化） ‣ ストレージの低廉化 ‣ ソフトウェアアプリケーションの複雑化、UI/UXのリッチ化 ‣ 機械学習の⼤衆化 ‣ 速度の重要性が爆上がり（応答速度、開発速度） ‣ 「システムの継続性・堅牢性」より「ビジネスの継続性・堅牢性」 *1 : https://www.sbbit.jp/article/cont1/29935

Slide 29

Slide 29 text

ʮ୲౰ൣғʯͷมԽYYYY -"/ αʔό )8 04 ϛυϧ ΢ΣΞ ΞϓϦέʔγϣϯ ϋʔυ΢ΣΞϚΠΫϩίʔυυϥΠό ιϑτ΢ΣΞ ϋʔυ΢ΣΞ Ծ૝)8 4%Y ιϑτ΢ΣΞ ΞϓϦέʔγϣϯ ίϯςφ 04 ϛυϧ ΢ΣΞ σʔληϯλ ϑΝγϦςΟ ‣ 純粋なハードウェアの領域の⼤部分がSDxに置き換えられる ‣ インフラのソフトウェア化 ‣ マネージドインフラ ‣ 純粋な「インフラ」担当の領域とするより、アプリと⼀体化して考えたほうが良い傾向が強くなる ※オンプレが無くなった＿＿＿わけではない 'BB4 Ϛωʔδυ

Slide 30

Slide 30 text

どこを何で監視（モニタリング）する︖ ‣ ここ数10年程で⾒るべき場所と⽬的が変化している ‣ そのために使える技術も⾶躍的に進化している ‣ その時々で最適な道具と⼿法が使われてきた ‣ 10年前の常識で監視・モニタリングしてませんか︖ ‣ 監視される側の可観測性(Observability)はあがっている ‣ どこをどう監視すべきか、⼀番詳しいひとは誰だろう

Slide 31

Slide 31 text

ʮϖοτͱՈசʯϞσϧʹ͓͚ΔϞχλϦϯά

Slide 32

Slide 32 text

CERN Data Centre Evolution ‣ Published on Nov 19, 2012 https://www.slideshare.net/gmccance/cern-data-centre-evolution#17

Slide 33

Slide 33 text

‣ 家畜(cattle)モデル ‣ 1台1台は最低限 ‣ 全体のパフォーマンスを重視「ペットと家畜」モデルにおけるモニタリング ‣ ペット(pet)モデル ‣ 1台1台のサーバから丁寧なメトリックを取得 http://www.tokyowest-ah.jp/medicals/sort_anesthetic.html https://www.titech.ac.jp/news/2019/043843.html

Slide 34

Slide 34 text

「ペットと家畜」モデルにおけるモニタリング(cont.) ‣ クラウドインフラ=「H/Wを⻑持ちさせる」という視点がない ‣ 100%までぶん回していい ‣ ⾃在にスケールアウト・スケールアップ -> 動いていることが⼤切 ‣ Design for failure ‣ その代わりの「従量課⾦」

Slide 35

Slide 35 text

「ペットと家畜」モデルにおけるモニタリング(cont.) ‣ クラウドインフラ=「H/Wを⻑持ちさせる」という視点がない ‣ 100%までぶん回していい -> 「とりあえず閾値90%」︖ ‣ ⾃在にスケールアウト・スケールアップ -> 動いていることが⼤切 ‣ Design for failure -> 1つ2つ落ちることは織り込み済み ‣ その代わりの「従量課⾦」-> 警告するべき視点の変化

Slide 36

Slide 36 text

ex) プロセスが落ちることとサーバが落ちることにどんな差が︖ ‣ どちらも「サービスが継続出来なくなる」ことに変わりない ‣ 昔 -> OS再起動にコスト⼤ -> プロセスだけ再起動しよう ‣ ペット化されたインフラは個体差も⼤きく複雑 ‣ モノリシック、密結合 ‣ いま -> コンテナ作り直せば︖ ‣ IaC, Immutable Infrastructure ‣ マイクロサービス、疎結合

Slide 37

Slide 37 text

ԿΛͲ͏ʮ؂ࢹʯ͢Δʁ ‣ 監視する項⽬ ‣ 監視する⽬的 ‣ 監視ツール

Slide 38

Slide 38 text

何をモニタリングするか ‣ アプリケーションレイヤ ‣ APM,トレース ‣ インフラストラクチャレイヤ ‣ メトリック（Gauge, Counter） ‣ ログ ‣ 正規化されていない⽂字列データ ‣ パフォーマンス ‣ 外形監視(Synthetic), Apdex http://www.xtbg.ac.cn/ydhz/hzdt/201102/t20110225_3075706.html

Slide 39

Slide 39 text

何をモニタリングするか(cont.) ‣ ⾼解像度(1s)・短期間(オンデマンド) ‣ 現在進⾏中の事象調査 ‣ ping、top系コマンド（htop, Glances）、netdata ‣ 中〜低解像度(1min〜1d)・中〜⻑期間(〜1y〜) ‣ 中⻑期的な傾向把握・将来予測、ふるまいの把握 ‣ ソリューション（オンプレ、SaaS）+ 式・機械学習 ‣ イベントドリブン ‣ 発⽣した事象の詳細・関連性調査 ‣ トレース・ログ解析

Slide 40

Slide 40 text

なんのために︖ ‣ KPI ‣ パフォーマンス(応答速度)向上、チューニング ‣ UI/UX - A/Bテスト、ヒートマップ、滞在時間・離脱率 ‣ 可⽤性、「障害を起こさない」、セキュリティ ‣ リソース管理 - コスト効率の向上 ‣ 継続的なテスト ‣ チェック監視（正常な状態から外れていないか、という意味で） ※機能要件・⾮機能要件の境は曖昧

Slide 41

Slide 41 text

それからどうする︖ ‣ ⾃動対応 ‣ 再起動、オートスケール、詳細情報の収集(gathering) ... ‣ 通知・エスカレーション ‣ 即時 -> ⼈間による即対応を促す ‣ 定期的レポーティング(〜⽇次、⽉次、年次) ‣ 記録のみ ‣ 将来的な利⽤

Slide 42

Slide 42 text

どうモニタリングする︖ ‣ 式による監視、異常検知(ふるまい検知、外れ値検知) ‣ 代表値での監視 ‣ 時系列・関連付け ‣ ダッシュボード ‣ 監視SaaS / 運⽤SaaS ‣ ⾃動化(Automation)

Slide 43

Slide 43 text

式による監視、異常検知(ふるまい検知、外れ値検知) ‣ 統計的⼿法、ML ‣ 個々の値に⼀喜⼀憂しない、全体傾向をみる ‣ S/N⽐の向上、認識補助 ‣ ノイズの除去、有意メトリックのふるい分け ‣ セキュリティインシデントの検知的な側⾯ ‣ ex) GuardDuty（これぞ「監視」って感じでは︖）

Slide 44

Slide 44 text

代表値での監視 ‣ 外形監視 - ネットワーク含めシステム全体の応答遅延 ‣ シングル、シナリオ ‣ 多拠点からの観測 -> クライアントアクセスをシミュレート ‣ Apdex - 応答速度の点から「顧客満⾜度」を図る ‣ https://newrelic.degica.com/docs/apm/new-relic-apm/apdex/ apdex-measuring-user-satisfaction ‣ LoadAverage - OS内I/O遅延 ‣ UNIX初期からある「システムのパフォーマンス」指標

Slide 45

Slide 45 text

ダッシュボード ‣ 複数要素の同時監視 ‣ システム横断、リソース横断、ログ＋メトリック ‣ エンジニアリングだけでなくビジネスレイヤでも ‣ KPI ‣ パフォーマンス

Slide 46

Slide 46 text

監視SaaS / 運⽤SaaS ‣ 「監視システムのお守り」は業務ですか︖ ‣ 数の暴⼒を享受しよう ‣ ポイント ‣ メトリクスの保存期間 - シーズナル要因を⾒極めるための年単位、Max/Ave/中央値 ‣ 監視対象のグルーピング⽅式 - タグ付け、カテゴライズ、サービス/ロール ‣ 通知の柔軟性 - フラッピング抑制 ‣ ⾒た⽬、操作性 - ある意味もっとも重要︕ 毎⽇眺めたくなるものを ‣ 多⾓的な表⽰、分析機能、拡張性 etc.

Slide 47

Slide 47 text

監視ソリューションにこだわらない監視 ‣ 例 : IoT Bot の監視（re:Invent 2018 DEV311） ‣ 各IoTは定期的にステータスをDynamoDBにアップロード ‣ ステータスのアップデートが途絶えた = 死と判断する https://dev.classmethod.jp/cloud/aws/practial-monitoring-bookreview/

Slide 48

Slide 48 text

⾃動化(Automation) ‣ ヘルスチェックは⽴派な監視 ‣ failoverは⽴派な⾃動運⽤ ‣ 「⾃動化は信⽤ならない」 ‣ 「信⽤出来るところに⾃動化を使う」「⾃動化出来ない部分は減らしていく」 ‣ 「なんでも⾃動化すればええんや」

Slide 49

Slide 49 text

参考︓「運⽤⾃動化」とは ‣ 波⽥野裕⼀⽒ ‣ 運⽤設計ラボ合同会社所属 ‣ 「不都合な真実」で有名 ‣ もっと広い「運⽤⾃動化」についての提⾔ ‣ ぜひ⼀度ご⼀読を https://speakerdeck.com/opelab/20190306-operation-what-automation

Slide 50

Slide 50 text

再掲 : 監視︖ monitoring? ‣ 監視のイメージ ‣ 監視カメラ ‣ モニタリングのイメージ ‣ ○○ウォッチング、モニタリング(観測・計測)ポスト

Slide 51

Slide 51 text

つまり ‣ むかし ‣ 1台1台が貴重、重い、できるだけ個々を⽌めないようにする、リソースも⾼く有限だったのでピンポイント、監視コストが⾼い ‣ 監視するほうも、されるほうも ‣ 通信帯域が制限 = 監視対象にちかいところで監視 ‣ 通知⼿段も限定的(ポケベル、⾳声電話)、DCまで物理移動 ‣ 連絡を受けてひとが対応

Slide 52

Slide 52 text

つまり ‣ いま ‣ 無尽蔵のクラウドリソース、監視コストが低い、多量のデータを素早く処理できる ‣ 監視するほうも、されるほうも ‣ 通信帯域が潤沢 = ネットワーク越しでいい -> SaaS ‣ インフラもクラウド、スマホで再起動やらスケールアップやら ‣ アラートを受けるのは⾃動化装置、報告のみ受け取る

Slide 53

Slide 53 text

AWS Well-Architected Framework 運⽤の優秀性 ‣ 期待される成果を定義し（中略）正しく運⽤できているかどうかを判断するために使われるシステムと運⽤に関するメトリクスを特定 ‣ メトリクスを収集して分析（中略）顧客やビジネスニーズを満たせているかを確認し、改善 ‣ メトリクスをビジネスニーズと整合させる（中略）⼀元化されていない⼿動で取得されたメトリクスは、計画外のイベントが発⽣した際にシステムの運⽤を⼤きく妨げる結果につながります https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_ﬁnal.pdf https://d1.awsstatic.com/events/jp/2017/summit/slide/D2T1-1.pdf

Slide 54

Slide 54 text

؂ࢹ4BB4ӡ༻4BB4 ‣ 監視(monitoring)と運⽤(operation) ‣ pushとpull ‣ , 鯖, ⽝, 遺跡, 相撲 etc.

Slide 55

Slide 55 text

監視(monitoring) ‣ AWS ‣ CloudWatch, X-Ray ... ‣ 汎⽤(網羅的)・インフラ寄り ‣ Datadog, Mackerel, Stackdriver ... ‣ 特定⽤途寄り ‣ NewRelic, sumoLogic, Pingdom ... ‣ 他にもセキュリティ向けなど運⽤(operation) ‣ AWS ‣ Systems Manager (SSM), SNS ... ‣ 通知・通知⽀援 ‣ PagerDuty, Slack ... ‣ ⾃動化⽀援 ‣ Opsgenie, Turbot ... ざっくり

Slide 56

Slide 56 text

オレオレ監視システム⼊⾨「監視」より抜粋︓ ‣ 2.3 デザインパターン3︓作るのではなく買う ‣ “ひと握りの企業はさらに⼤きくなり、ユニークな問題やニーズを満たすための独⾃の監視プラットフォームを構築します。Netﬂix、Dropbox、Twitterと⾔った企業は、このグループに属します。” ‣ “多くの点に関して、私は監視の SaaS ソリューションの⽀持者です。5 年間は悩む必要はなく SaaS を監視に使うべきだというのが私の考えです。” ‣ 2.3.1 安いから ‣ 2.3.2 あなたは（おそらく）監視ツールを設計する専⾨家ではないから ‣ 2.3.3 SaaS を使うとプロダクトにフォーカスできるから ‣ 2.3.4 実際のところ SaaS の⽅がよいから

Slide 57

Slide 57 text

push or pull ‣ 監視サーバ(マネージャ)と監視クライアント(エージェント)間の通信⽅法 ‣ push ... エージェント -> マネージャ ‣ pull ... マネージャ -> エージェント ‣ いわゆるポーリング ‣ 実際問題として、どちらかだけ、というものはない ‣ 例 1 ‣ 登録・メトリック送信は push / 死活や必要に応じてマネージャから pull ‣ 例 2 ‣ メトリックや死活判定は push / 登録はクラウドインフラのAPIから pull ‣ 例 3 ‣ ログは push / 外形監視は pull (polling) ‣ ※製品によっては「○○型」と謳っているものも

Slide 58

Slide 58 text

Amazon Web Services ‣ 純正の安⼼感と流⽯のAWS連携 ‣ CloudWatch ‣ metrics / Agent / Event / Alarm / Logs / Dashboards ‣ CW Logs Insights / Container Insights (New!) ‣ AWS X-Ray ‣ Amazon Route 53 Healthcheck ‣ HTTP/HTTPS接続監視からの CW Events発⽕ ‣ AWS Systems Manager, Lambda, SNS etc. https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/welcome-health-checks.html

Slide 59

Slide 59 text

Mackerel ‣ みんな⼤好き ‣ mackerel-agent / -container-agent, Agentプラグイン, check -> action ‣ AWSインテグレーションでCWメトリクス収集 ‣ 外形監視（L7） ‣ ダッシュボード ‣ 各種Webhook連携 ‣ 国産 ‣ シフト＆リフトのフェーズで使いやすい（偏⾒） ‣ インフラメトリクス監視に寄りがち

Slide 60

Slide 60 text

Datadog ‣ みんな⼤好き ‣ Infra, Metrics, 外形, APM, Trace, Logs, Dashboard ‣ AWSインテグレーション ‣ AWSと密接、莫⼤な開発リソース ‣ Infraから始まって網羅的に機能拡充中 ‣ 外形監視がこの3⽉にGA（API Test / Browser Test） ‣ APMもできる（こなれているかは︖ ‣ これから⽇本市場に⼒をいれていく（らしい

Slide 61

Slide 61 text

New Relic, Stackdriver ‣ New Relic ‣ APM, Analyze, Infrastructure, 外形, フロントエンド, リアルユーザ ‣ Apdexの発明元（パフォーマンス = 顧客満⾜度の指標） ‣ イベントドリブンからのドリルダウン（Stack trace, Server status） ‣ アプリ寄りの出⾃。ログはこれから ‣ Stackdriver ‣ いまはGoogle = GCPとの密接な連携 ‣ AWSインテグレーション(コネクタ) ‣ Monitoring, Logging, Error Reporting, Trace, Debugger

Slide 62

Slide 62 text

sumoLogic ‣ ログ解析重点 ‣ 「ログを収集・分析・可視化するSaaS」（弊社加藤・談） ‣ インポートしてしまえば強⼒な正規化・分析⽀援を施せる ‣ 別途収集のメトリックと時系列で並べられる ‣ コマンドラインで⾔えば top ではなく grep/sed/awk/sort や Perl・Ruby の代替 ‣ リアルタイムよりは分析で威⼒を発揮 ‣ 障害、セキュリティイシューの調査 ‣ 定期的なレポーティングやアラート設定も可能 ‣ OSSでいえば Elasticsearch + logstash + Kibana ‣ 対抗は Splunk https://dev.classmethod.jp/cloud/aws/jaws_days_2019_sumologic/

Slide 63

Slide 63 text

Pingdom ‣ 外形監視特化 ‣ Uptime Monitoring - 複数拠点からの死活監視 ‣ Performance / Real User Monitoring ‣ Transaction Monitoring ‣ Page speed Monitoring ‣ アラート通知、インフラ監視も ‣ Server monitor - StatsD, インテグレーション, ダッシュボード

Slide 64

Slide 64 text

·ͱΊ

Slide 65

Slide 65 text

まとめ ‣ 監視 or モニタリング ‣ 監視 -> 異常を⾒つけて通知することが主眼 ‣ モニタリング -> 定期的な計測、異常があったら対処 ‣ ⾃動対応 or 通知 ‣ 対象がかわったのでやり⽅もかわる ‣ SaaSの積極的な利⽤がコストダウンに繋がる ‣ なんとなしに始めるのは危険、⾼く付く可能性 ‣ まず計測から・無料枠からはじめよう︕

Slide 66

Slide 66 text

No content