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

Observability & APM 入門 〜2023年のIT運用/監視の流行語はこれだ!

Observability & APM 入門 〜2023年のIT運用/監視の流行語はこれだ!

本資料は次のイベントの投影資料です。

<イベントURL>
https://studyco.connpass.com/event/270279/

<概要>
皆さんは「Observability」(可観測性) や「APM」(Application Performance Management, アプリケーション性能管理) という言葉を聞いたことはあるでしょうか?

私事で恐縮ですが、2022年をふりかえった時、ずっとこれらの言葉がリフレインしていた気がします笑

しかし、おそらくまだまだ世間一般には浸透はしているとは言い難い言葉で、言葉がリフレインするという私に共感してくれる方も少ないのではないかと感じています...

...ということで、2023年に私と一緒にこれらの言葉がリフレインするような仲間を作るため、何なら流行語を狙ってみようというモチベで本イベントを開催させていただきます!

もう少し真面目な説明をすると、「Observability」や「APM」は主にIT運用や監視など、いわゆるDay2 オペレーションの領域で最近注目されているものです。

背景としては、マイクロサービスの普及などに伴ってどんどんシステムが複雑化し、ユーザによるシステム稼働への要求レベルも上がっている状況があります。

このような状況に対して、KubernetesプロジェクトなどでOSS業界で有名な CNCF (Cloud Native Computing Foundation) もホワイトペーパーなどでObservabilityの重要性や技術を発信しております。

また、企業がObservabilityを実現するにあたって手段の一つとしてAPMへの関心も高まっており、マーケットも拡大しております。

今回はこのような「Observability」や「APM」を入門レベルで知っていただくこと、興味を持っていただくことを目標として、概要の説明とAPMソリューションの1つである Instana のデモンストレーションを実施します。

Takahiro Esaki

January 12, 2023
Tweet

More Decks by Takahiro Esaki

Other Decks in Technology

