プロシン54発表資料

システム系ソフトウェア、クラウドを中心としたプロフェッショナルサポート集団へ

Kompira：シンプルで軽量なIT運用自動化プラットフォーム

フォースクーナ株式会社服部健太・溝江真也・三角正樹


ITシステムの運用管理とは

2013/1/12第54回プログラミング・シンポジウム2

システムの障害監視、リソース監視

障害対応、影響範囲の調査、復旧作業

変更管理、構成管理

データのバックアップ

DNS、FW、LBなどの各種設定変更

Webコンテンツファイル更新

ユーザーアカウントの追加、設定変更

SSL証明書の更新

セキュリティパッチの適用

OS、ミドルウェア、アプリケーションのインストール、バージョンアップ

ユーザーからの問い合わせの対応

・・・

実際の業務は多岐にわたる


運用現場の実情


webサイトの目視チェックを毎日行っている

SSL証明書の更新が重なり、毎日更新作業で終わってしまう

webサーバへのコンテンツ配布を手作業でやっている

サーバリソースの閾値越えアラートが発生した際にtopコマンドの値をコピペして顧客に報告メールを送っている

ディスク使用率の閾値越えのアラートが発生した際に過去のファイルを削除して、ディスクスペースに空きを作っている

設定の変更依頼が頻繁にあり、設定やテストの為に人が1～2人、常にはりつきで作業している

ミドルウェアのバージョンを調べ、古かったら手作業でバージョンアップをやっている

システムやサーバ毎に担当が分かれており、どこにどんなバッチがあるか管理できていない

担当者変更やシステム移行の際、調査から始めなければならない


手順書の例（弊社の障害対応フロー）


顧客によって対応手順が微妙に変わる場合もある


オペレーションミスによる障害事例


ファーストサーバ事故（2012年6月20日）

担当者が長年使用してきた独自プログラムで更新作業を実施

プログラムの修正ミスにより、誤ってファイル削除

約5700件の顧客データを焼失

全日空座席予約システム事故（2012年11月28日）

営業担当者が誤って座席予約情報を削除

2013年2月搭乗分の国内線航空券の約10万6000席が取り消し

Amazonクラウド障害（2012年12月24日）

メンテナンス作業中にELB(Elastic Load Balancer)のステートデータを誤って削除

削除に気付かず、しばらく障害が拡大

NetflixのWebサイトや動画の再生に問題


運用現場の問題点


問題点１：高負荷

運用現場は、業務負荷が高くて困っている

「運用」の守備範囲が不明確で、「なんでも運用」、「運用でカバー」に陥りがち。結果として、数多くのタスクが現場に落ちてくる

問題点２：属人的

運用現場は、属人的で、暗黙知が多くて困っている

タスクやフローが多岐にわたるため、ドキュメントの作成や更新が追いつかない。結果として、現場の業務知識が属人化する

問題点３：費用対効果が見えない

運用現場は、費用対効果が見えにくくて困っている

開発に比べて、利益につながるアウトプットが見えにくいため、コストカットの対象となりやすい。結果として現場の士気が下がる

波多野：見えない「運用」 - 疲弊する運用現場、より要約


Kompiraの目指すところ


手順化属人化

自動化手動

整頓混沌

連携バラバラ

見える化見えない

Kompiraを使うことで運用現場をハッピーにしたい


統合運用管理ツール


ベンダー製ツール

日立JP1

IBM Tivoli

富士通 SystemWalker

NEC WebSAM

HP Operation Orchestration

NetIQ Aegis

オープンソース

Hinemos

Crane

大手ベンダー製ツールは大変高価なのでなかなか手が出ない


システム運用管理に使えるOSS


監視ツール系

Nagios

Zabbix

Icinga

Cacti

Pandora FMS

問題管理系

Redmine

Trac

構成管理系

Chef

Puppet

デプロイメント系

Fabric

Capistrano

バックアップ系

Amanda

Mondo Rescue

ツール間の連携は人手で行うため効率化に限界がある


オペレータの典型的な業務


スクリプト実行

情報収集

エスカレーション

作業記録

手順書にしたがって対象システムにログインし、コマンド実行やWeb操作を行う

設定変更

報告メール送信

ログファイル取得

オペレータ

手順書


Kompiraのコンセプト


Kompira

サーバー監視Nagios, Zabbix, ・・・

ジョブ管理

構成管理Chef, Puppet, ・・・

問題管理Redmine, Trac,・・・

インシデント管理変更管理

Subversion, ・・・

作業記録管理

資産管理GLPI, ・・・

ナレッジベースKBPublisher, Wiki, ・

・・ログ管理

