OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏

2. © 2020 TIS Inc. 2 発表者紹介 1/2 おがわまさと小川真人所属: TIS株式会社 IT基盤エンジニアリング企画室役割: 運用レコメンドPF サービス展開チーム興味: 低レイヤに興味があります(知識はない) アピール？：今回を機にQiitaなどで知識のアウトプットをはじめ、スキルアップをしていこうと思います。 Qiita https://qiita.com/yumidukasattin

3. © 2020 TIS Inc. 3 発表者紹介 2/2 いけだだいすけ池田大輔所属: TIS株式会社 IT基盤エンジニアリング企画室役割: 運用レコメンドPF プロダクトオーナー興味: 運用管理系の効率化技術: Zabbix,AWS,Docker,Kubernetes, JobScheduler,fluentd,Ansible,Golang 著書: 技術評論社「改訂2版 Zabbix統合監視徹底活用」 Twitter @ike_dai Qiita https://qiita.com/ike_dai

6. © 2020 TIS Inc. 6 IT運用効率化・品質向上への取組み定常業務定型業務 ⇒旗印は「標準化」非定常業務非定型業務 ⇒標準化できない･･･> だからこそ、非定常・非定型最終ゴールは、AIによる自律・自動型のIT運用【保守・運用の効率化・品質向上の限界】【”運用レコメンドプラットフォーム”の目指す世界】障害の発生予防（予兆検知）障害の早期回復（ダウンタイムの短縮）最終ゴールは、「自律型自動運用」運用保守に関するデータの集約と共有イベントデータ (ログ、障害、構成変更、システム操作、脆弱性発覚etc.) 構成情報データ (サーバ、SW、パラメータetc.) 集約データの分析統計分析・機械学習 etc (テキスト分類、類似度分析、共起分析 etc.) 保守・運用作業の Nextアクションをレコメンド

7. © 2020 TIS Inc. 7 既存の分析ツール、可視化ツールとの違い • 既存の監視系ツール、ログ管理系ツールの置き換えというわけではなく、各運用系ツールを束ねて、運用の効率化を促進するという位置づけの製品となります。 • (メトリクス監視をしている既存の監視データを活用し、状態の異常を検知したり、構成情報やその他作業イベントの情報と関連付けて可視化したり) 運用保守に関するデータの集約と共有イベントデータ (ログ、障害、構成変更、システム操作、脆弱性発覚etc.) 構成情報データ (サーバ、SW、パラメータetc.) 集約データの分析統計分析・機械学習 etc (テキスト分類、類似度分析、共起分析 etc.) 保守・運用作業の Nextアクションをレコメンド障害の発生予防（予兆検知）と、障害の早期回復（ダウンタイムの短縮）【運用レコメンドPFのコンセプト】

9. © 2020 TIS Inc. 9 運用レコメンドプラットフォームサービス概要 2パターンの提供形態運用情報の統合表示いつもと違うを機械的に捉える SaaS型パッケージ型手軽に使える.. クローズド環境でも使える.. サーバ1 サーバ2 サーバ3 ネットワーク1 関連する監視傾向情報関連するログ情報統合的に可視化関連する作業履歴情報なんとなくおかしいな.. いつもの稼動傾向をモデル化変化を機械検知想定外の状況発生に早期に気づく従来… 運用レコメンドPFを使うと…

10. © 2020 TIS Inc. 10 ◼ 監視データ、ログデータ、設定情報、操作履歴等統合的に確認可能 Data Collector Data Analyzer データ収集基盤データ分析基盤ダッシュボード Operation Dashboard ◼ 根本的なデータ収集は既存監視ツール等と連携し、分析できる形に変換して保有することに注力 ◼ システムの状態変化の検出と検知結果と運用作業との関係性分析に注力提供予定の機能概要以下を確認可能に・システムで異常が起こっていないか・異常状態になっているのはどこか・異常箇所に関連する状態がどうなっているか以下を実現・保守運用に必要なデータを自動的に集約・構成情報を軸にし、各データを関連付けて管理以下を実現・いつもと状態が違うタイミングを早期に検知して伝える ※データ分析機能詳細は参考情報ページを参照

11. © 2020 TIS Inc. 11 分析機能仕組み 1 -監視データ変化点検知分析- ◼ 数値系監視結果データに対して、変化点の検出処理を実施する機能 ◼ ① 指定した監視アイテムのデータに対し、正常状態時の分析パターンを生成 (周期性も考慮した変動パターンの生成。デフォルトは1週間の変動周期を考慮) ◼ ② 直近の監視データを用いて、①の正常パターンと比較して変化点が発生していないかを定期分析 (実行間隔はデフォルト30分に1回) 分析評価イメージ評価のため、内部では正常状態の傾向パターンを管理突発的ではなく、状態が変化し始めた点を検出