Transcript

  1. - 1 - - 1 - Observability & APM ⼊⾨

    〜2023年のIT運⽤/監視の流⾏語はこれだ︕ - Instanaのデモンストレーションを添えてご紹介 2023/01/12 Takahiro Esaki 1
  2. - 2 - - 2 - 講師紹介 【経歴】 n東京⼤学 ⽂学部

    ⼼理学専修課程 卒業 • 専⾨︓⾼次認知(記憶・学習・⾏動 など) n業務/ITコンサルティング • 基幹システム運⽤保守業務改⾰ • 基幹システム刷新PMO • サプライチェーン最適化/需要予測最適化 • データ分析システム刷新PM/アーキテクチャ設計 など n新規事業開発・アジャイル開発・ローコード開発 • クラウドソーシングプラットフォームサービス • アパレルプラットフォームサービス • 海外クリエーター向けe-Learningサービス など nCSM (カスタマーサクセスマネージャー) @IBM Japan※ • AI & Cloudソリューションの活⽤促進 • コミュニティ活動・アドボケート活動 など ※本講演・本資料は IBM Japan, Ltd. を代表するものではございません 江﨑 崇浩 (Takahiro Esaki) Twitter @t_esaking LinkedIn CSMをご紹介する記事を執筆しましたので、ぜひご確認ください︕ https://www.imagazine.co.jp/customer-success-manager/
  3. - 3 - - 3 - アジェンダ 1 ͸͡Ίʹ 2

    Observabilityͷઆ໌ 3 APMͷઆ໌ɾInstanaͷσϞ 4 ͓ΘΓʹ
  4. - 4 - - 4 - アジェンダ 1 ͸͡Ίʹ 2

    Observabilityͷઆ໌ 3 APMͷઆ໌ɾInstanaͷσϞ 4 ͓ΘΓʹ
  5. - 10 - - 10 - まあ、落ち着いてください お そ ろ

    し く 速 い ⾃ 然 な 導 ⼊ 参考︓HUNTER×HUNTER 本⽇は個⼈的な流⾏語の1つ「Observability」の話をします︕ (⼤事なことなので2回良いましたが、団⻑の⼿⼑を⾒逃さなかった⼈のおかげで⼤丈夫ですね︕)
  6. - 11 - - 11 - 本⽇のモチベと期待 n 本⽇はソフトウェアライフサイクルの中の、「Day2オペレーション」のテーマになります Day0

    • 計画 • 設計 • 調達 Day1 • 構築 • 初期設定 Day2 • 運⽤ (監視/メンテナンス/ト ラブル対応 など) 本⽇のテーマ (講師のモチベ) n 2022年のふりかえり︓「開発」する視点だけでなく、「運⽤」する視点も⼤事︕ n 2023年も「Observability」がもっと熱くなってくると思うので伝えたい︕ (期待) n 「運⽤」「Observability」「APM」をよく知らない⼈たち︓ 興味を持っていただく。知識をつけていただく。周りに伝えていただく n 「運⽤」「Observability」「APM」を知っている⼈たち︓ 改めて整理して、より⾝近に感じていただく。講師の説明不⾜があれば、宜しければフォロー願います ※Observability = 可観測性 ※APM (Application Performance Management) = アプリケーション性能管理
  7. - 12 - - 12 - 本⽇のテーマの概念イメージ 従来の監視 Monitoring 可観測性

    Observability APM Application Performance Management n 従来の監視 & Observability & APM
  8. - 13 - - 13 - アジェンダ 1 ͸͡Ίʹ 2

    Observabilityͷઆ໌ 3 APMͷઆ໌ɾInstanaͷσϞ 4 ͓ΘΓʹ
  9. - 14 - - 14 - 従来の監視 vs Observability (可観測性)

    n マイクロサービス化など環境変化を背景に、従来の監視に対するアンチテーゼとしてObservabilityが注 ⽬されている 従来の監視 Monitoring 可観測性 Observability APM Application Performance Management • レガシー/モノシリック • オンプレ中⼼ • マイクロサービス • クラウドネイティブ 環境の変化 • 複数のシステム/基盤にわたるデー タの収集 • システム全体の振る舞いを理解し て、サービス改善に取り組む • 主要シグナルは、メトリック・ト レース・ログ • 積極的な対応 (Proactive)を⽬指す • 特定のシステム/基盤の視点 でデータの収集 • あらかじめ閾値を設定。障 害アラートを受けてインシ デント対応 • 事後的な対応 (Passive) に なりがち
  10. - 15 - - 15 - 参考︓監視 (Monitoring) n 監視についての全体的な整理をするための参考情報は次の通り

    監視観点 ⽬的 具体的な監視対象 ビジネスKPI ユーザがサービスを利⽤できているか、 サービスは期待効果を創出しているか、シ ステムがどのライフサイクルに位置してい るかなどを確認する • アクティブユーザ数、ログイン数、アク セスルート、キャッシュコンバージョン レート など フロントエンド ブラウザやモバイルアプリのフロントエン ドのパフォーマンス/エラーを監視し、 ユーザ満⾜・売り上げに貢献しているか確 認する • レンダリングパフォーマンス • JavaScriptエラー など アプリケーショ ン アプリ単位でのパフォーマンスやエラーな どを測定し、期待通りの動作をしているか 確認する。障害原因の調査を実施する • クエリ実⾏時間、外部API応答時間 • デプロイパイプラインメタ情報 • ヘルスチェック など リソース (サーバ) アプリが稼働しているサーバの物理的なメ トリクスを測定し、スケーリング検討や障 害原因の調査を実施する • CPU/メモリ/ディスクなどの共通メトリ クス • WebサーバのHTTPステータスコード、 DBサーバのスロークエリなどの特有メト リクス ネットワーク ネットワークの疎通/パフォーマンスなど からアプリが期待通りの動作をしているか を確認する。障害原因の調査を実施する • インバウンド/アウトバンドのIPアドレス、 パケット、アクセス頻度、ルーティング など セキュリティ 不正アクセス/悪意的な攻撃などからユー ザ情報や企業機密などのデータを保護する ための検知/追跡の仕組みを構築する • ユーザ、コマンド、ファイルシステムの 実⾏履歴 など
  11. - 16 - - 16 - Observability (可観測性) とは︖ n

    CNCF (Cloud Native Computing Foundation) TAG (Technical Advisory Group) Observability whitepaperより <What> 可観測性とは 外部出⼒の情報から システムの内部状態 を どれだけうまく推測できる かを⽰す尺度である <Why> • システムの複雑さと毎秒処理するデータの継続的な増加に伴い、私たちはワーク ロードの状態を理解するためにより良い観測性を必要としている • 観測可能なツールに加え、サービスとしてのソフトウェアの実⾏に責任を持つすべ てのエンジニアが、アプリケーションの監視と観測の⽅法を理解していることが、 現在では⼀般的になっている • 顧客の期待が⾼まり、サービスレベルの⽬標が厳しくなる中、エンジニアはこれま で以上に迅速にデバッグし、問題の根本原因を突き⽌めなければならない 参考︓https://github.com/cncf/tag-observability/blob/main/whitepaper.md
  12. - 17 - - 17 - 参考︓サービスレベル管理 n ビジネスとシステムの安定性のバランスを採るための考え⽅ •

    必ずしも、すべてのサービスで 99.999% の可⽤性は必要とされない リスクと報酬のバランス︓企業はどれだけのダウンタイムに耐えられるか︖ • 明確な SLA を確⽴し、サービスに対して問題を測定することで、 SREは意⾒を数学の問題に変えることができます n エラー・バジェット 1 • SLI (Service Level Indicator サービスレベル指標) サービスの信頼性を計測するためのメトリック etc) 応答性能、エラー率 • SLO(Service Level Objective サービスレベル⽬標) 達成すべきゴール etc) 応答の98%が750ミリ秒未満 • SLA(Service Level Agreement) Stakeholderと合意された契約 100% 99.9% SLA (99.9% に設定 されて いる 場合) 可⽤性 システム停⽌ エラー・ バジェット SLA SLA 確保が 危うい状態 このサイク ルでは、 これ以上の リリースは なし︕ SLA SLA を⼗分に 確保できてい る 状態 変更をより 積極的に ロールアウト 可能 新機能を開拓 または l プロダクトチームと SRE が、共通の⽬標に向けて協⼒します。 イノベーションと安定性を両⽴させます。 l 開発チームが⾃らリスクを管理できます。 エラー・バジェットをどう活⽤するか⾃発的に判断できます。 l ⾮現実的な信頼性の⽬標が設定されにくくなります。 ⾮現実的な⽬標は、イノベーションを減速させます
  13. - 18 - - 18 - Observability (可観測性) とは︖ n

    CNCF (Cloud Native Computing Foundation) TAG (Technical Advisory Group) Observability whitepaperより l メトリック ü ある⼀定期間の状態を 集計可能な数値で表現したもの l トレース(分散トレーシング) ü 1つのトランザクション(要求)のインスタンスが、 ライフサイクルに渡り、複数コンポーネントでどのように処理されたか l ログ ü 個別の事象を表す、構造化された、⼈間が読める詳細な情報 üWhitepaper では さらに 2つを有益なシグナルとして紹介 – プロファイル • システム内のリソース配分の把握 CPUプロファイル、ヒープ・プロファイルetc • サンプリング・プロファイラーの普及により、本番での取得も現実的に – ダンプ • クラッシュしたプロセスのトラブル・シューティングに有益 <How> 可観測性の主要シグナルを収集して計測する 参考︓https://github.com/cncf/tag-observability/blob/main/whitepaper.md
  14. - 19 - - 19 - Observability (可観測性) を実現するOSS n

    メトリック・データの取得 • Prometheus n メトリック・データの集約(グラフィカルに把握するためのツールなど) • Grafana ü OpenShift ではOpenShift Monitoring として提供 • Thano ü マルチクラスター環境でのPrometheusメトリクスを集約 ü OpenShift Advanced Cluster Managementで提供 n トレーシング • Zipkin • Jaeger︓ ü OpenShift では、 OpenShift Distributed Tracing として Jaegerを提供 • OpenTelemetry ü またOpenTracing や OpenCensus というプロジェクトが統合 n ログ • LogStash • Fluentd ü OpenShift では、OpenShift Logging として EFK (ElasticSearch, Fluentd, Kibana)のスタックが提供 参考︓https://www.ibm.com/blogs/solutions/jp-ja/container-cocreation-center-15/
  15. - 20 - - 20 - 【再掲】従来の監視 vs Observability (可観測性)

    n マイクロサービス化など環境変化を背景に、従来の監視に対するアンチテーゼとしてObservabilityが注 ⽬されている 従来の監視 Monitoring 可観測性 Observability APM Application Performance Management • レガシー/モノシリック • オンプレ中⼼ • マイクロサービス • クラウドネイティブ 環境の変化 • 複数のシステム/基盤にわたるデー タの収集 • システム全体の振る舞いを理解し て、サービス改善に取り組む • 主要シグナルは、メトリック・ト レース・ログ • 積極的な対応 (Proactive)を⽬指す • 特定のシステム/基盤の視点 でデータの収集 • あらかじめ閾値を設定。障 害アラートを受けてインシ デント対応 • 事後的な対応 (Passive) に なりがち
  16. - 21 - - 21 - 閑話休題 n 個⼈的ちいかわ名シーン 参考︓ちいかわ

    https://twitter.com/purinchankawaii/status/1533295097022148608
  17. - 22 - - 22 - アジェンダ 1 ͸͡Ίʹ 2

    Observabilityͷઆ໌ 3 APMͷઆ໌ɾσϞ 4 ͓ΘΓʹ
  18. - 23 - - 23 - 概念イメージ︓APM n 今回はObservabilityを実現するための要素/⼿段の⼀つとして、広義の意味でのAPMを紹介する 従来の監視

    Monitoring 可観測性 Observability APM Application Performance Management <狭義> • アプリケーションレベルに閉じてパフォーマンスを 計測・管理する。特にゴールデンシグナルの計測 (レスポンスタイム、スループット、エラー率) <広義> • アプリケーションからインフラまでを監視/追跡し、 システム全体のパフォーマンス問題の特定や解決を ⽀援する。ゴールデンシグナルの計測だけでなく、 トレーシング/サービスマップ/エンドユーザーモニ タリング/ビジュアルダッシュボードなども含む • 今回はObservabilityを実現するための要素/⼿段の⼀ つとして、広義の意味でのAPMをご紹介 • APM以外のObservabilityを実現するための要素例 ü NPM (Network Performance Management) ü Continuous Optimization ü AIOps など
  19. - 25 - - 25 - APMとは(広義の意味で) n アプリケーションからインフラまでを監視/追跡し、パフォーマンス問題の特定や解決を⽀援する n

    サービス影響の未然防⽌と迅速な問題解決を通じて安定稼働を実現し、UX/⽣産性の向上に寄与する アプリケーションから インフラストラクチャ までの性能/応答時間 の監視と追跡 性能基準 SLAの策定と 性能問題時のシステム 管理者へのアラート 洞察を得るための 視覚化された 統計情報の提供 アプリケーション性能 問題の解消⽀援 Application Performance Management 監視と追跡 基準策定と検知 通知 情報の可視化 根本原因特定 プラットフォーム リソース ユーザー体験 パフォーマンス性能 アプリケーション クラウド サービス コード最適化 < / > ランタイム .Net ミドルウェア 安定稼働の実現 サービス影響の未然防⽌ 障害の迅速な解決 顧客体験価値 + ⽣産性の向上
  20. - 27 - - 27 - IBM Observability by Instana

    n 次世代 アプリケーション・パフォーマンス・モニタリング 従来型 監視基盤 ü 個別導⼊とセットアップ - 監視対象に応じて導⼊ - 監視対象の設計と設定が必要 ü 得られる情報が少ない - OSレベルの情報のみ - 5秒-30秒の平均値の値 - アプリケーションの挙動が掴めず 改善につなげられない ü オンプレミスとクラウド 別管理基盤 - ユーザーの体験を理解できない - ツールとして情報を追えない 次世代 可観測性 基盤 ü ゼロ構成と⾃動監視、環境変化にも⾃動追随 - 監視対象を検知し⾃動構成 - 監視対象に対する専⾨知識を反映済み ü ⾼精細データでシステムを可視化 - 全要求トレース+1秒単位メトリック - 基盤からアプリまで多様に渡り可視化 - AIと機械学習で 問題を⾃動検知 - 関連コンポーネントの情報も整理して提⽰ ü オンプレミスとクラウドも統合して監視 - WebUIから基幹システムの呼出しまで - 挙動を理解しユーザー体験改善につなげる 多様な観点での解析 AI/MLによるアクション コンテキストの可視化
  21. - 28 - - 28 - 監視構成の⾃動化 n 動的環境に⾃動的に対応、環境の完全な観測性を得ることができます •

    1ホストに1つのエージェント が コンポーネントの監視に必要なセンサーを⾃動構成 • 環境の変化にも⾃動追随し、監視を継続します • すべての要求をトレース、1秒単位のメトリクス、すべての構成変更を記録 アプリケーションのすべてのリクエスト を完全に可視化 サンプリング、部分的なトレースではあ りません。 スパイクを⾒逃すことがないように、 すべてのメトリックは、毎秒収集されます。 ü 環境にあわせて 事前に導⼊・構成が必要 ü 監視対象の再起動が必要 ü 基盤だけのモニタリング・ データ ü サンプリング・データ 28 ︕ 従来型モニタリングの課題 28
  22. - 29 - - 29 - コンテキストの提供 n サービスの依存関係を リアルタイムで提⽰します

    • 取得した要求トレースの解析により、各コンポーネントが 他のすべてのコンポーネントやサービスに、どう依存しているかをリアルタイムで可視化します • すべてのサービスの品質に関する即時のコンテキスト情報により 顧客に影響を与える前にパフォーマンスを最適化することができます Instana は収集したデータを 継続的に依存関係モデルに編成します。 コンポーネント、サービス、リクエストを論理的にグループ化し、 気になるサービスを簡単に可視化します。 29 ü サービスの依存関係が 把握できない ü ハイブリッド・クラウドの 挙動を追えない ü 問題が与える可能性のある 影響範囲がわからない 従来型モニタリングの課題 ︕ 29
  23. - 30 - - 30 - AI/MLによるインテリジェントなアクション n 問題の要因を理解して、迅速に問題を解決に導きます •

    各テクノロジーの センサーには 各テクノロジーの専⾨知識に基づいて あらかじめ デフォルトの 監視設定が構成されている • ランタイムにおける警告/エラーのログは⾃動的に記録されます • 要求数、エラー数、応答性能などのゴールデン・シグナルに対し 機械学習を適⽤、通常と違う振る舞いを検知し通知します 根本原因に関連するすべてのイベントを 含む単⼀のアクション可能なアラート 30 ü 固定的なしきい値監視だけ では拾えない ü ⼤量のイベント通知 ü メトリック値だけでは なにが起きているか わからない ︕ 従来型モニタリングの課題 30
  24. - 31 - - 31 - Instanaのデモンストレーション n 「Play with

    Instanaʼs APM Observability sandbox」の環境を利⽤ • https://www.instana.com/getting-started-with-apm/ • Instanaの操作性を体験するためのサンドボックス環境 • 「Robot Shop」というマイクロサービスをモニタリングしている ü デモ⽤に定期的に障害が起きているようになっているECサイト ü GKEやECSなどで構築されている
  25. - 32 - - 32 - アジェンダ 1 ͸͡Ίʹ 2

    Observabilityͷઆ໌ 3 APMͷઆ໌ɾInstanaͷσϞ 4 ͓ΘΓʹ
  26. - 33 - - 33 - まとめ n ちいかわでも分かる「Observability」「APM」のまとめ︕ 従来の監視

    Monitoring 可観測性 Observability APM Application Performance Management • レガシー/モノシリック • オンプレ中⼼ • マイクロサービス • クラウドネイティブ 環境の変化 • 複数のシステム/基盤にわたるデー タの収集 • システム全体の振る舞いを理解し て、サービス改善に取り組む • 主要シグナルは、メトリック・ト レース・ログ • 積極的な対応 (Proactive)を⽬指す • 特定のシステム/基盤の視点 でデータの収集 • あらかじめ閾値を設定。障 害アラートを受けてインシ デント対応 • 事後的な対応 (Passive) に なりがち • 今回はObservabilityを実現するための要 素/⼿段の⼀つとして、広義の意味で紹介 • ゴールデンシグナルは、レスポンスタイ ム、スループット、エラー率 • トレーシング/サービスマップ/エンド ユーザーモニタリング/ビジュアルダッ シュボードなども • 代表例として、Instanaのデモンスト レーションを実施 参考︓ちいかわ
  27. - 34 - - 34 - みなさんへのお願い n 2023年の流⾏語にしようぜ︕ 「Observability」「APM」を周りに広めてください︕

    あと良ければInstanaも触ってみてください︕https://www.instana.com/getting-started-with-apm/ Observability 参考︓ちいかわ