連携処理基盤

連携記述

連携記述

連携記述・・・

レポート作成

• 運用管理に求められる機能は多岐にわたるため、これをそのまま実装していくと肥大化ソフトウェアが出来上がる

• 既存ツールをなるべく利用し、連携自動化処理の部分に集中する


実現に向けた課題


連携処理のための自動化手順をどうやって記述するか？独自のDSLであるジョブフロー言語を用いて記述

ジョブフローはリモートマシン上で実行するコマンド列を指定する

様々なツールと連携するにはどうする？外部から非同期に発生するイベントをチャネルから統一的に受

信

何らかの並行処理を扱えるようにする

ツールからのデータやコマンドの実行結果をどう扱うか？オブジェクトストレージを提供し、ジョブフローから統一的に

アクセス可能にする

そこで扱うデータの型はユーザーが独自に定義できるようにする

シンプルで一貫した連携処理をどうやって提供するか？


自動化手順の記述方式の比較


既存スクリプト言語や内部DSLの場合、インタプリタにまで手を加えて、並行処理の導入やユーザーコードからの保護を実現するのは大変

記述方式記述容易性NonPG／PG

実装コスト

機能性並行処理の導入

しやすさ

保護しやすさ

グラフィカル ◎／× × ○ ◎ ◎

既存スクリプト言語

×／◎ ◎ ◎ × ×

内部DSL △／◎ ○ ◎ × ×

外部DSL ○／○ ○ ○ ◎ ◎

実装コストと並行処理、保護性を重視し、独自の外部DSL方式を採用


グラフィカル vs テキスト


{ fork |

<イベント待ち1>

<イベント待ち2> }

-> [前処理] -> { fork |

[処理1] -> [処理2]

[処理A] -> [処理B] } -> [後処理]

大手ベンダー製の

グラフィカルなジョブ定義

Kompiraのテキストによるジョブフロー定義


ジョブフロー記法


特長ジョブ/ジョブフロー名に、日本語(utf-8)が使える

矢印記号（->, =>, ->>, =>>）でジョブをつないでいく記法

ジョブ実行の処理の流れを把握しやすい

並行処理、チャネルによるイベントの待ち合わせ

ジョブ：ジョブフローにおける処理の単位コマンド実行：[‘cat /etc/redhat-release’]

ジョブフローの呼び出し：

[/障害管理/インシデント新規作成: 名前=‘new’]

イベント待ち：<./監視アラートチャネル>