12. © 2020 TIS Inc. 12 分析機能仕組み 2 -複数監視データ同士の相関変化分析- ◼ 複数の監視データ同士の変動の相関変化を分析する機能を提供 ◼ ① 任意の複数の監視項目のデータを用いてそれぞれの変動の相関関係の正常時パターンを算出 ◼ ② 定期的に、直近データを用いて相関関係を算出、①正常時パターンと比較し変動が大きい箇所を検知 (実行間隔は調整可能。デフォルトは30分に1回) ◼ 複数の監視項目の選択のパターン例 ◼ i. 同一のサーバの監視項目同士の相関を見るケース ◼ ii. 同一の監視項目(CPU使用率)のサーバ間の相関を見るケース分析評価イメージ正常状態時の相関係数を内部で保持相関係数の変化箇所を検出普段は出ていない相関が出始めていることの検知の例

13. © 2020 TIS Inc. 13 分析機能仕組み 3 -ログデータ出力傾向変化分析- ◼ ログに含まれるキーワードの出力傾向情報を分析し、前日の同時間帯と比較して傾向が変わってきたタイミングで検知期待する効果 - キーワードマッチベースの検出では気づけない傾向変化を早期検知できるようになる比較対象期間(前日の同時間帯データ) 2019/09/18 12:01:20 +09:00 warning Starting app server ... 2019/09/18 12:03:21 +09:00 info check test ok 2019/09/18 12:07:12 +09:00 info check test ok 2019/09/18 12:08:21 +09:00 info check test ok 2019/09/18 12:12:43 +09:00 warning Starting app server ... 2019/09/18 12:15:14 +09:00 warning lotate debug log 2019/09/18 12:16:45 +09:00 warning invalid type integer 2019/09/18 12:29:11 +09:00 info check test ok 2019/09/18 12:31:01 +09:00 warning Starting app server ... 2019/09/18 12:32:32 +09:00 info check test ok 評価対象期間(直近のデータ) 2019/09/19 12:05:23 +09:00 warning Starting app server ... 2019/09/19 12:06:22 +09:00 warning old test debug log 2019/09/19 12:07:21 +09:00 warning invalid type integer 2019/09/19 12:08:20 +09:00 warning invalid max connections parameters 2019/09/19 12:12:19 +09:00 warning Starting app server ... 2019/09/19 12:15:18 +09:00 warning lotate debug log 2019/09/19 12:16:17 +09:00 warning invalid type integer 2019/09/19 12:29:15 +09:00 warning less max connections parameters 200 2019/09/19 12:31:14 +09:00 warning Starting app server ... 2019/09/19 12:32:13 +09:00 info change debug level 3 to 4 変化度合いを分析

16. © 2020 TIS Inc. 16 運用レコメンドPF活用によるビジネス損害の極小化障害予防（発生抑制）と発生時の早期回復（ダウンタイムの短縮）により、ビジネス損害を抑制ビジネスにITを活用する（＝システムを運用する）障害対応の直接費用（IT関連・業務関連の対応人件費・外注費、機器交換・補修費、・・）機会損失顧客からの損害賠償信用力低下による中長期的なビジネス損害直接的損害ダウンタイム中の業務効率低下（当該システムの直接影響、その他関連業務への波及影響）間接的損害【影響度】 ⇒見えない損害ほど、その影響度の抑制効果が大残念ながら、（必ず、）障害は起こる

17. © 2020 TIS Inc. 17 システムの異常に”いち早く”・”的確に” 気付けるように【現行のよくある運用シーン】 1 監視の仕組みは入っていて障害には気付けるようになっているが・・・課題 • 閾値ベースの設定が中心で調整が複雑になりがち(属人的) • 閾値を厳しくしすぎると大量のアラート発生 • 閾値をゆるくしすぎると障害発生の検知が遅れる 2 おかしくなってきていないかの確認を週次や月次で目検チェックしているが・・・課題 • チェックする対象が多く時間がかかる • おかしそうかなという基準が見る人によってブレる(属人的) • チェックとチェックの間隔が長くなりがちなので検知のタイミングは遅れる

