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）

アイテム結果出力

トリガ（成功：０）

トリガ（失敗：１）

アクションメディア

結果（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

ご清聴ありがとうございました