変数の代入：[URL=‘http://kompira.jp’, パス=‘/foo/bar’]

組み込みジョブ：print(‘Hello’), mailto(addr, title, body)など


リモートコマンドの実行


実行コンテクストを特殊変数で指定し、コマンドジョブを実行する __host__, __user__, __password__, __dir__, __sudo__など

コマンドの実行結果は特殊変数に格納される $RESULT

コマンド実行時の標準出力結果が格納される

$STATUS

コマンド実行の終了ステータスが格納される

例：[__host__ = ‘192.168.213.33’,

__user__ = ‘kompira’,

__password__ = ‘secret’ ]

-> [‘hostname’] -> print($RESULT)


結合子（矢印）の意味

結合子リモートコマンド異常終了時

リモートログイン失敗時

-> abort abort

=> 継続 abort

->> abort 継続

=>> 継続継続

コマンド実行のエラーチェックをいちいち記述するのは煩雑


基本的な制御構文


ifブロック{ if x > 0 |

then: [./処理1] else: [./処理2] }

caseブロック{ case $RESULT |

‘*OK*’: [./処理OK]

‘*NG*’: [./処理NG] }

whileブロック{ while x == 0 | [./処理] -> [./処理2] }

forブロック{ for host in ./サーバ一覧 |

[./ログファイル取得: host] }


外部イベントの取得


例：メール受信したら、本文の解析処理を行う<./メール受信> -> [./メール解析: $RESULT]

choiceブロック複数種類のイベントを待つことも可能{ choice |

<./メール受信>

-> print(‘メールを受信しました’)

<./SNMPトラップ受信>

-> print(‘SNMPトラップが発生しました’) }

障害発生のアラート、メール受信、SNMPトラップなど、非同期に発生する外部イベントは、チャネルを通じ

て統一的に受信


並行処理のサポート


forkブロックプロセスを並行に処理する

メール送信と障害対応を並行して処理する例：{ fork |

[./メール送信]

[./障害対応処理] } -> print(‘完了しました’)

pforブロック同じ処理を一斉に実行する

サーバ一覧にあるサーバに対してホスト情報を一斉に取得

{ pfor host in ./サーバ一覧 |

[./ホスト情報取得: host]

-> print($RESULT) }


オブジェクトストレージ


Kompiraが扱う様々な種類のオブジェクトを階層構造に格納ジョブフローユーザーアカウント情報機器情報などなど

ジョブフローからは、相対パス、絶対パスでオブジェクトにアクセス可能

ユーザー毎のパーミッション制御も実装特定のユーザーやグループからアクセスできないオブジェクト

URLとオブジェクトパスは自然に対応

• 様々なツールとの連携には、やりとりするデータを共通の領域に格納する必要がある

• UnixライクなファイルシステムをWebアプリの上に実装


ユーザーによる型定義


ユーザーが型オブジェクトを定義することで新たな種類のオブジェクトが作成できるようになる

カスタマイズが容易にできる

例：連絡先情報を新たに定義したい

フィールド名フィールド表示名フィールド種別

name 氏名 String

address 住所 Text

phone 電話番号 PhoneNumber

email Eメール EmailAddress


Kompiraシステム構成


リモートコマンドの実行にsshを用いるた

め、エージェント不要

Kompiraサーバをイント

ラ内部に設置する場合、ジョブマネージャは

Kompiraサーバ上で動作可能


ライセンスファイル発行業務の自動化


弊社管理部社員は、Kompiraのライセンス申請書を受け取ると、ライセンスファイルを発行し、顧客に送付する業務を行う1. 弊社内のLinuxサーバにログインする

2. 有効期限やノードIDなどを引数に与えて所定のプログラムを実行する

3. この際、ライセンスファイルデータが標準出力に出力されるので、適切なファイルにリダイレクトして保存する

4. 保存したファイルを自分のPCにコピーする

5. 作成されたライセンスファイルをメールに添付して、顧客に送付するノンプログラマにとってLinuxサーバにログインし、コマ

ンドを実行し、出力結果のファイルを取得してもらうのはハードル高い


その他の使用例


リリース用バイナリパッケージの作成1. Bitbucketからソースコードをexport

2. ビルドコマンド実行し、tarボール作成

3. 生成したファイルをアップロード

公式ウェブサイトのコンテンツ更新1. デザイナが所定のディレクトリにコンテンツをアップ

ロード

2. アップロードされたコンテンツをStaging環境に展開

3. 上長に内容確認依頼のタスクを送信

4. OKなら、本番サイトをバックアップし、ステージングの内容を本番サイトにコピー

5. ステージング環境を削除


サーバ障害の自動対応の例


１．Webサーバの応答に異常発生

２．監視サーバからアラートがあがる

３．Kompiraサーバでアラートを受信

４．KompiraがWebサーバにログインし、

プロセス調査

５．Kompiraが障害を確認、関係者に障

害メール送信

６．Kompiraがプロセス再起動

７．Kompiraが復旧確認

８．Kompiraが関係者に復旧メール送信

Kompira

監視システム

監視対象システム

２

３

４

Administrator

５

１

６

７

８


どこまで自動化すべきか？


自動化に向いているもの手順化が簡単（単純な規則にもとづく作業）

何度も繰り返し行う作業

自動化に向いていないもの手順化できない、手間が大変（高度、複雑な判断が必要な作

業）

一回ポッキリの作業

自動化によって削減されるコスト＞自動化にかかるコスト

人間向きの高度な作業

単純な定型処理

・・・・・・

オペレータオペレータKompiraKompira Kompira


期待できる効果

2013/1/1228 第54回プログラミング・シンポジウム

弊社監視センター業務の内訳

1次障害対応

定常運用

その他

サービス改善

1次障害対応 45%

定常運用 20%

その他 19%

サービス改善 16%

典型的なMSPでは、最大で60％から70%程度の効率化が可能

自動化に適した作業


今後の課題


ウェブブラウザ操作の自動化

Selenium等との連携？

Windows対応

WMI、WinRMなどを使う？

ジョブフローの可読性はどうなのか？

編集はテキストベース、表示は箱と矢印でグラフィカルに

ジョブフローのテストをどうするか？

現状はステップ実行機能のみサポート

自動化に頼り切ると、Kompira障害時にお手上げ

難しい問題ではあるが、Kompira障害を想定した防災訓練などによってオペレータのレベルを維持することは可能？


まとめ


ITシステム運用管理のための基盤ソフトKompiraを開発

様々な管理ツールと連携し、統合するための基盤ツール

UnixライクなファイルシステムをWeb上に実装

オペレータはウェブブラウザからジョブの実行、結果を取得

独自DSLのジョブフロー言語によって自動化処理を記述

Kompira公式サイト http://www.kompira.jp

Technology

プロシン54発表資料