Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Jtf2018 自律的運用に向けた第一歩

2,689 views

Published on

July Tech Festa 2018での発表資料です。自律的運用に向けて、運用現場にあふれるデータをどのような形で管理しなければならないかといった視点で紹介しています。#JTF2018

Published in: Technology
  • Login to see the comments

Jtf2018 自律的運用に向けた第一歩

  1. 1. 自律的運用に向けた第一歩    〜運用現場にあふれる情報をデータ化し 機械的に学習できる状態に〜 TIS株式会社 インダストリー事業統括本部 IT基盤技術本部 IT基盤エンジニアリング第 1部 池田 大輔 July Tech Festa 2018 [29 July 2018]
  2. 2. 自己紹介 TIS株式会社 IT基盤エンジニアリング第 1部 所属  い け だ       だ い す け      池田 大輔 R&D部門での活動(社内システム運用とかやりつつ)を経て OSSサポートビジネスのサポートエンジニア・プリセールス・マーケティングを実施。 現在は、システム運用改善を支援するためのサービス企画開発中 その他、Zabbixの書籍執筆等実施。 2@ike_dai ikedai ike-dai ike_dai
  3. 3. ITシステムの保守運用に 「人」は必要ですか? 3
  4. 4. 保守運用作業 定型 Standard 非定型 Non-standard 定期 Regularly 不定期 Irregularly 定期実行バッチジョブ 監視検知による自動復旧処理 監視検知後、 状況確認し作業手順実行 セキュリティチェック&対策 月次バージョンアップ対応 障害調査&対応 障害予防対策 4
  5. 5. 保守運用作業 定型 Standard 非定型 Non-standard 定期 Regularly 不定期 Irregularly 定期実行バッチジョブ 監視検知による自動復旧処理 監視検知後、 状況確認し作業手順実行 セキュリティチェック&対策 月次バージョンアップ対応 障害調査&対応 障害予防対策 運用管理系ツールの高機能化 PaaS/SaaSによる吸収 5
  6. 6. 保守運用作業 定型 Standard 非定型 Non-standard 定期 Regularly 不定期 Irregularly 定期実行バッチジョブ 監視検知による自動復旧処理 監視検知後、 状況確認し作業手順実行 セキュリティチェック&対策 月次バージョンアップ対応 障害調査&対応 障害予防対策 課題はここ 6
  7. 7. 自分がor自分たちのチームが 未知のことへの対処が必要な現場 では人をなくすことはできない 7
  8. 8. 自分がor自分たちのチームが 未知のことへの対処が必要な現場 では人をなくすことはできない 8
  9. 9. 1. 運用現場の定性的感覚を定量的に 2. より多くの運用現場の情報を共有 This is OpsBear big concept! 9
  10. 10. Case1 : Nginx error log 10 2018/07/20 14:20:00 ...(24: Too many open files) while accepting new connection... $ ulimit -n 1024 $ cat /proc/sys/fs/file-max 816063 $ vi /etc/systemd/system/nginx.service.d/limits.conf [Service] LimitNOFILE=10000 $ systemctl daemon-reload $ systemctl restart nginx.service このような対応を行う可能性が xx%
  11. 11. Case2 : Zabbix Tuning 11 $ vi /etc/zabbix/zabbix_server.conf StartPollers=20 Zabbix Pollerのbusy率が上昇 Zabbixの監視項目数が上昇 Zabbix Server全体の CPU使用率には余裕あり このような対応を行う可能性が xx%
  12. 12. 定性的から定量的に From Qualitative to Quantitative 12
  13. 13. 13 運用現場にあふれる情報 ・監視データ ・バッチジョブの処理結果情報 ・種々なログ情報 ・システム構成情報 ・チケット情報 ・利用者からの問い合わせ情報 ・インターネット上の公開情報 ・ベンダーからの提供情報
  14. 14. 監視データ 14 集めているデータは定量的でも... 一時的にバーストしているだけのようだ
  15. 15. 監視データ 15 このようなデータの残し方になっている ケースも多いのでは?
  16. 16. 監視データ 16 判断に必要となることを特徴量として定量的に残す ・平均値 ・最大値 ・最小値 ・中央値 ・回帰係数 ・移動平均値  等
  17. 17. 17 システム構成情報 サーバ構成 No ホスト名 IPアドレス OS 備考 1 web-server-01 192.168.111.11 RHEL7.3 web-server-02とのAct-Standby構成 2 web-server-02 192.168.111.12 RHEL7.3 web-server-01とのAct-Standby構成 3 db-server-01 192.168.111.31 RHEL7.3 db-server-02とのAct-Act(ReadReplica)構成 4 db-server-02 192.168.111.32 RHEL7.3 db-server-01とのAct-Act(ReadReplica)構成 5 db-lb-server-01 192.168.111.21 CentOS7 db-lb-server-02とのAct-Act構成 6 db-lb-server-02 192.168.111.22 CentOS7 db-lb-server-01とのAct-Act構成 SW/MW構成 No. ホスト SW/MW バージョン 1 web-server-01 web-server-02 nginx 1.14.0 2 pacemaker 1.1.18 3 zabbix-agent 3.0.19 4 db-server-01 db-server-02 PostgreSQL 9.6.5 5 JobScheduler Agent 1.12.0 これでは関係性とか評価が難しい ... たとえ、構成を図で表現されていたとしても ...
  18. 18. 18 システム構成情報 CMDBuild等の構成管理ツール
  19. 19. 19 システム構成情報 Terraformの定義情報と構成グラフ variable "count" {default = 2} variable "hostnames" { default = { "0" = "example1.org" "1" = "example2.net" } } data "template_file" "web_init" { count = "${length(var.hostnames)}" template ="${file("templates/web_init.tpl")}" vars { hostname ="${var.hostnames[count.index]}" } } resource "aws_instance" "web" { count = "${length(var.hostnames)}" user_data = "${data.template_file.web_init.*.rendered[count.index]}" } terraform graphコマンド
  20. 20. 20 システム構成情報 グラフDBに着目 ・構成をより自然な形で管理できる ・構成の特徴となる様々なデータを定量的に扱うことができる Service Cに経路が集中して重要度が高そうだ
  21. 21. 21 システム構成情報 ノードグラフから媒介中心性を求めるクエリ(Neo4j cypher) MATCH p = allShortestPaths((p1:Service)-[:connect*]-(p2:Service)) WHERE id(p1) < id(p2) AND length(p) > 1 UNWIND nodes(p)[1..-1] AS n RETURN n, count(*) AS betweeness ORDER BY betweeness DESC n betweeness Service C 5 Service B 3 Service A 3
  22. 22. それぞれの定量化を行うことで、システム全体の定量化ができ システムに対して行われる対処と状態を機械的に紐づけて管理していくことができるのではないか 状態の定量化 サーバA CPU使用率 平均 サーバA CPU使用率 最大値 サーバAが ホスト1で稼働 しているか サーバAに Nginxが 入っているか サーバAの Nginxの バージョンがx系か サーバAの Nginxの エラーログ発生数 サーバAの 経路重要度 ・・・ xx時間以内に実 行する対応 45 56 1 1 0 120 4.5 ・・・ 対応A 31 34 1 1 1 90 3.1 ・・・ 対応C 23 89 0 1 0 1 6.8 ・・・ 対応B ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ 22
  23. 23. 共有を目指して For to go toward the state of Sharing 23
  24. 24. Dashboard 24 データ集約基盤の提供 Core API (Events & Config management) Collector Zabbix Collector ConfDiff Collector Command Collector ・・・ Analyzer
  25. 25. Dashboard 25 データ集約基盤の提供 Core API (Events & Config management) Collector Zabbix Collector ConfDiff Collector Command Collector ・・・ Analyzer Zabbix Linux Server 監視統計データ集約 監視構成情報集約 設定パラメータ コマンドヒストリ 設定パラメータ変更情報集約 コマンド実行情報集約
  26. 26. 26 OpsBear(仮) ・OSS化も視野に検討・開発中 ・既存の有用なツールとの連携を軸に ・運用情報同士を紐づける基盤に 運用対応策のレコメンド
  27. 27. 運用イベント集約 27
  28. 28. イベントと紐づけた構成管理 28
  29. 29. 構成変更の管理 29
  30. 30. 監視統計データの確認 30
  31. 31. オペレーションの実行 31
  32. 32. 設定パラメータの検索確認 32
  33. 33. データ収集しつつ 「ある状態の時」に 「どういう対処を行う」可能性が 高いか? 分析検証中 33
  34. 34. ・プロトタイプレベルでも試してみたいという方 ・一緒に作ってみたいという方 ・一緒に意見出し合い検討してみたい方 34 協力者募集 TIS株式会社 池田まで
  35. 35. Thank you 35Presentation template by SlidesCarnival

×