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

【投影資料】20230628_IBM Tech/Developer Dojo_Instanaを使い倒す#1

【投影資料】20230628_IBM Tech/Developer Dojo_Instanaを使い倒す#1

セッションの投影資料です。

<開催日>
開催日:2023/06/28(水) 14:00-15:00@WebEX

<セッション概要>
シリーズ「IBMのObservability/APM製品(Instana)を使い倒す #1」の第一回目の開催となります。
今回は、初回セッションということで、Observability・APMの概念、なぜそれらが必要なのか、どのように活用するのか等をお伝えします。
また、IBMのObservability・APM製品である「Instana」のデモを交えながら、実用的な活用方法も学んで頂きます。

Instanaユーザ会(ユーザコミュニティ)も発足し、ますます盛り上がりを見せるInstana。

みんなで楽しく、Instanaを学んでいきましょう!

Airi Furukawa

June 30, 2023
Tweet

More Decks by Airi Furukawa

Other Decks in Technology

Transcript

  1. ©2022 IBM Corporation IBM Automation アジェンダ nAPM/Observabilityとは︖(10分) 14:05-14:15 nなぜAPM/Observabilityが必要なのか︖(10分) 14:15-14:25

    nAPM/Observability をどのように活⽤するか(10分)14:25-14:35 nInstanaで実現するAPM/Observability + デモ(20分)14:35-14:55 nQ&Aタイム/アンケート回答(5分) 14:55-15:00 ご質問は チャット欄 にどうぞ︕
  2. ©2022 IBM Corporation IBM Automation 本⽇のゴール n「APM/Observabilityとは︖」を理解する。 n APM/Observability がなぜ必要なのかを理解する。

    n APM/Observability をどう活⽤できるのかを理解する。 n Instana の概要を理解する。 n Instanaでシステムの障害原因/性能ボトルネックを特定する⽅法を学ぶ。
  3. ©2022 IBM Corporation IBM Automation APM/Observability とは︖ -私たちを取り巻く環境- 運⽤管理の変化 テクノロジーの複雑化

    デプロイ頻度の増加 • アジャイル開発 • CI/CD • DevOps • SRE(Site Reliability Engineering) • マルチクラウド • ハイブリッドクラウド • マイクロサービス • コンテナ • サーバーレス
  4. ©2022 IBM Corporation IBM Automation APM/Observability とは︖ -Observabilityとは︖- n Observe(観察)+

    Ability(能⼒) から成る造語。 –システムのどこで、いつ、何が起きているか、なぜそれが起きたかを観測可能にすること。 Observability(オブザーバビリティ︓可観測性) n 主要な3つのデータ(=シグナル)︓ メトリクス、トレース、ログ。 n データに関連性/コンテキストを持たせる。 →「どこで」「何が」起きているかだけでなく、 「なぜ」不具合が発⽣したか を理解する。 ※シグナルをテレメトリーデータと呼ぶこともある。
  5. ©2022 IBM Corporation IBM Automation APM/Observability とは︖-APMとObservability の違い- どちらもソフトウェアのパフォーマンスを理解し改善するためもの。 nAPM︓ダッシュボードやアラートを使って既知の障害や予想される

    障害を⾒える化、トラッキング。 –Observabilityを実践するためのステップの1つ。 n Observability ︓アプリからインフラまで複数のレイヤーにわたって データを⾒える化/トラッキングしたのち、更にそれを分析し、問題 の根本原因を追及する。
  6. ©2022 IBM Corporation IBM Automation APM/Observability とは︖ -従来のモニタリングとの違い1- • サーバやネットワーク、データベースなど個々の健全性は確認可能。

    • しかし、アプリケーションはそれらの全てに跨って構成される。 → インフラの個々の状態からは想定できない様々な事象が発⽣しうる。 モニタリング APM Observability インフラ観点で⾒える化 ユーザ視点でアプリも⾒える化 システム全体の繋がり・「なぜ︖」を理解 • UXの低下など、今まで気づくことができなかった事象も⾒える化。 • データ間の関連性を持たせることで、コンテキストを理解。 • 「異常に気づいてから対応→異常が起きる前に対応」へシフト。
  7. ©2022 IBM Corporation IBM Automation APM/Observability とは︖ -監視項⽬の違い- インフラの監視がメイン §死活監視

    §リソース監視 §CPU使⽤率 §メモリ使⽤率 §ディスク使⽤率 §ログ監視 §プロセス監視 モニタリング APM/Observability インフラレイヤのみならず、フロントエンド/アプリ も可視化。 § Webサイトのページロード時間(レスポンスタイム) § API呼び出しのエラー率 § Healthエンドポイントチェック(HTTPステータス コードの確認) § API呼び出しにかかった時間 § クエリ実⾏時間. etc… ※サーバ監視を例に記載
  8. ©2022 IBM Corporation IBM Automation なぜAPM/Observabilityが必要なのか︖ Visibilityの 向上 デバッグの 強化

    ユーザ体験 (UX)の 向上 アップ グレード アラート SLO/SLI監視。 ビジネス⽬標 達成に寄与。 APM/Observability で得られる効果︓ユーザ/開発・運⽤者体験の改善・向上。
  9. ©2022 IBM Corporation IBM Automation APM/Observability をどのように活⽤するか︖#1-1 APM/Observabilityの世界では、SLO/SLIベースの監視を実現。 nSLO: Service

    Level Objective →⽬標 –サービスレベルの⽬標値。 –顧客に公開される「外部SLO」と公開されない「内部SLO」がある。 –1週間/1か⽉単位など、ある程度の期間をベースに設定。 nSLI︓Service Level Indicator →指標 –SLOを達成できているかを図る指標。SLOの部分要素。 –1分単位、1時間単位など短期間をベースに設定。
  10. ©2022 IBM Corporation IBM Automation APM/Observability をどのように活⽤するか︖#1-2 APM/Observabilityの世界では、SLO/SLIベースの監視を実現。 出典:https://www.ibm.com/support/customer/csol/terms/?id=i126-9268&lc=en#detail-document nSLA︓Service

    Level Agreement →契約/合意 –サービス提供者/顧客間でSLA(サービスの可⽤性)を合意。 –サービス提供者がSLAを守れなかったら、顧客に対して返⾦などを⾏う。
  11. ©2022 IBM Corporation IBM Automation APM/Observability をどのように活⽤するか︖#1-3 SLO/SLIベースの監視を実現。 SLA(契約/合意)︓ 「このSLO(外部SLO)を守ります。守れなかったらペナルティを負います。」

    という契約/合意。 SLO(⽬標)︓ 1週間のうち、99%の割合でWebアプリケーションのレスポンスタイム 2秒以内を達成する。 SLI(⽬標達成の指標)︓ 1⽇のうち、99%の割合でレスポンスタイム2秒以内を達成する。
  12. ©2022 IBM Corporation IBM Automation APM/Observability をどのように活⽤するか︖#1-4 SLO/SLIベースの監視を実現。 SLA(合意)︓ 「このSLO(外部SLO)を守ります。守れなかったらペナルティを負います。」

    という契約/合意。 SLO(⽬標)︓ 1週間のうち、99%の割合でWebアプリケーションの レスポンスタイム2秒以内を達成する。 SLI(⽬標達成の指標)︓ 1⽇のうち、99%の割合でレスポンスタイム2秒以内を達成する。 APM/Observability 製品の出番︕
  13. ©2022 IBM Corporation IBM Automation APM/Observability をどのように活⽤するか︖#1-5 SLO/SLIはビジネスKPIを実現するための⼿段。 ビジネス⽬標達成のためにもAPM/Observabilityが必要。 ビジネスKPI︓

    アクティブユーザ数/⽉、そのサイトから⽣まれる売上 等。 SLA(合意) SLO(⽬標)︓ 1週間のうち、99%の割合でWebアプリケーションの レスポンスタイム2秒以内を達成する。 SLI(⽬標達成の指標)︓ 1⽇のうち、99%の割合でレスポンスタイム2秒以内を達成する。
  14. ©2022 IBM Corporation IBM Automation APM/Observability をどのように活⽤するか︖#2 いつ、だれが、どんなシチュエーションで利⽤するか︖ 開発 アプリ開発時(改修時)

    のデバッグ作業 性能試験、試験シナリオの作成 ビジネス サイド 運⽤ • 障害発⽣時の 原因究明 • SLO/SLI監視 試験
  15. ©2022 IBM Corporation IBM Automation Instanaをどのように活⽤するか︖ [平常時] 処理数、エラー率、応答性能などを即座に把握。 業務ごとの処理量を 容易に把握。

    呼出しの依存関係を可視化。 カスタムダッシュボードで必要な情報に 瞬時にアクセス。 応答性能の悪い処理を特定。 アプリケーション性能を改善。 メソッドレベルで遅い処理を特定・解析。 サービス状況の把握 n 平常時のサービスレベルを正確に理解 n 複雑化したサービス環境を⼀元的に可視化 n リソース状況、各種メトリックの即時把握 レポーティング負荷軽減 n ⽉次報告資料作成の負荷低減 インパクト分析 n アプリ修正やパッチ適⽤の影響確認 n 開発段階からアプリケーション品質担保
  16. ©2022 IBM Corporation IBM Automation Instanaをどのように活⽤するか︖ [障害時] 処理量や応答性能の急激な変化 を検知・通知。 解析画⾯から応答性能で要求をソート。

    インフラ観点で問題のある コンポーネントを特定。 周辺コンポーネントのイベントも 集約して通知。(チャット/メール) 依存関係マップで、 エラーのコンポーネントを 把握。 エラー・メッセージを返却している クラスまで確認可能。 MTTD/MTTRの短縮 n 問題発⽣状況、影響範囲の把握。 n 障害発⽣タイミング/件数の把握。 n 障害復旧状況の把握。 n 問題発⽣時の障害原因調査。 n 障害時のコミュニケーションを円滑に。 障害発⽣/影響拡⼤の未然防⽌ n AI/MLがサービス提供状況を学習し、逸脱した振 る舞い検知。 n リソース枯渇を事前に検知・通知。 (Javaヒープや ディスク・フルなど)
  17. ©2022 IBM Corporation IBM Automation Instanaで何ができるか︖ -機能概要 - 23 カスタマイズ可能なダッシュボード

    HTTPリクエストの数/ステータス・レスポンスタイム等の情報を提供。 アプリケーション/サービスごとに処理待ち時間などを表⽰。 Kubernetes, Cloud Foundry(Tanzu), VMware vSphere等 のプラットフォーム情報を表⽰ ホストやホストの状態、それが属するAZなど表⽰。 強⼒なフィルターベースの分析エンジンを提供 インシデント、問題、変更を⼀覧表⽰
  18. ©2022 IBM Corporation IBM Automation Websites & Mobile Apps n

    ユーザー・エクスペリエンスを理解する –リアル・ユーザーモニタリング(RUM) →モバイルApp監視 –エンド・ユーザー・モニタリング(EUM)→Webサイト監視 n モバイルApp監視 –アクティビティ数 –ビーコン数 –ユニークユーザ数 n Webサイト監視 –ページビュー数 –ページロード時間 –地理情報(どこからアクセスがあったか) 24
  19. ©2022 IBM Corporation IBM Automation Applications n 依存性マップ –コンポーネントやサービスの依存関係、データの流れを可視化。 –カーソルを合わせると

    詳細とメトリックの表⽰ –特定のメトリックによる アイコンの拡⼤表⽰ –イベントの発⽣状況の カラー表⽰ 25 カーソルを合わ せた時にポップ アップ表⽰ 特定のメトリックによ るアイコンの拡⼤表⽰ 例)Calls(アクセス)が 多い箇所を拡⼤表⽰
  20. ©2022 IBM Corporation IBM Automation Events n 根本原因の特定を加速させるイベント管理機能を提供 – センサーに事前定義された

    Health Signature および 事前定義されたアルゴリズムでイベントをトリガー 28 インシデントの引き金になったイベントを 「Triggering Event」として表示 インシデントに関連するイベントを 「Related Events」として時系列で表示 「Analyze Calls」ボタンで分析メニューへ 直接ジャンプ
  21. ©2022 IBM Corporation IBM Automation カスタムダッシュボード 29 n 個別にモニタしたい指標を登録して素早く状況を把握 –ユーザー毎に提供、複数ユーザーで共有も可能

    –サービスレベル指標(SLI)とサービスレベル⽬標(SLO)を定義し、サービスのパフォーマンスを可 視化および分析することが可能 カスタムダッシュボードの例 SLOウィジェット
  22. ©2022 IBM Corporation IBM Automation 【参考】CI/CDパイプラインフィードバックの統合 30 n アプリケーションの各リリースのエンドツーエンドの可視性を提供 リリース名と時間

    をマーキング リリースの バナー通知 時間ビューに リリースを追加 CI/CD Tools • Circle CI • Concourse • Github Actions • Harness • Jenkins • BOSH Deployments Instana Releases API
  23. ©2022 IBM Corporation IBM Automation 【参考】ログ統合 31 n 外部のログ管理ツールと連携し、スムーズなワークフローを実現 –Instanaで開いているビューの情報をもとにログをフィルタリング

    –⼀部のログ管理ツールからInstanaへのアクセスも有効化 ログ管理ツール • Coralogix • ELK • Humio • LogDNA • Splunk ホスト名、時間で フィルタされた ビューへジャンプ
  24. ©2022 IBM Corporation IBM Automation デモ環境 アーキテクチャ概要 3 Qoute of

    the Day (サンプルアプリケーション) Linux 仮想マシン Instana Backend (=監視サーバ) Instana エージェント WebSphere Liberty DB コンテナ (MariaDB) Node.js Instana センサー Web コンテナ (JS) AP コンテナ (JS) Instana センサー Instana センサー Instana センサー Instana センサー
  25. ©2022 IBM Corporation IBM Automation デモ まとめ 34 障害発⽣ Instanaで

    原因特定 アクション 検討 サンプルアプリの Rating機能が 使⽤不可。 利⽤した機能/障害原因 ◾Applicationsメニュー • HTTPステータスコード500の発⽣を確認 • GET /ratings/:IDでのレイテンシを確認。 ◾Eventsメニュー • Node.jsのヒープメモリ使⽤率上昇 (GCの頻度↑)を確認 • NodeのCPU使⽤率上昇を確認。 アクション • CPU増設 • Node.jsのチューニン グ チューニング実現⽅法 ◾Applicationsメニュー Node.jsの監視 ◾Analyzeメニュー AutoProfile機能
  26. ©2022 IBM Corporation IBM Automation まとめ モニタリング APM Observability インフラ観点で⾒える化

    ユーザ視点でアプリも⾒える化 システム全体の繋がり・「なぜ︖」を理解 開発 運⽤ アプリ開発時 (改修時)の デバッグ作業 試験 性能試験、 試験シナリオの作成 障害発⽣時の 原因究明 • APM/Observabili tyの基盤。 • 障害原因を迅速に 特定。 • 障害発⽣後の改善 活動にも役⽴つ︕ APM/Observabilityとは︖なぜ必要なのか︖ 得られる効果 • MTTD/MTTRの短縮・改善 • UX向上 APM/Observabilityをどう活⽤するか︖ Instanaとは︖どう活⽤するか︖