18. © 2020 TIS Inc. 18 システムの異常に”いち早く”・”的確に” 気付けるように【現行のよくある運用シーン】 1 監視の仕組みは入っていて障害には気付けるようになっているが・・・課題 • 閾値ベースの設定が中心で調整が複雑になりがち(属人的) • 閾値を厳しくしすぎると大量のアラート発生 • 閾値をゆるくしすぎると障害発生の検知が遅れる 2 おかしくなってきていないかの確認を週次や月次で目検チェックしているが・・・課題 • チェックする対象が多く時間がかかる • おかしそうかなという基準が見る人によってブレる(属人的) • チェックとチェックの間隔が長くなりがちなので検知のタイミングは遅れる運用レコメンドPF 運用システム正常時パターンいつもの稼働状態をデータとして記録直近稼働パターンデータ収集機械的に違いをチェックし続け変化の発生を検知いつもと違うおかしくなってきたタイミングを機械的に判断できる！将来的には・・・属人的になりがちな閾値ベースの監視設定を排除していける

19. © 2020 TIS Inc. 19 ”なんでだっけ？”をよりスピーディに解決できるように【現行のよくある運用シーン】 1 監視の仕組み、作業記録管理、インシデント管理の仕組みは入っているが・・・課題 • それぞれ管理しているツールが別々になっていて確認に手間がかかる • 各情報の関連付けもできておらず効果的に活動できる状態で管理できていない 2 監視の仕組みは調整されていてアラートは的確にあがってくるが・・・課題 • 監視アラートが何をきっかけにその状態になったのかを確認するのに時間がかかる • どこを確認すべきかについても属人的になりがち

20. © 2020 TIS Inc. 20 ”なんでだっけ？”をよりスピーディに解決できるように【現行のよくある運用シーン】 1 監視の仕組み、作業記録管理、インシデント管理の仕組みは入っているが・・・課題 • それぞれ管理しているツールが別々になっていて確認に手間がかかる • 各情報の関連付けもできておらず効果的に活動できる状態で管理できていない 2 監視の仕組みは調整されていてアラートは的確にあがってくるが・・・課題 • 監視アラートが何をきっかけにその状態になったのかを確認するのに時間がかかる • どこを確認すべきかについても属人的になりがち運用レコメンドPF 運用システム運用情報を時間軸に沿って統合的に管理監視データ監視アラートログデータ操作履歴設定変更履歴時間サーバの負荷上昇警告アラートサーバ内の設定パラメータ変更サーバ内の設定パラメータ変更サーバの負荷復旧アラート何か起こった時に時間に沿って実施された事象を即座に確認できる！将来的には・・・機械的に関係性を判断し作業実施前の未然予防やアラート発生時のリカバリプランの判断を機械的にできようになる

22. © 2020 TIS Inc. 22 運用レコメンドPFの状況 2020/10/30にの正式版の提供を開始しました。 AI技術を益々活用した保守運用者を補助できる仕組みを開発中です。～開発中や検討中の機能～ – 分析モデルの自動管理強化 (現状いつもの状態の期間指定が運用者による指示ベース) – 構成情報の表現のバリエーション強化 – ゆくゆくはAI技術を駆使して、 • 異常の原因となった行動の分析(原因分析) • 異常により影響を与える箇所の分析(影響分析) 今後の方針提供状況

29. © 2020 TIS Inc. 29 アーキテクチャ検討に際し意識していること極力必要なところだけを作るにとどめる今後が不透明なので、方向性が変わっても対処できるようにするエンジニアのモチベーション維持および研究開発の観点も絡んでいたので比較的新しい要素も試す既存の仕組みを使えるとこは使う - 監視ツール等は既存のものと連携機能まるごと入れ替えるとかも考慮提供する場所もどう転ぶか - クラウド提供、オンプレ提供よいものを提供するには実現できるエンジニア重要

30. © 2020 TIS Inc. 30 • 企画～PoC – 素早く手軽に • プロダクト化～展開 – セキュアに確実にフェーズによっても意識を変えて取り組みを要素企画～PoC プロダクト化～展開コンテナ管理 Docker Composeベース Kubernetesベース DB InfluxDB(時系列DB)、Neo4j(グラフ DB) TimescaleDB(PostgreSQLの時系列拡張) 認証 KONG (JWT認証プラグイン) Keycloak API仕様 REST API (Python Flaskベース) gRPC 分析管理 MLflow + Sqlite3 + localファイル MLflow + PostgreSQL + S3(S3互換Minio) コレクター Python コンテナイメージ配布方式 Golang バイナリ配布方式

