Oracle Database Technology Night #56 データベースエンジニアに向けたOracle Management Cloud 入門・活用方法

Oracle Database Technology Night #56 データベースエンジニアに向けたOracle Management Cloud 入門・活用方法　後半

Transcript

1. データベースエンジニアに向けた Oracle Management Cloud 入門・活用方法 日本オラクル株式会社 テクノロジーコンサルティング事業本部 Platform Solution本部 2022/06/23
2. 1. Oracle Management Cloud全体構成について 2. Oracle Management Cloud各機能の活用事例と知見 1. Infrastructure Monitoring編 2. Log Analytics編 3. Application Performance Monitoring編 Agenda Copyright © 2022, Oracle and/or its affiliates 2
3. 1. Oracle Management Cloud全体構成について 2. Oracle Management Cloud各機能の活用事例と知見 1. Infrastructure Monitoring編 2. Log Analytics編 3. Application Performance Monitoring編 Agenda Copyright © 2022, Oracle and/or its affiliates 3
4. • Oracle Management Cloud (OMC)では、サーバへ配布されたエージェントにより様々な情報が収集されOMCイ ンスタンスへと集約されます。 • この通信を行うためのネットワーク構成は重要な設計要素となります。 • OMCインスタンスとOCI上のエージェント間の通信経路の選択 • Internet Gateway • Nat Gateway • Service Gateway • OMCインスタンスとエージェント間の直接通信可否 • 各エージェントが直接OMCインスタンスと通信する • Gatewayを構成し、各エージェントはGateway経由でOMCインスタンスと通信する 設計要素 - ネットワーク構成 Copyright © 2022, Oracle and/or its affiliates 4
5. • Internet GatewayおよびNat Gateway 経由（①+②） • PublicにあるCloud Agentは、Internet Gateway経由、PrivateにあるCloud AgentはNAT Gateway経由 • Agentはインターネット経由(HTTPS)でOMC と通信し、監視対象の情報やログを定期的に 送信 • Service Gateway経由（③） • Cloud Agentは、Service Gatewayを経由 してOMCにプライベート接続 • OMC - Agent間の通信はリージョン内のクロー ズドなアクセス ネットワーク構成 – OCI環境との接続 Copyright © 2022, Oracle and/or its affiliates 5 OCI Region VCN Public Subnet Private Subnet Service Gateway Oracle Management Cloud Internet Gateway NAT Gateway Cloud Agent Cloud Agent ① ② ③
6. ネットワーク構成 - エージェント動作について Copyright © 2022, Oracle and/or its affiliates 6 対象サーバ 対象サーバ HTTP/HTTPS プロキシ (Optional) サーバ Gateway (Optional) OMCと直接通信が可能なサーバ OMCと直接通信が不可能なサーバ Cloud Agent Cloud Agent HTTPS 通信 HTTPS 通信 HTTPS 通信 HTTPS 通信 OMCと直接通信が可能なサーバ • エージェントからOMCサービス間のトラフィックはすべてTLS暗号化で保護されます。 • エージェントは、保護されたHTTPSサービスを利用して、インターネット経由でOMC サービスに接続します。必要なのはアウトバンドのHTTPS接続のみです。 Oracle Management Cloud
7. • 本番環境や開発環境など複数の環境を監視する場合のOMCインスタンスの構成も重要な設計要素となります。 • 単一のOMCインスタンスへの集約 • 単一のコンソールで全ての環境の情報を確認できる • 全環境への一括設定や環境間の比較などが可能で運用効率がよい • 環境毎にOMCインスタンスを分割 • 環境毎にコンソール単位で分割できる • セキュリティの観点や作業を許可するユーザが異なる場合などに有効 設計要素 - OMCインスタンス構成 Copyright © 2022, Oracle and/or its affiliates 7 Oracle Management Cloud 本番環境 開発環境 ユーザ Oracle Management Cloud 本番環境 開発環境 ユーザ Oracle Management Cloud ユーザ 集約 分割
8. • 対象システム • OCI上に移行された単一のシステム • OMCインスタンスとエージェント間の通信経路の選択 • インターネット経由のアクセスを許可しない場合が多いため、Service Gatewayを選択する場合が多いです。 • OMCインスタンスとエージェント間の直接通信可否 • Service Gatewayが選択される場合が多いこともあり、Gatewayを構成する例は少なくエージェントとの直接通 信を許可する例が多いです。 • OMCインスタンス構成 • 運用の考え方に大きく左右されるため、集約、分割どちらのパターンも選択されています。 構成パターン（Oracle Cloud Infrastructure） Copyright © 2022, Oracle and/or its affiliates 8
9. • 対象システム • 既存のオンプレミス上のシステム • OMCインスタンスとエージェント間の通信経路の選択 • オンプレミス側のプロキシ、ファイアウォールを介して、インターネット経由で通信することが多いです。 • OMCインスタンスとエージェント間の直接通信可否 • インターネット経由での通信となるためエージェントとの直接通信は許可せず、Gatewayを構成することが多いで す。 • OMCインスタンス構成 • 運用の考え方に大きく左右されるため、集約、分割どちらのパターンも選択されています。 構成パターン（オンプレミス） Copyright © 2022, Oracle and/or its affiliates 9
10. 1. Oracle Management Cloud全体構成について 2. Oracle Management Cloud各機能の活用事例と知見 1. Infrastructure Monitoring編 2. Log Analytics編 3. Application Performance Monitoring編 Agenda Copyright © 2022, Oracle and/or its affiliates 10
11. サービス概要/特徴 • システムを構成するあらゆるITコンポーネントを監視し、イン フラのステータス、リソースや、パフォーマンスなどキーメトリック を可視化します。 • オンプレミス環境とクラウドの両方を、オラクル・非オラクル問 わず統合的に監視することができます。 • Oracle Management Cloudの他のサービスと連携し一 元的なビューを提供します。 こんな課題に役立ちます • インフラ監視は行っているが、オペレーターしか見ることができ ず、トラブルシューティングの際にすぐに確認できない。 • アプリケーション性能やログ内のエラーと、インフラリソース状 況とを関連付けて調査するのが大変。 Infrastructure Monitoringについて Copyright © 2022, Oracle and/or its affiliates 11
12. • Infrastructure Monitoringによる監視では下図にまとめた選択肢の中から、監視要件に合わせて適切な方式を 選択します。 • 迅速な構築や高い運用性確保の観点から、現行の監視設定が存在するシステムにおいても安易に踏襲するのでは なく、作業コストの低い標準メトリックの採用可否をまずは検討することをお勧めします。 監視方式の選択 Copyright © 2022, Oracle and/or its affiliates 12 標準メトリック カスタム・メトリック プロセス監視 概要 • エンティティ・タイプごとに事前に定義されたメト リック • 特定のエンティティ・タイプに対してユーザが指 定したコマンドやスクリプトの結果から構成され るメトリック • エンティティとしてではなく、ホスト・エンティティに 紐づくプロセスとして監視する 対象 • 登録済みエンティティ • 登録済みエンティティ • 登録済みホスト・エンティティ • エンティティ・タイプ未定義のコンポーネントも ホストのプロセスとして対象化 柔軟性 • なし（多数のメトリックが定義されている） • つくり込みが可能なため柔軟性は最も高い • 対象は柔軟だが、プロセスに対して収集され るメトリックは固定 設定方法 • なし（事前定義済み） • OMCコンソール • OSログイン（スクリプト配置） • REST API 作業コスト • エンティティ登録をすることで使用可能になる ため、コストは低い • 内容の複雑さによって変動するが、標準メト リックと比較して作業コストは高い • OMCに対してREST APIを使用可能にす るための準備コストが高い • OS上の特定プロセスのみ指定するための フィルタ条件作成の作業コストがやや高い
13. • ホスト、データベース、APサーバなどのエンティティの可用性監視 • CPU、メモリ、ファイルシステムなどのリソース監視 • Data Guardパフォーマンス監視（※後ほど説明） 活用事例 - 標準メトリック Copyright © 2022, Oracle and/or its affiliates 13
14. 活用事例 - カスタム・メトリック Copyright © 2022, Oracle and/or its affiliates 14 • 既存監視スクリプトの活用 • 特定ディレクトリの領域監視 • 特定ファイルのサイズ監視 • 周辺機器へのping監視 ※ カスタム・メトリックの実装には、定義の作成、テスト、 公開、デプロイの一連の手順が必要となります。 ※ システム固有で重要度の高い監視要件への利用をお 勧めします。
15. • エンティティ登録出来ないコンポーネントのプロセス死活監視 • プロセス数増減の監視 • 特定のOracleバックグラウンド・プロセスの監視 ※ エンティティ定義がない対象や、重要なプロセスに限定しての利用をお勧めします。 活用事例 - プロセス監視 Copyright © 2022, Oracle and/or its affiliates 15 { "name": "<name of the process set>", "metadata": { "description": "<description>", "isDisabled": false }, "filters": [ { "filterType": "<filter type>", "filterPattern": "<regular expression>", "description": "<description>", "isDisabled": false } ] } { "meId" : "<meid of the process set>", "name": "<name of the process set>", "mappings": [ { "meId": "<meid of the host target>" } ] } 対象プロセスをフィルタリングして指定 ホスト・エンティティへ紐付け ホスト・エンティティの構成画面から確認可能 REST APIで設定 REST APIで設定
16. • OMCではOracle Databaseをエンティティ登録することで様々なメトリックを収 集可能ですが、Data Guardについても様々なメトリックが用意されているため 簡単に監視が可能になっています。 • Oracle Databaseエンティティの画面から、Data Guardのロールなどの構成情 報の確認や、転送/適用ラグなど必要なパフォーマンス・メトリックを選択して表 示することが可能です。 Oracle Database関連情報 - Data Guardの監視 Copyright © 2022, Oracle and/or its affiliates 16 ▼Data Guardの構成情報画面 ▼パフォーマンス・チャートの選択画面
17. • Enterprise Manager Cloud Control (EMCC) へData Collectorエージェントを導入することで、登 録されているターゲットの構成やパフォーマンス・メトリッ クなどをOracle Enterprise Manager Cloud Control Management Repository (OMR)から 収集しOMCへ連携可能。 • 運用において既にEMCCを活用している場合などに有 効です。 • OMCとEMCCの併用では、OMCで情報を一元管理 した上で、 EMCCでOracle Databaseの運用や深 掘分析を実施するといった使い分けをおこないます。 Oracle Database関連情報 - Enterprise Managerとの連携 Copyright © 2022, Oracle and/or its affiliates 17 OCI Region VCN Subnet Subnet EMCC Service Gateway Database Exadata Data Collector OMA OMA Oracle Management Cloud
18. 1. Oracle Management Cloud全体構成について 2. Oracle Management Cloud各機能の活用事例と知見 1. Infrastructure Monitoring編 2. Log Analytics編 3. Application Performance Monitoring編 Agenda Copyright © 2022, Oracle and/or its affiliates 18
19. サービス概要/特徴 • あらゆるログを取り込みビジュアライズ化することで迅速な障 害対応や、新たな知見の抽出を支援します。 • テキストベースで整形に手間がかかるログを、横断的に、か つ高速に可視化・柔軟に検索＆絞り込みできるほか、機械 学習を活用した異常値の発見、相関分析などを可能にし ます。 こんな課題に役立ちます • 障害対応ですぐログがほしいのに取得と整形に時間がかか る。 • 正常処理のログが大量にあり、異常値を見つけるのが大変。 • ログはトラブルが起きて初めて見ている。もっとプロアクティブに 分析したい。 Log Analyticsについて Copyright © 2022, Oracle and/or its affiliates 19
20. ログ監視の動作イメージ Copyright © 2022, Oracle and/or its affiliates 20 ログ・ソースA ログ・ソースB ログ・ファイルA ログ・ソースA ログ・パーサー ログの分析項目定義 ログファイルパス その他設定 マスキング等 ログ・ファイルB ログ・ソースB ログ・パーサー ログの分析項目定義 ログファイルパス その他設定 マスキング等 ログ情報の可視化、分析、監視 ログ分析設定 監視対象ログ
21. ログ監視の動作イメージ – ログ・ソースとログ・パーサー Copyright © 2022, Oracle and/or its affiliates 21 ログ・ソース：ログ分析の設定セット ログ・パーサー：ログの分析項目定義 ログの分析項目をフィールドとして定義し、 解析式に関連付け ログファイルパス その他設定 ・マスキング ・拡張フィールド ・ラベル 等 例）パーサーの作成 フィールドの抽出 フィールド1 フィールド2 フィールド3 ※ フィールド定義では、単純なアラート通知や高度な分析などログの用途に合わせて 適切な粒度での設定が重要となります。
22. • Log Analyticsにおける、アラート・ルールでは下記のルール・タイプから監視要件に合致するものを選択して設定する 必要があります。 • 選択するルール・タイプによりアラート発報条件の挙動がことなるため注意が必要です。 アラート・ルールの選択 Copyright © 2022, Oracle and/or its affiliates 22 リアルタイム スケジュール済 概要 • 収集されたログ・レコードに指定したラベルと合致する内容が存在し た場合にアラート発報するルール • 特定の時間間隔ごとに指定した条件に合致するかを判定し合致し た場合にアラート発報するルール 判定間隔 • リアルタイム • 同一ラベルに合致するログが00秒から1分間の範囲で複数出力 された場合は1つのアラートとなる • 15分から7日間の任意の値を選択 • 選択した間隔ごとにアラート発報条件を判定 アラート発報条件 • 指定したラベルと合致するログ・レコードが検出された場合 • 指定した警告/クリティカルしきい値を超え重大度が変更された場 合 • 同一の重大度の場合、連続発報されることはない 柔軟性 • 複雑な条件は指定できない • ログ・データからグラフを作成し、グラフをもとにした条件を作ることが できるため、リアルタイムと比較して複雑な条件を指定可能
23. • Linux syslog • Windows Event Log • Oracleアラート・ログ • 周辺機器へのping実行ログ ※ 定義済みのログ・ソースを活用するこ とで効率的にログ収集が可能です。 活用事例 Copyright © 2022, Oracle and/or its affiliates 23
24. • 4ノードRAC構成のOracle Databaseにおける1ノード障害時のキャパシティ管理のため、AWRをログとしてOMCに 収集し、1ノード障害時に予測されるCPU時間をグラフ化したケースを紹介します。 • AWRを中間サーバ上でjson形式に変換し、カスタム・ログ・ソースを作成してOMC収集。 • ログ内のリソース使用量を1ノード障害時のサービス配置先ノードが同じサービスでフィルタし、集計してグラフ化。 Oracle Database関連情報 - 高度なAWR分析への活用例 Copyright © 2022, Oracle and/or its affiliates 24 AWR AWR AWR (HTML) ログ・ソース AWR (json) Oracle Management Cloud AWR (HTML)
25. 1. Oracle Management Cloud全体構成について 2. Oracle Management Cloud各機能の活用事例と知見 1. Infrastructure Monitoring編 2. Log Analytics編 3. Application Performance Monitoring編 Agenda Copyright © 2022, Oracle and/or its affiliates 25
26. Webアプリケーションに関する性能監視と管理のためのOMCサービス ユーザー体験とアプリケーション・パフォーマンスをエンド・ツー・エンドで「見える化」 APM導入によるメリット 1. 情報の可視化による容易な現状把握 APサーバーが複数台あるような複雑なシステムでも、 OMCコンソール上から一元管理可能 2. 迅速な原因究明 問題発生時に、ビジュアル形式で 原因箇所の掘り下げをしていくことができる Application Performance Monitoring(APM)とは Copyright © 2022, Oracle and/or its affiliates 26 対象ページは？ どの処理？ どのサーバー？ どのサーバー リクエスト？ 定常時の運用シーン 異常時の運用シーン [APMホーム]画面 OMCコンソールからドリルダウン
27. 特殊法人のお客様 APM導入事例 Copyright © 2022, Oracle and/or its affiliates 27 1. レイヤーごとに担当チームが分かれており、 チームを横断した関連ログの収集、整形に工数がかかり リアルタイムに分析することが難しい 2. アプリケーション性能障害発生時の分析にはシステムに関する 専門的なスキルが必要になるため、障害発生時の初動が遅くなり、 問題点の特定に時間がかかる お客様データセンター(オンプレミス) Tomcat AP Server 1 APM Agent Cloud Agent Tomcat AP Server 4 APM Agent Cloud Agent Tomcat AP Server 2 APM Agent Cloud Agent Tomcat AP Server 3 APM Agent Cloud Agent DB Server ユーザー 課題 導入効果 1. 集計作業の効率化 主要ページのアクセス数などのパフォーマンス情報を収集 月次報告資料に活用 2. パフォーマンス低下時のボトルネックの特定 過去にあった大規模障害では原因特定までに1-2週間を 要していたが、APM導入により10分程度で原因特定できるように ブラウザからOMC画面にアクセス
28. 集計作業および分析の効率化 ⚫ 属人的なスキルがなくても迅速な情報収集と 分析が可能 ⚫ [APMホーム]から必要な情報をいち早く収集 ⚫ データ・エクスプローラの使用により、 「APサーバーごとにCPU/メモリの使用率の推移」 などのダッシュボードのカスタマイズも可能 HPシステムの月次報告資料として活用 情報の可視化による容易な現状把握 Copyright © 2022, Oracle and/or its affiliates 28 月次報告資料の例 定常時の運用シーン 留意事項 APMの情報保持期間が 7日間のため、月次単位での資料作成 および分析にはIT Analyticsが使用できる Enterprise Editionのライセンスが必要
29. Webアプリケーション定義 特定の条件に一致するアプリケーション内の一連のページを取得するためのフィルタ定義 定常時の運用でのAPM活用(1/3) Copyright © 2022, Oracle and/or its affiliates 29 定常時の運用シーン ご要望 特定のURLページに対して定義を作成 (「次を含む」「次と等しい」などの条件指定) 要件に応じてWebアプリケーション定義を 設定することで、ダッシュボードのカスタマイズが 可能 Webアプリケーション定義の作成 1. HPシステム全体でのアクセス数を 把握したい 2. 別ページにリダイレクトしないが、 クリックすると遷移する個別のページごとに アクセス数を比較できるようにしたい 3. スマホ用サイトとPC用のサイトで アクセス数やページのロード時間を 比較したい
30. Webアプリケーション定義 実際のダッシュボード例 定常時の運用でのAPM活用(2/3) Copyright © 2022, Oracle and/or its affiliates 30 定常時の運用シーン 個別ページごとのアクセス数推移のダッシュボード 個別ページごとに カラー別で アクセス数を表示
31. プライバシ設定 プライバシ設定を有効化することで、APMによる個人識別可能情報の保存を停止できる 定常時の運用でのAPM活用(3/3) Copyright © 2022, Oracle and/or its affiliates 31 定常時の運用シーン 選択項目 IPアドレス: 保持 位置情報: 保持 IPアドレス: 破棄 位置情報: 保持 IPアドレス: 破棄 位置情報: 破棄 用途 接続IPアドレスの把握 エリアごとの利用傾向分析 個人特定につながらない範囲で の利用傾向分析 GDPRに準拠するなど、 プライバシー関連の法令に 遵守した運用監視 位置情報を破棄した際の影響 「合計ビュー」などのカラーリングが反映されなくなる IPアドレスを破棄した際の影響 セッションの「クライアントIP」の情報がマスキング表示される
32. 障害対応期間の短縮に大きく貢献 迅速な原因究明 Copyright © 2022, Oracle and/or its affiliates 32 運用チーム インフラチーム アプリチーム 関連リソースの情報提供依頼 情報収集/提供 情報整理 問題箇所の絞り込み 詳細調査 情報収集/提供 詳細調査 状 況 説 明 状 況 説 明 障害発生 Before 運用チーム インフラチーム アプリチーム 状況共有・報告 情報整理 問題箇所の絞り込み 詳細調査 After 別チームへの 状況説明による タイムラグが発生 障害発生 解決 解決 原因特定 原因特定 ポイント 1. OMCダッシュボード利用による 情報共有の迅速化 2. 関連情報の収集・整理や 問題切り分けの時間を 大幅に短縮 3. 手動作業による スキルの属人化の排除 どのチームも 共通のダッシュボード から状況を確認 サーバー・リクエスト/ アプリケーション定義設定などの 分析区分の設定 異常時の運用シーン
33. 問題発生時に迅速な原因切り分けを実現 ⚫ レスポンス時間が異常に長い、 エラーが発生しているなどの 問題解決の手がかり ⚫ 個々のサーバーの端末に入って 関連ログ収集する等の作業は不要 ⚫ サーバー構成は特に気にする必要はなく、 コンソール上の画面クリックで ドリルダウンできる 異常時の運用でのAPM活用(1/3) Copyright © 2022, Oracle and/or its affiliates 33 ドリルダウンの流れ ⚫ 最大レスポンス時間 ⚫ エラー数 ⚫ 合計ビュー数 ⚫ 最大レスポンス時間 ⚫ エラー数 ⚫ 合計コール数 ⚫ AP/DBサーバーの 階層使用量 ⚫ コール元/コール先 対象ページは？ どのサーバーに 対する リクエスト？ どこで負荷が かかっている？ ⚫ 画面コントローラ (APサーバー処理) ⚫ 実行したSQL (DBサーバー処理) どの処理？ 異常時の運用シーン
34. アプリケーション定義 フィルタ定義を保存して、条件と一致するアプリケーション内のページやサーバー・リクエストをひとまとめに表示 異常時の運用でのAPM活用(2/3) Copyright © 2022, Oracle and/or its affiliates 34 異常時の運用シーン 1. APサーバーごとにサーバー・リクエスト数を 同じ画面上で比較したい 2. 時間あたりのページ・ビュー数を APサーバーごとに比較することで、 一部のサーバーに処理の偏りがあるか どうかを確認したい ご要望 [アプリケーション]から事前定義を基に、 APサーバー/サーバー・リクエスト/ページ単位で Webパフォーマンスを確認 横ぐしを通す形でのオブジェクト監視 アプリケーション定義の設定
35. アプリケーション定義 アプリケーション画面の例 異常時の運用でのAPM活用(3/3) Copyright © 2022, Oracle and/or its affiliates 35 異常時の運用シーン APサーバーごとに設定したアプリケーション一覧 表示期間を選択し、APサーバーごとの時間あたりの ページ・ビュー数やサーバー・リクエスト数を比較することで 処理の偏りを確認