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.

運用自動化のためのプログラミング言語の作り方

2,882 views

Published on

  • Be the first to comment

運用自動化のためのプログラミング言語の作り方

  1. 1. 運用自動化のための プログラミング言語の作り方(仮) 株式会社フィックスポイント 服部健太
  2. 2. ITシステムの運用管理とは             システムの障害監視、リソース監視 障害対応、影響範囲の調査、復旧作業 実際の業務は 変更管理、構成管理 多岐にわたる データのバックアップ DNS、FW、LBなどの各種設定変更 Webコンテンツファイル更新 ユーザーアカウントの追加、設定変更 SSL証明書の更新 セキュリティパッチの適用 OS、ミドルウェア、アプリケーションのインストール、バージョンアップ ユーザーからの問い合わせの対応 ・・・
  3. 3. 運用現場の実情          webサイトの目視チェックを毎日行っている SSL証明書の更新が重なり、毎日更新作業で終わってしまう webサーバへのコンテンツ配布を手作業でやっている サーバリソースの閾値越えアラートが発生した際にtopコマンド の値をコピペして顧客に報告メールを送っている ディスク使用率の閾値越えのアラートが発生した際に過去の ファイルを削除して、ディスクスペースに空きを作っている 設定の変更依頼が頻繁にあり、設定やテストの為に人が1~2人、 常にはりつきで作業している ミドルウェアのバージョンを調べ、古かったら手作業でバー ジョンアップをやっている システムやサーバ毎に担当が分かれており、どこにどんなバッ チがあるか管理できていない 担当者変更やシステム移行の際、調査から始めなければならな い
  4. 4. オペレータの典型的な業務 作業記録 情報収集 設定変更 ログファイル取 得 スクリプト実行 手順書 オペレータ エスカレーション 報告メール送信 手順書にしたがって対象システムにログインし、 コマンド実行やWeb操作を行う
  5. 5. 運用現場の問題点  問題点1:高負荷  運用現場は、業務負荷が高くて困っている  「運用」の守備範囲が不明確で、「なんでも運用」、「運用でカ バー」に陥りがち  結果として、数多くのタスクが現場に落ちてくる  問題点2:属人的  運用現場は、属人的で、暗黙知が多くて困っている  タスクやフローが多岐にわたるため、ドキュメントの作成や更新 が追いつかない  結果として、現場の業務知識が属人化する  問題点3:費用対効果が見えない  運用現場は、費用対効果が見えにくくて困っている  開発に比べて、利益につながるアウトプットが見えにくいため、 コストカットの対象となりやすい  結果として現場の士気が下がる 波多野:見えない「運用」 - 疲弊する運用現場、より要約
  6. 6. どうやって解決する?  やっぱり自動化でしょ。  現場の声:  スクリプトなら書いているよ  ChefやPuppetを使ってできるところはやっているよ  いろんなツールを導入しても、多様な運用業務全て をカバーするのは不可能  かえってツールの管理コストがかさむだけ  シンプルで自由度の高い万能なツールが欲しい! そうだ、運用をプログラミングしよう!!!
  7. 7. Kompiraの概要  運用自動化のためのプラットフォーム  オペレータはサーバの運用手順をジョブフローとして記 述し、それをKompiraサーバ上で実行する
  8. 8. Kompiraサーバのシステム構成
  9. 9. 実現に向けた課題 シンプルで一貫した連携処理をどうやって提供するか?  連携処理のための自動化手順をどうやって記述するか?  独自のDSLであるジョブフロー言語を用いて記述  ジョブフローはリモートマシン上で実行するコマンド列を指定す る  様々なツールと連携するにはどうする?  外部から非同期に発生するイベントをチャネルから統一的に受信  何らかの並行処理を扱えるようにする  ツールからのデータやコマンドの実行結果をどう扱うか?  オブジェクトストレージを提供し、ジョブフローから統一的にア クセス可能にする  そこで扱うデータの型はユーザーが独自に定義できるようにする
  10. 10. 自動化手順の記述方式の比較 記述方式 記述容易性 NonPG/PG 実装コス ト 機能性 並行処理 の導入 しやすさ 保護 しやすさ グラフィカル ◎/× × ○ ◎ ◎ 既存スクリプ ト言語 ×/◎ ◎ ◎ × × 内部DSL △/◎ ○ ◎ × × 外部DSL ○/○ ○ ○ ◎ ◎  既存スクリプト言語や内部DSLの場合、インタプリタに まで手を加えて、並行処理の導入やユーザーコードから の保護を実現するのは大変 実装コストと並行処理、保護性を重視し、 独自の外部DSL方式を採用
  11. 11. グラフィカル vs テキスト 大手ベンダー製の グラフィカルなジョブ 定義 Kompiraのテキストに よるジョブフロー定義 { fork | <イベント待ち1> <イベント待ち2> } -> [前処理] -> { fork | [処理1] -> [処理2] [処理A] -> [処理B] } -> [後処理]
  12. 12. ジョブフロー記法  特長  ジョブ/ジョブフロー名に、日本語(utf-8)が使える  矢印記号(->, =>, ->>, =>>)でジョブをつないでいく記 法  ジョブ実行の処理の流れを把握しやすい  並行処理、チャネルによるイベントの待ち合わせ  ジョブ:ジョブフローにおける処理の単位  コマンド実行:[‘cat /etc/redhat-release’]  ジョブフローの呼び出し: [/障害管理/インシデント新規作成: 名前=‘new’]  イベント待ち:<./監視アラートチャネル>  変数の代入:[URL=‘http://kompira.jp’, パス=‘/foo/bar’]  組み込みジョブ:print(‘Hello’), mailto(addr, title, body)な ど
  13. 13. リモートコマンドの実行  実行コンテクストを特殊変数で指定し、コマンド ジョブを実行する  __host__, __user__, __password__, __dir__, __sudo__ など  コマンドの実行結果は特殊変数に格納される  $RESULT  コマンド実行時の標準出力結果が格納される  $STATUS  コマンド実行の終了ステータスが格納される  例: [__host__ = ‘192.168.213.33’, __user__ = ‘kompira’, __password__ = ‘secret’ ] -> [‘hostname’] -> print($RESULT)
  14. 14. 結合子(矢印)の意味 コマンド実行のエラーチェックをいちいち記述するのは 煩雑 結合子 -> リモートコマンド 異常終了時 abort リモートログイン 失敗時 abort => 継続 abort ->> abort 継続 =>> 継続 継続
  15. 15. 基本的な制御構文  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] }
  16. 16. 外部イベントの取得 障害発生のアラートメール受信、SNMPトラップなど、非同期 に発生する外部イベントは、チャネルを通じて統一的に受信  例:メール受信したら、本文の解析処理を行う <./メール受信> -> [./メール解析: $RESULT]  choiceブロック  複数種類のイベントを待つことも可能 { choice | <./メール受信> -> print(‘メールを受信しました’) <./SNMPトラップ受信> -> print(‘SNMPトラップが発生しました’) }
  17. 17. 並行処理のサポート  forkブロック  プロセスを並行に処理する  メール送信と障害対応を並行して処理する例: { fork | [./メール送信] [./障害対応処理] } -> print(‘完了しました’)  pforブロック  同じ処理を一斉に実行する  サーバ一覧にあるサーバに対してホスト情報を一斉に取 得 { pfor host in ./サーバ一覧 | [./ホスト情報取得: host] -> print($RESULT) }
  18. 18. オブジェクトストレージ • 様々なツールとの連携には、やりとりするデータを共 通の領域に格納する必要がある • UnixライクなファイルシステムをWebアプリの上に実 装  Kompiraが扱う様々な種類のオブジェクトを階層構造に格納  ジョブフロー  ユーザーアカウント情報  機器情報  などなど  ジョブフローからは、相対パス、絶対パスでオブジェクトに アクセス可能  ユーザー毎のパーミッション制御も実装  特定のユーザーやグループからアクセスできないオブジェクト  URLとオブジェクトパスは自然に対応
  19. 19. ユーザーによる型定義  ユーザーが型オブジェクトを定義することで新た な種類のオブジェクトが作成できるようになる  ビューや入力用フォームが自動生成される  ジョブフローからのフィールドアクセスも可能  例:連絡先情報を新たに定義したい フィールド名 フィールド表示名 フィールド種別 name 氏名 String address 住所 Text phone 電話番号 PhoneNumber email Eメール EmailAddress
  20. 20. どこまで自動化すべきか? 自動化によって削減されるコスト > 自動化にかかるコスト  自動化に向いているもの  手順化が簡単(単純な規則にもとづく作業)  何度も繰り返し行う作業  自動化に向いていないもの  手順化できない、手間が大変(高度、複雑な判断が必要な作業)  一回ポッキリの作業 人間向きの 高度な作業 単純な 定型処理 ・・・ ・・・ Kompira オペレータ Kompira オペレータ Kompira
  21. 21. 期待できる効果 典型的な監視センター業務の内訳 1次障害対応 定常運用 その他 サービス改善 定常運用 20% その他 19% サービス改善 1次障害対応 45% 16% 自動化に適した作業 典型的なMSPでは、最大で60%から70%程度の効率化が可能
  22. 22. 今後の課題  ノンプログラマがジョブフローを書くのは難しい  Kompiraのターゲット層の明確化  ジョブフローレシピ集の充実  ウェブブラウザ操作の自動化  運用現場でGUIポチポチは自動化の敵  Selenium等との連携?  自動化に頼り切るとKompira障害時にお手上げ?  難しい問題ではあるが、Kompira障害を想定した防 災訓練などによってオペレータのレベルを維持する ことは可能?

×