Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for Seigo Watanabe Seigo Watanabe
May 30, 2019
2.5k

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

「入門『監視』」みなさん読まれましたか? 長くインフラ運用に携わっている方(僕です)は、読んで何かしらの違和感を感じたのではないでしょうか。 監視・運用を取り巻く環境の変化をふまえ、何を使って何をどう「監視」すれば良いのかを探ります。

Avatar for Seigo Watanabe

Seigo Watanabe

May 30, 2019
Tweet

More Decks by Seigo Watanabe

Transcript

  1. 渡辺聖剛 ‣ʼ17/01⼊社 ‣AWS事業本部オペ部所属 ‣インターネット⽼⼈会 ‣前職までは所謂インフラエンジニア ‣汎⽤機(ʼ95~) -> ISP (Y2K~) ->

    SIer (~ʼ10) -> ⾃他社Web構築運⽤ ‣(特に)好きなAWSサービス ‣Route 53、AWS Systems Manager ࣗݾ঺հ  
  2. 19xx〜   ‣ 汎⽤機(ダム端末 - 中央集権型) ‣ オープンシステム(UNIX +

    TCP/IP, CS型) ‣ インターネット(PC UNIX, x86) ‣ Web2.0(⾔語フレームワーク, モバイル) ‣ 4G(LTE) + スマートフォン ‣ クラウド(アプリ, インフラ)
  3. はなすこと(Agenda)   ‣ そもそも「監視」って何さ︖ ‣ 監視される対象が変化している ‣ 監視する⽬的と価値も変化している ‣

    監視する側の⽴場と価値観も(ry ‣ それに合わせてツールも(ry ‣ いまどんなものがある︖
  4. 「⼊⾨」︖   ‣ ⼊⾨「監視」―モダンなモニタリングのためのデザインパターン ‣ @hamako9999 の記事 -> ‣

    原題 : Practical Monitoring: Effective Strategies for the Real World ‣ Practical = 実⽤的・実践的 ‣ “relating to real situations and events rather than ideas, emotions etc”(ロングマン現代英英辞典より) ‣ Effective = 効果的な (「⼊⾨」...? https://dev.classmethod.jp/cloud/aws/practial-monitoring-bookreview/
  5. 監視︖ monitoring? (cont.)   ‣ 監視のイメージ ‣ 監視カメラ ‣

    モニタリングのイメージ ‣ ◦◦ウォッチング、モニタリング(観測・計測)ポスト 英語と⽇本語で⾔葉のイメージがずいぶんと違う →翻訳物を読むときに気をつけたいポイント →(…⾔語の違いだけだろうか︖)
  6. 「F1に例えたら︖」   ‣ 岡⽥良太郎(アスタリスク・リサーチ) ‣ hbstudy(主催・株式会社ハートビーツ) ‣ #87「Hardening に参加しよう︕」

    ‣ 1:43:00〜 https://youtu.be/liPWCeB0lw0?t=6180 ‣ ハードニングというセキュリティイベントの話をしているとき
  7. もしもシステムがF1だったら︖   ‣ F1 = サーキット周回カーレース ‣ F1ドライバー、ピットクルー ‣

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

    ‣ ピットクルー = 運⽤担当者 ‣ ⾞の製造 = 開発担当者 ‣ レース(サービス運⽤)はアプリが動作させる ‣ ⾞の調⼦はピットクルー(運⽤担当)が⾒る
  9. もしもシステムがF1だったら︖(cont.)   ‣ 岡⽥⽒の答え︓ ‣ ⾞ +ドライバー =Ops(運⽤担当者) ‣

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

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

    ‣ ピットクルー = 運⽤担当者 ‣ ⾞の製造 = 開発担当者 ‣ レース(サービス運⽤)はアプリが動作させる ‣ ⾞の調⼦はピットクルー(運⽤担当)が⾒る →(よく考えたら)ウォーターフォール的な考え⽅
  12. DevOps時代のモニタリング   ‣ DevOps時代において ‣ 「システムが動いて初めて価値を⽣む」(岡⽥⽒) ‣ メトリックを「次のイテレーション(周回)を回す判断材料として」取 得することが重要

    ‣ 蓄積 -> 分析 ‣ ならば「アラート」とは︖ ‣ アラート : 何かしらの「好ましくない事態」を検知したことによる通知 ‣ アラート(通知)を受け取るのは誰だろう
  13. 再掲 : 198x〜   ‣ 汎⽤機(ダム端末 - 中央集権型) ‣

    オープンシステム(UNIX + TCP/IP, CS型) ‣ インターネット(PC UNIX, x86) ‣ Web2.0(⾔語フレームワーク, モバイル) ‣ 4G(LTE) + スマートフォン ‣ クラウド(アプリ, インフラ)
  14. 汎⽤機環境   ‣ ダム端末、中央集権型 ‣ CUI ‣ ジョブの正常性監視 ->

    異常終了時にアラート ‣ ハードウェアの⾒回り(⽬視) ‣ ⽇次〜の⾃⼰診断(diagnostics) ‣ ⽉次〜でAct/Std切り替え・定期メンテナンス
  15. オープンシステム環境   ‣ 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
  16. インターネット環境   ‣ 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
  17. Web2.0環境の運⽤・モニタリング   ‣ ⾔語フレームワーク(Ruby on Rails) ‣ モバイル(フィーチャーフォン) ‣

    ビッグデータ(⼤量データの⾼速分析) ‣ WebAPI ‣ OSSツールの進化 ‣ MRTG -> RRDTool、Cacti ‣ BigBrother, Hobbit -> Zabbix ‣ NetSaint -> Nagios ‣ APM(Application Performance Management) ‣ Webアプリケーションの複雑化とパフォーマンスチューニングの必要性 ‣ NewRelic (2008〜)
  18. ここ5年10年の運⽤・モニタリング   ‣ LTE + スマフォ、⼤陸間/⼤帯域/⾼速/低遅延 通信 ‣ UI/UX、リッチコンテンツ

    ‣ 売り切りパッケージ -> スマフォアプリ・Webサービス ‣ 動画配信、インタラクティブコンテンツ(30fps↑ゲームコンテンツ) ‣ クラウドインフラ ‣ サーバ側 : Infrastructure as Code、コンテナ ‣ クライアント側 : マルチデバイス、IoT ‣ ML(機械学習による⼤容量データの準リアルタイム分析・予測)
  19. 四半世紀の変化   ‣ 需要(市場の要求)と供給(技術的な進歩) ‣ コンピュート能⼒の向上 ‣ インフラのソフトウェア化(Software-Defined anything[*1](SDx)、クラウドインフラ)

    ‣ ネットワークの⾼速化(⼤帯域、低遅延、CDNの⼤衆化) ‣ ストレージの低廉化 ‣ ソフトウェアアプリケーションの複雑化、UI/UXのリッチ化 ‣ 機械学習の⼤衆化 ‣ 速度の重要性が爆上がり(応答速度、開発速度) ‣ 「システムの継続性・堅牢性」より「ビジネスの継続性・堅牢性」 *1 : https://www.sbbit.jp/article/cont1/29935
  20. ʮ୲౰ൣғʯͷมԽYYYY   -"/ αʔό )8 04 ϛυϧ ΢ΣΞ ΞϓϦέʔγϣϯ

    ϋʔυ΢ΣΞϚΠΫϩίʔυυϥΠό ιϑτ΢ΣΞ ϋʔυ΢ΣΞ Ծ૝)8 4%Y ιϑτ΢ΣΞ ΞϓϦέʔγϣϯ ίϯςφ 04 ϛυϧ ΢ΣΞ σʔληϯλ ϑΝγϦςΟ ‣ 純粋なハードウェアの領域 の⼤部分がSDxに置き換え られる ‣ インフラのソフトウェア化 ‣ マネージドインフラ ‣ 純粋な「インフラ」担当の 領域とするより、アプリと ⼀体化して考えたほうが良 い傾向が強くなる ※オンプレが無くなった__ _わけではない 'BB4 Ϛωʔδυ
  21. どこを何で監視(モニタリング)する︖   ‣ ここ数10年程で⾒るべき場所と⽬的が変化している ‣ そのために使える技術も⾶躍的に進化している ‣ その時々で最適な道具と⼿法が使われてきた ‣

    10年前の常識で監視・モニタリングしてませんか︖ ‣ 監視される側の可観測性(Observability)はあがっている ‣ どこをどう監視すべきか、⼀番詳しいひとは誰だろう
  22. CERN Data Centre Evolution   ‣ Published on Nov

    19, 2012 https://www.slideshare.net/gmccance/cern-data-centre-evolution#17
  23. ‣ 家畜(cattle)モデル ‣ 1台1台は最低限 ‣ 全体のパフォーマンスを重視 「ペットと家畜」モデルにおけるモニタリング   ‣

    ペット(pet)モデル ‣ 1台1台のサーバから丁寧な メトリックを取得 http://www.tokyowest-ah.jp/medicals/sort_anesthetic.html https://www.titech.ac.jp/news/2019/043843.html
  24. 「ペットと家畜」モデルにおけるモニタリング(cont.)   ‣ クラウドインフラ=「H/Wを⻑持ちさせる」という 視点がない ‣ 100%までぶん回していい -> 「とりあえず閾値90%」︖

    ‣ ⾃在にスケールアウト・スケールアップ -> 動いているこ とが⼤切 ‣ Design for failure -> 1つ2つ落ちることは織り込み済み ‣ その代わりの「従量課⾦」-> 警告するべき視点の変化
  25. ex) プロセスが落ちることとサーバが落ちることにどんな差が︖   ‣ どちらも「サービスが継続出来なくなる」ことに変わりない ‣ 昔 -> OS再起動にコスト⼤

    -> プロセスだけ再起動しよう ‣ ペット化されたインフラは個体差も⼤きく複雑 ‣ モノリシック、密結合 ‣ いま -> コンテナ作り直せば︖ ‣ IaC, Immutable Infrastructure ‣ マイクロサービス、疎結合
  26. 何をモニタリングするか   ‣ アプリケーションレイヤ ‣ APM,トレース ‣ インフラストラクチャレイヤ ‣

    メトリック(Gauge, Counter) ‣ ログ ‣ 正規化されていない⽂字列データ ‣ パフォーマンス ‣ 外形監視(Synthetic), Apdex http://www.xtbg.ac.cn/ydhz/hzdt/201102/t20110225_3075706.html
  27. 何をモニタリングするか(cont.)   ‣ ⾼解像度(1s)・短期間(オンデマンド) ‣ 現在進⾏中の事象調査 ‣ ping、top系コマンド(htop, Glances)、netdata

    ‣ 中〜低解像度(1min〜1d)・中〜⻑期間(〜1y〜) ‣ 中⻑期的な傾向把握・将来予測、ふるまいの把握 ‣ ソリューション(オンプレ、SaaS)+ 式・機械学習 ‣ イベントドリブン ‣ 発⽣した事象の詳細・関連性調査 ‣ トレース・ログ解析
  28. なんのために︖   ‣ KPI ‣ パフォーマンス(応答速度)向上、チューニング ‣ UI/UX -

    A/Bテスト、ヒートマップ、滞在時間・離脱率 ‣ 可⽤性、「障害を起こさない」、セキュリティ ‣ リソース管理 - コスト効率の向上 ‣ 継続的なテスト ‣ チェック監視(正常な状態から外れていないか、という意味で) ※機能要件・⾮機能要件の境は曖昧
  29. それからどうする︖   ‣ ⾃動対応 ‣ 再起動、オートスケール、詳細情報の収集(gathering) ... ‣ 通知・エスカレーション

    ‣ 即時 -> ⼈間による即対応を促す ‣ 定期的レポーティング(〜⽇次、⽉次、年次) ‣ 記録のみ ‣ 将来的な利⽤
  30. 式による監視、異常検知(ふるまい検知、外れ値検知)   ‣ 統計的⼿法、ML ‣ 個々の値に⼀喜⼀憂しない、全体傾向をみる ‣ S/N⽐の向上、認識補助 ‣

    ノイズの除去、有意メトリックのふるい分け ‣ セキュリティインシデントの検知的な側⾯ ‣ ex) GuardDuty(これぞ「監視」って感じでは︖)
  31. 代表値での監視   ‣ 外形監視 - ネットワーク含めシステム全体の応答遅延 ‣ シングル、シナリオ ‣

    多拠点からの観測 -> クライアントアクセスをシミュレート ‣ Apdex - 応答速度の点から「顧客満⾜度」を図る ‣ https://newrelic.degica.com/docs/apm/new-relic-apm/apdex/ apdex-measuring-user-satisfaction ‣ LoadAverage - OS内I/O遅延 ‣ UNIX初期からある「システムのパフォーマンス」指標
  32. 監視SaaS / 運⽤SaaS   ‣ 「監視システムのお守り」は業務ですか︖ ‣ 数の暴⼒を享受しよう ‣

    ポイント ‣ メトリクスの保存期間 - シーズナル要因を⾒極めるための年単位、Max/Ave/中央値 ‣ 監視対象のグルーピング⽅式 - タグ付け、カテゴライズ、サービス/ロール ‣ 通知の柔軟性 - フラッピング抑制 ‣ ⾒た⽬、操作性 - ある意味もっとも重要︕ 毎⽇眺めたくなるものを ‣ 多⾓的な表⽰、分析機能、拡張性 etc.
  33. 監視ソリューションにこだわらない監視   ‣ 例 : IoT Bot の監視(re:Invent 2018

    DEV311) ‣ 各IoTは定期的にステータスをDynamoDBにアップロード ‣ ステータスのアップデートが途絶えた = 死と判断する https://dev.classmethod.jp/cloud/aws/practial-monitoring-bookreview/
  34. ⾃動化(Automation)   ‣ ヘルスチェックは⽴派な監視 ‣ failoverは⽴派な⾃動運⽤ ‣ 「⾃動化は信⽤ならない」 ‣

    「信⽤出来るところに⾃動化を使う」「⾃動化出来ない部分は減ら していく」 ‣ 「なんでも⾃動化すればええんや」
  35. 参考︓「運⽤⾃動化」とは   ‣ 波⽥野裕⼀⽒ ‣ 運⽤設計ラボ合同会社所属 ‣ 「不都合な真実」で有名 ‣

    もっと広い「運⽤⾃動化」につい ての提⾔ ‣ ぜひ⼀度ご⼀読を https://speakerdeck.com/opelab/20190306-operation-what-automation
  36. 再掲 : 監視︖ monitoring?   ‣ 監視のイメージ ‣ 監視カメラ

    ‣ モニタリングのイメージ ‣ ◦◦ウォッチング、モニタリング(観測・計測)ポスト
  37. つまり   ‣ むかし ‣ 1台1台が貴重、重い、できるだけ個々を⽌めないようにする、 リソースも⾼く有限だったのでピンポイント、監視コストが⾼い ‣ 監視するほうも、されるほうも

    ‣ 通信帯域が制限 = 監視対象にちかいところで監視 ‣ 通知⼿段も限定的(ポケベル、⾳声電話)、DCまで物理移動 ‣ 連絡を受けてひとが対応
  38. つまり   ‣ いま ‣ 無尽蔵のクラウドリソース、監視コストが低い、多量のデータ を素早く処理できる ‣ 監視するほうも、されるほうも

    ‣ 通信帯域が潤沢 = ネットワーク越しでいい -> SaaS ‣ インフラもクラウド、スマホで再起動やらスケールアップやら ‣ アラートを受けるのは⾃動化装置、報告のみ受け取る
  39. AWS Well-Architected Framework 運⽤の優秀性   ‣ 期待される成果を定義し(中略)正し く運⽤できているかどうかを判断する ために使われるシステムと運⽤に関す

    るメトリクスを特定 ‣ メトリクスを収集して分析(中略)顧 客やビジネスニーズを満たせているか を確認し、改善 ‣ メトリクスをビジネスニーズと整合さ せる(中略)⼀元化されていない⼿動 で取得されたメトリクスは、計画外の イベントが発⽣した際にシステムの運 ⽤を⼤きく妨げる結果につながります https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_final.pdf https://d1.awsstatic.com/events/jp/2017/summit/slide/D2T1-1.pdf
  40. 監視(monitoring) ‣ AWS ‣ CloudWatch, X-Ray ... ‣ 汎⽤(網羅的)・インフラ寄り ‣

    Datadog, Mackerel, Stackdriver ... ‣ 特定⽤途寄り ‣ NewRelic, sumoLogic, Pingdom ... ‣ 他にもセキュリティ向けなど 運⽤(operation) ‣ AWS ‣ Systems Manager (SSM), SNS ... ‣ 通知・通知⽀援 ‣ PagerDuty, Slack ... ‣ ⾃動化⽀援 ‣ Opsgenie, Turbot ... ざっくり  
  41. オレオレ監視システム   ⼊⾨「監視」より抜粋︓ ‣ 2.3 デザインパターン3︓作るのではなく買う ‣ “ひと握りの企業はさらに⼤きくなり、ユニークな問題やニーズを満たすための独⾃の監視プラット フォームを構築します。Netflix、Dropbox、Twitterと⾔った企業は、このグループに属します。” ‣

    “多くの点に関して、私は監視の SaaS ソリューションの⽀持者です。5 年間は悩む必要はなく SaaS を監視に使うべきだというのが私の考えです。” ‣ 2.3.1 安いから ‣ 2.3.2 あなたは(おそらく)監視ツールを設計する専⾨家ではないから ‣ 2.3.3 SaaS を使うとプロダクトにフォーカスできるから ‣ 2.3.4 実際のところ SaaS の⽅がよいから
  42. push or pull   ‣ 監視サーバ(マネージャ)と監視クライアント(エージェント)間の通信⽅法 ‣ push ...

    エージェント -> マネージャ ‣ pull ... マネージャ -> エージェント ‣ いわゆるポーリング ‣ 実際問題として、どちらかだけ、というものはない ‣ 例 1 ‣ 登録・メトリック送信は push / 死活や必要に応じてマネージャから pull ‣ 例 2 ‣ メトリックや死活判定は push / 登録はクラウドインフラのAPIから pull ‣ 例 3 ‣ ログは push / 外形監視は pull (polling) ‣ ※製品によっては「◦◦型」と謳っているものも
  43. 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
  44. Mackerel   ‣ みんな⼤好き ‣ mackerel-agent / -container-agent, Agentプラグイン,

    check -> action ‣ AWSインテグレーションでCWメトリクス収集 ‣ 外形監視(L7) ‣ ダッシュボード ‣ 各種Webhook連携 ‣ 国産 ‣ シフト&リフトのフェーズで使いやすい(偏⾒) ‣ インフラメトリクス監視に寄りがち
  45. Datadog   ‣ みんな⼤好き ‣ Infra, Metrics, 外形, APM,

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

    Analyze, Infrastructure, 外形, フロントエンド, リアルユーザ ‣ Apdexの発明元(パフォーマンス = 顧客満⾜度の指標) ‣ イベントドリブンからのドリルダウン(Stack trace, Server status) ‣ アプリ寄りの出⾃。ログはこれから ‣ Stackdriver ‣ いまはGoogle = GCPとの密接な連携 ‣ AWSインテグレーション(コネクタ) ‣ Monitoring, Logging, Error Reporting, Trace, Debugger
  47. sumoLogic   ‣ ログ解析重点 ‣ 「ログを収集・分析・可視化するSaaS」(弊社加藤・談) ‣ インポートしてしまえば強⼒な正規化・分析⽀援を施せる ‣

    別途収集のメトリックと時系列で並べられる ‣ コマンドラインで⾔えば top ではなく grep/sed/awk/sort や Perl・Ruby の代替 ‣ リアルタイムよりは分析で威⼒を発揮 ‣ 障害、セキュリティイシューの調査 ‣ 定期的なレポーティングやアラート設定も可能 ‣ OSSでいえば Elasticsearch + logstash + Kibana ‣ 対抗は Splunk https://dev.classmethod.jp/cloud/aws/jaws_days_2019_sumologic/
  48. Pingdom   ‣ 外形監視特化 ‣ Uptime Monitoring - 複数拠点からの死活監視

    ‣ Performance / Real User Monitoring ‣ Transaction Monitoring ‣ Page speed Monitoring ‣ アラート通知、インフラ監視も ‣ Server monitor - StatsD, インテグレーション, ダッシュボード
  49. まとめ   ‣ 監視 or モニタリング ‣ 監視 ->

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