Slide 1

Slide 1 text

- 1 - - 1 - Observability & APM ⼊⾨ 〜2023年のIT運⽤/監視の流⾏語はこれだ︕ - Instanaのデモンストレーションを添えてご紹介 2023/01/12 Takahiro Esaki 1

Slide 2

Slide 2 text

- 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/

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

- 5 - - 5 - はじめに みなさん、 2022年どうでした︖

Slide 6

Slide 6 text

- 6 - - 6 - 2022年を流⾏語で振り返ってみよう(ユーキャン ver) 図表参考︓https://www.nikkansports.com/general/nikkan/news/202212010000406.html ユーキャン 新語・流⾏語⼤賞︓https://www.jiyu.co.jp/singo/index.php

Slide 7

Slide 7 text

- 7 - - 7 - 2022年を流⾏語で振り返ってみよう(SNS ver) 参考︓https://webtan.impress.co.jp/n/2022/12/02/43812

Slide 8

Slide 8 text

- 8 - - 8 - 個⼈的な流⾏語は・・・ Observability 今⽇は「Observability」の話をする・・・ ってコト︕︖ 参考︓ちいかわ

Slide 9

Slide 9 text

- 9 - - 9 - みなさん、こう思っていませんか︖ 参考︓ちいかわ

Slide 10

Slide 10 text

- 10 - - 10 - まあ、落ち着いてください お そ ろ し く 速 い ⾃ 然 な 導 ⼊ 参考︓HUNTER×HUNTER 本⽇は個⼈的な流⾏語の1つ「Observability」の話をします︕ (⼤事なことなので2回良いましたが、団⻑の⼿⼑を⾒逃さなかった⼈のおかげで⼤丈夫ですね︕)

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

- 12 - - 12 - 本⽇のテーマの概念イメージ 従来の監視 Monitoring 可観測性 Observability APM Application Performance Management n 従来の監視 & Observability & APM

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

- 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

Slide 17

Slide 17 text

- 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 ⾮現実的な信頼性の⽬標が設定されにくくなります。 ⾮現実的な⽬標は、イノベーションを減速させます

Slide 18

Slide 18 text

- 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

Slide 19

Slide 19 text

- 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/

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

- 21 - - 21 - 閑話休題 n 個⼈的ちいかわ名シーン 参考︓ちいかわ https://twitter.com/purinchankawaii/status/1533295097022148608

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

- 24 - - 24 - APMが重要視されている背景 n パフォーマンス低下によるユーザーへの悪影響が広く認知されている 参考︓https://prtimes.jp/main/html/rd/p/000000001.000031546.html

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

- 26 - - 26 - APMのソリューション例 n APMソリューションの代表例 今回デモでご紹介

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

- 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などで構築されている

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

- 34 - - 34 - みなさんへのお願い n 2023年の流⾏語にしようぜ︕ 「Observability」「APM」を周りに広めてください︕ あと良ければInstanaも触ってみてください︕https://www.instana.com/getting-started-with-apm/ Observability 参考︓ちいかわ