sos jobschedulerを使った運用管理事例
TRANSCRIPT
Copyright © NHN Techorus Corp.
SOS Jobschedulerを使った運用管理事例
Page 2
自己紹介
名前
大久保 智之(おおくぼ ともゆき)
所属
NHNテコラス株式会社 SE部
経歴
SI系会社で顧客先に常駐して運用管理業務を中心に関わった後、
フォースクーナ(現NHNテコラス)でMSP業務に携わる
現在は主にクラウド環境に対し運用サービスの導入・運用を担当
Page 3
NHNテコラス概要
社名 NHN テコラス株式会社
設立 2007年4月
拠点 東京、大阪、浜松、福岡
資本金 21億円
事業内容 データセンター事業クラウド事業マネージド事業セキュリティ事業コマース支援事業広告支援事業
従業員数 472人(2016年5月末時点)
n h n - t e cho r u s . c o m
Page 4
沿革
Page 5
事業のご紹介
ITインフラ・マネージド事業 コマース支援事業
広告支援事業 セキュリティ事業
Page 6
データホテル事業について
クラウドホスティング/
データセンター
業界別ソリューション
医療 学校 放送
大容量動画ファイル高速転送ソリューション
クラウド型 Wi-Fi ソリューション
医用動画・画像共有ソリューション
クラウド構築・運用・監視
AWS請求代行・活用支援
AWS構築・運用パッケージ
インターネット接続
AWS Direct Connect
高速ファイル転送
ネットワーク
マネージドホスティング
マネージドデータセンター
コロケーション(国内・海外)
Page 7
今日の話題
×
Page 8
障害対応とジョブ管理システム
Page 9
ジョブ管理システムを使う利点
ジョブの集中管理 Cronやタスクスケジューラでもよいが、規模により管理が困難に
ジョブの制御 ジョブの順番や条件分岐、排他制御等の連携が保守しやすい
ジョブの実行履歴管理 分散管理の場合実行履歴が管理しやすい
Page 10
MSP事業者でよくある障害対応業務
監視システムからオペレーション担当者へ障害通知
オペレーション担当者が障害対応手順に基づくオペレーションを実施する
オペレーション担当者から顧客へ障害対応報告する
障害検知/通知
障害対応
障害復旧/通知
Page 11
障害対応業務とドキュメント
障害ケースに対する対応内容をまとめる=障害対応フロー
実際のオペレーション内容をまとめる=障害対応手順
障害検知/通知
障害対応
障害復旧/通知
Page 12
障害検知/通知
障害対応
障害復旧/通知
障害ケースに対する対応内容をまとめる=障害対応フロー
実際のオペレーション内容をまとめる=障害対応手順
障害対応業務とドキュメント
Page 13
障害対応ドキュメントを使ったオペレーションの課題
オペレーションの伝達 オペレーション内容はドキュメントを読む人の解釈が入る
オペレーションの再現性 同じことを100回、1000回、10000回行ったときどうか
オペレーションの修正コスト ドキュメントの修正と運用の落とし込みは案外時間が必要
Page 14
改善したい
オペレーションの伝達 情報の受け取り手が意図を解釈する負担を減らすには
オペレーションの再現性 同じことを何回繰り返しても同じ結果を得るには
オペレーションの修正コスト オペレーションの修正が運用業務に与える影響を減らすには
Page 15
ジョブ管理システムを障害対応ツールとして見ると…
ジョブの集中管理 障害対応オペレーションをジョブ管理システムで集中管理
ジョブの制御 障害対応オペレーションのジョブ化(部品化)
ジョブの実行履歴管理 障害対応オペレーション実績の記録
Page 16
SOS Jobschedulerの利用事例
Page 17
今回ご紹介する事例
基盤の環境:- Amazon Web Services(AWS)
環境概要:- 主にEC2を使ったWebシステム- 監視システム(Zabbix)を導入- ジョブ管理システム(SOS Jobscheduler)を導入
Page 18
体制 エンドユーザ様
開発会社様
NHNテコラスは24×365のシフト体制+アカウントSE
分担 エンドユーザ様:サービスの全体統括
開発会社様:アプリケーション及び実行環境部分のミドルウェア
NHNテコラス:AWS環境(OS・ミドルウェア含む)
プロジェクト体制
Page 19
監視運用設計 監視対象機器の選定
監視項目の定義
オペレーション設計 監視項目に対する1次対応オペレーションを決める
エスカレーション設計 プロジェクト関係者の役割を整理する
プロジェクト関係者の連絡先を整理する
「誰に」「どのような情報」を通知するか決める
運用設計
Page 20
監視運用と障害対応オペレーション設計の例
1次対応 URL ホスト
URL Xxxx Xxxx Xxxx
稼動状況の監視 URL監視 URL エスカレーション エスカレーション
個別監視 サービス監視 Apache プロセス再起動 プロセス再起動
Tomcat プロセス再起動 プロセス再起動
MySQL プロセス再起動 プロセス再起動
アプリケーションログ監視
アプリケーションログ
自動通知 自動通知 自動通知 自動通知
ベース監視 リソース監視 ロードアベレージ 自動通知 自動通知 自動通知 自動通知
メモリ利用率 自動通知 自動通知 自動通知 自動通知
ディスク使用率 自動通知 自動通知 自動通知 自動通知
プロセス監視 ntpd プロセス再起動 プロセス再起動 プロセス再起動 プロセス再起動
rsyslogd プロセス再起動 プロセス再起動 プロセス再起動 プロセス再起動
sshd プロセス再起動 プロセス再起動 プロセス再起動 プロセス再起動
エージェント監視 Zabbix Agent プロセス再起動 プロセス再起動 プロセス再起動 プロセス再起動
死活監視 Ping エスカレーションOS再起動
OS再起動 エスカレーション エスカレーション
Page 21
障害対応にジョブ管理システムを組み込んでみる?
ジョブ管理システムが障害対応ジョブ実行
ジョブ管理システムからの結果通知オペレーション担当者は結果確認必要に応じて顧客へ対応報告
監視システムからジョブ管理システムへ障害通知
障害検知/通知
障害対応
障害復旧/通知
Page 22
Zabbix+Jobscheduler連携の概要
メディア
アイテム情報
トリガ
アクション
トリガ設定
アイテム情報取得
外部スクリプト
JOB実行
API(SOAP)
アイテム結果出力
トリガ(成功:0)
トリガ(失敗:1)
アクションメディア
結果(zabbix_sender)
Page 23
ジョブ管理システムを組み込んでみた結果
オペレーションの伝達 障害対応フローがシンプルに
オペレーションの再現性 監視システムのアラートトリガーで障害対応ジョブを繰り返す
オペレーションの修正コスト オペレーションの修正=設定変更作業に変わりつつある
Page 24
今後の課題
複数台構成や複雑な障害対応 複数のノードが関係するオペレーションの実行はまだこれから
障害対応をジョブ化するための運用設計 自動化範囲を見極めるための運用設計ノウハウを溜める必要あり
ジョブ管理システム自体の運用管理 例えばオペレーション変更の業務プロセスをどう作っていくか
Page 25
余談:最後に
今回の仕組み、実は1つ注意事項があります。
何でしょう?
Page 26
メンテ中は監視止めないと何かが起きてしまう、かもしれない
余談:それは
Page 27
マネージドクラウドサービスのご紹介
Page 28
サービス紹介
府川 旭
twitter :@fukawa730
Tech Clips公式クリッパー
(https://tech-clips.com/)
FashionTech Talks主催
(#ft_talks)
Page 29
サービス紹介
同時リリース!!
Page 30
サービス紹介
運用レス志向の高まり
Web Apps + SQL DataBase + Blob
App Engine + Cloud SQL + Cloud Strage
Function as a Service
Serverless Architecture
MSPの淘汰は進む。でも運用は無くならない
Page 31
サービス紹介
むしろ・・・
DevOpsに向かえない
アプリエンジニアの淘汰が先に進む
そこに危機感持った人たちは
きっとたくさんいる
Page 32
サービス紹介
IaaS / PaaS 対応
認定エンジニアサポート
運用の自動化
インスタンス課金の廃止
初期費用ゼロ
請求書払い(手数料なし)
Page 33
サービス紹介
Liteプラン
クラウド利用料の3%
Standardプラン
クラウド利用料の10%
Professionalプラン
クラウド利用料の50%
Page 34
ご清聴ありがとうございました