31. © 2020 TIS Inc. 31 • 企画～PoC – 素早く手軽に • プロダクト化～展開 – セキュアに確実にフェーズによっても意識を変えて取り組みを要素企画～PoC プロダクト化～展開コンテナ管理 Docker Composeベース Kubernetesベース DB InfluxDB(時系列DB)、Neo4j(グラフ DB) TimescaleDB(PostgreSQLの時系列拡張) 認証 KONG (JWT認証プラグイン) Keycloak API仕様 REST API (Python Flaskベース) gRPC 分析管理 MLflow + Sqlite3 + localファイル MLflow + PostgreSQL + S3(S3互換Minio) コレクター Python コンテナイメージ配布方式 Golang バイナリ配布方式開発のしやすさを優先的に・開発言語の統一・疎結合だけどシンプルにワンセットで動く

32. © 2020 TIS Inc. 32 • 企画～PoC – 素早く手軽に • プロダクト化～展開 – セキュアに確実にフェーズによっても意識を変えて取り組みを要素企画～PoC プロダクト化～展開コンテナ管理 Docker Composeベース Kubernetesベース DB InfluxDB(時系列DB)、Neo4j(グラフ DB) TimescaleDB(PostgreSQLの時系列拡張) 認証 KONG (JWT認証プラグイン) Keycloak API仕様 REST API (Python Flaskベース) gRPC 分析管理 MLflow + Sqlite3 + localファイル MLflow + PostgreSQL + S3(S3互換Minio) コレクター Python コンテナイメージ配布方式 Golang バイナリ配布方式導入・運用を考慮・展開した後の管理・拡大するチーム体制も考慮

34. © 2020 TIS Inc. 34 コンテナベース&マイクロサービス型 Why? How? Pros? Cons? ◆ 機能変更に追随しやすいように ◆ 分析機能等処理負荷読みにくいものも柔軟に切り出して管理しやすいように ◆ 場所を問わず動かせるように ◆ Front - BFF – Backend構成に ◆ BFFは画面の表示コンポーネント毎に ◆ Backendは扱うデータの種別毎に ◆ 分析は処理種別毎に ◆ 機能変更時の影響範囲を局所化 ◆ クラウド基盤やオンプレ環境どこでも稼動可能に ◆ コンテナ数が非常に多く ◆ 実装が冗長になりがち

35. © 2020 TIS Inc. 35 gRPC API Why? How? Pros? Cons? ◆ 分析処理等リソース指向の操作を表現するRESTでは表現しにくい ◆ 分析用大量データ送受信等のため少しでも早く軽量に ◆ API仕様もしっかり管理できるように ◆ ProtocolBuffersでAPI仕様定義 ◆ gRPCによるAPI実装 ◆ Front(JS)からはgrpc-web ◆ BFF(Python)からBackendはgRPC ◆ コレクター(Go)からBackendもgRPC ◆ ProtocolBuffersでAPI定義し明確化 ◆ 開発者間やプロダクトオーナーとの会話もスムーズに ◆ 若干高速化しているかも ◆ gRPCサーバとのやり取りのデバッグがやりにくい ✓ curlとかで手軽にできない(grpcurlとか) ✓ フロントも開発者ツールとかで通信の内容確認しにくい(シリアライズ化) ◆ ProtocolBuffersからbuildするワンステップ管理が増える

36. © 2020 TIS Inc. 36 • Protocol Buffers – インターフェース定義言語 – データシリアライズするための形式 – API通信の処理を定義に沿ってシリアライズ/デシリアライズする等 • gRPC – リモートプロシージャコール – HTTP/2を利用した通信 – Protocol Buffersでデータをシリアライズし、通信することで高速なやり取りができる – 双方向通信等も対応 syntax = "proto3"; // 分析処理管理サービス service AnalyzeService { // 分析処理を実行するrpc rpc ExecAnalyze (ExecAnalyzeRequest) returns (ExecAnalyzeResponse) {} // 分析結果のリストを取得するrpc rpc GetResults (GetResultsRequest) returns (GetResultsResponse) {} } message ExecAnalyzeRequest { repeated string monitor_id = 1; // 分析対象のID(リスト) } message ExecAnalyzeResponse { bool result = 1; // 成功かどうかのフラグ string message = 2; // 結果のメッセージ } 参考) Protocol BuffersとgRPC サービス定義 rpc定義メッセージ型定義 Go Python JS .protoファイルコンパイルサーバやクライアントのコード実装・protoの仕様に沿ってシリアライズ/デシリアライズ

37. © 2020 TIS Inc. 37 Kubernetesベース基盤 Why? How? Pros? Cons? ◆ SaaS版/パッケージ版両提供 ◆ SaaS版は複数顧客を論理的に分割しつつ維持管理 ◆ SaaS版は接続元IP制限等管理強化 ◆ Kubernetes前提の稼動 ◆ Kubernetesの実行定義manifestは SaaS・パッケージ極力同一で管理 ◆ 環境毎の区分けはConfigMapで (Kustomize活用) ◆ SaaSはEKS、パッケージはmicrok8s ◆ 顧客用環境の追加削除が簡単に ◆ 同一基盤上で複数管理可能なのでリソース効率もよくなる ◆ リソース制限や通信制限等安全な構成に ◆ Kubernetesの仕組み複雑でなにかトラブルあったときの切り分けが辛い ◆ シングル構成で軽く動かしたくても k8s環境必要なのでオーバースペック

38. © 2020 TIS Inc. 38 Goベースのコレクター Why? How? Pros? Cons? ◆ 利用者環境側に導入するので極力シンプルに導入できる ◆ 稼動負荷も軽量に ◆ 各種ツールと連携するのでライブラリが豊富 ◆ Goをベースに開発 ◆ データ収集の常駐処理をGo Routine で実装 ◆ 配布物はbuild済みバイナリ+設定ファイルのみでシンプルに提供 ◆ 導入のためにPython実行環境等準備しなくてよくなりシンプルに ◆ ライブラリも不自由なく実装しやすい ◆ 動作も比較的軽量に ◆ build済み配布物の管理が必要 ◆ 少人数の開発チームで扱う言語が増える(本体側は分析の都合上Python)

39. © 2020 TIS Inc. 39 MLflowによる分析管理 Why? How? Pros? Cons? ◆ 分析モデル管理や生成物管理を極力自前実装したくない ◆ 稼動場所(SaaS/パッケージ)によらず同じように管理したい ◆ 実行時間や実行成否、実行時の分析スコア管理、生成物管理はMLflowで実施 ◆ 生成物はSaaSはS3に配置、パッケージ版はMinioを同梱し同一の仕組みで実現 ◆ 分析処理の実装に注力した開発ができている ◆ 自前で管理の仕組みなしで稼動場所の変化に対応できている ◆ 開発初期はMLflowのバグ引くことも多かった ◆ 試行回数が増えたときの検索性能が上がらないなどハマるところはちょこちょこと

40. © 2020 TIS Inc. 40 • 機械学習のライフサイクル管理を行うOSS – 分析処理環境の管理 – 分析試行の実行管理 – 分析時のパラメータ管理 – 分析実行結果の管理 – 分析による算出される生成物の管理 – これらを確認できるダッシュボード提供参考) MLflow (https://mlflow.org/) 例えば... ハイパーパラメータ切り替えて実施した結果を比較チェックしたいな実行にかかった時間や実行時のメトリクス情報を記録しておきたいな AWS上やローカル環境上など実行先を切り替えて処理させたいな分析処理のステップ毎に状況を記録し途中状態をチェックできるようにしたいな Jupyter Notebookではちょっとやりにくい管理部分が統合できる！

43. © 2020 TIS Inc. 43 • 各種優れたOSSのおかげで要件を満たす構成に • まだまだ改善が必要ではあるが、自分たちの強みになるものをOSSの組み合わせで作ることは可能性があるのではないか • オーバースペック気味でスピード感が損なわれてしまったことは否めないが・・ • 我々はOSSを活用しつつ、そのノウハウ発信し、OSSに貢献する活動も継続！ – (いずれは部分的にOSS化をしたいとは思っています・・) 試行錯誤を繰り返しながらも・・・

44. © 2020 TIS Inc. 44 • 検討中の案 ✓ AWS EKSベースのサービス提供とmicrok8s環境でのパッケージ型提供 ✓ マイクロサービスアーキテクチャ実現のためのEnvoyとKeycloak ✓ React.js + gRPCベースのWebアプリケーション実装例とハマリどころ ✓ MLflowをベースにしたデータ分析管理の仕組みなどなど今後のOSCでの講演テーマの予告今後のOSCのTIS枠の講演にもぜひご参加ください

46. THANK YOU 本資料に関するお問い合わせ TIS株式会社 IT基盤エンジニアリング企画室運用レコメンドPFサービス運営窓口 opsbear.service@ml.tis.co.jp ＜本資料の取り扱いに関して＞本資料は、著作権法及び不正競争防止法上の保護を受けております。資料の一部あるいは全部について、TIS株式会社から許諾を得ずに、複写、複製、転記、転載、改変、ノウハウの使用、営業秘密の開示等を行うことは禁じられております。本文記載の社名・製品名・ロゴは各社の商標または登録商標です。

OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏

OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏

Recommended

More Related Content

What's hot

What's hot(20)

Similar to OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏

Similar to OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏(20)

More from Daisuke Ikeda

More from Daisuke Ikeda(20)

Recently uploaded

Recently uploaded(8)

OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