Cuto紹介資料

エンジニア向け
プロセス制御OSSツール
『GoCuto(ゴーキュート)』
© 2015 UNIRITA Inc. All rights reserved.
株式会社ユニリタ

『攻め』と『守りと維持』のIT
1
2© 2015 UNIRITA Inc. All rights reserved.

『攻め』と『守り』と『維持』のIT
攻めのIT 守りのIT 維持のIT
事業部門、マーケなど情シス部門、IT子会社協力会社、委託先
俊敏、スピード、7割安定、安全、判断手順書ベース
売上/利益を生む安定した業務遂行ルールに従った行動
小規模、少人数大、マネジメント重視大量インフラ
プロセスの自動化サービスの自動化ルーチンの自動化
組織
特徴
目的
規模
自動化
事業社内/業務システムインフラ維持対象
高い課題に対しては高い低い投資意欲
クラウド、OSS 堅実、実績重視人手志向
垂直型なDevOps 社内/業務システム主にインフラ範囲

SoRとSoE
キャズムの著者であるジェフリームーアが提唱したシステムの分類。
従来の基幹システム : System of Record(SoR) 顧客視点的システム : System of Engagement(SoE)
FacebookなどのSNSを利用しているユーザに対し、どのような広告を展開することで『Like』が得られる
のか？ファンページが存在し2000名登録されていれば2000名には確実に広告が届きます。ですが、それは
単なる投げっぱなしな広告でしか有りえません。ソーシャルマーケティングでは、ファンがシェアすること
で、シェアしたファンのソーシャルへ更に広告が届いていき2乗、3乗と閲覧が増加することでファン増加、
ランディング増加を狙っているのが現在のソーシャルマーケティングです。
どのような広告の出し方で、どのような特性が得られるのかといった日々変化するSNS上の行動特性のよう
なものを取得することに対し大きな投資が行われているのが現状です。このような行動特性を得ることを
「Engagementを得る」といい、そのためのシステム化がSystem of Engagementと言われています。
基幹DB
会計システム
受発注システム
人事給与システム
販売管理システム
・・・
記録
System of Record
■主な特徴
・過去データの蓄積によるシステム
・ルール化による正確性が重要
・基本的に答えは○か×しか存在しない
・特定の結果を特定のルールで確認
・情報システム部門による維持管理
System of Engagement
ソーシャルネットワーク
スマホ
■主な特徴
・大量なデータに対する柔軟な解析とリアルタイムな分析
・状況に合わせ常に変化できる俊敏性が必要
・1つの場所だけみていても○か×かは判断できない
・早く試すことが求められる。失敗も多いが成功すると
急激にスケールする特徴がある。
BigData、BI、Marketing Automation、
アドテク、スマホアプリ
SoRとSoEの連携が
今後のテーマ Facebook、LINE、Twitterなど

ガートナーのペースレイヤリング
基幹システム革新システム
情報システム部、委託先DC
インフラ
実績、保守SaaS
システム構築ウォーターフォール反復型DevOps アジャイル
差異化システム
攻めのIT 守りと維持のIT
組織 ITでビジネスする企業事業部、マーケティング
信頼性とコスト効率重視試験的な取り組み業務知識とスピード
データとプロセス整合性特徴新技術で試験的基幹と連携の新プロセス
統制された変更管理管理中止権限持つチーム管理システム単位の管理
大手メーカー、ベンダー技術機能すれば何でもベストオブブリード
クラウド、OSS
アプリケーションのペースレイヤリングとして、攻めのITのアプリケー
ションはペースが速いことが特徴であると定義。

攻めのIT 特徴
特性1. 利用技術はオープンソース技術が多い
OSはLinux、利用技術はOSSツールが基本。
コストをミニマムに抑え、調達などに時間を有することなく必要な技術を各種OSS
ツールとしてダウンロード。
特性2. 全ての課題をコードで『書いて』解決
アプリケーションの開発に限らず、稼働環境の構築まで含め全てをコードで書いて
制御することが基本。
エンタープライズのように開発と運用のような役割が存在しない。DevOpsによる
運用まで見据えたアプリケーション構築であるため運用に関しても書いて解決する
ことを好む。
特性3. 画面利用による管理を嫌う
画面利用などによる管理が必須となる機能は基本的に利用されません。特性2にある
ようコードによる制御が基本となっており、制御のために管理が必要になるものは
後に運用管理が発生するため利用しない傾向が強い。

エンジニアの悩み
コードで書いて制御することを基本とするエンジ
ニアではありますが、無理してコードで制御して
いるケースが存在しています。
2

コードによる制御の限界
例えば、複数サーバで稼働するアプリケーションにおいて、サーバ間を
跨ってプロセス制御し、前後関係の依存関係を保ちたい場合。
Aサーバ Bサーバ
DB
プロセス1
cronから毎日15:00に定期実行
フラグエリア
プロセス2
cronから毎日15:10に定期実行
起動時に実行中FLG書込み。
終了時に終了FLG書込み。
起動時にFLG確認。
終了FLGを確認し、プロセス2
の処理を実行。
・サーバ間をcronの時差で実行。
・依存関係を保つためDB利用で
FLGチェックによる制御。
依存関係
プロセス1 → 2
上記解決手法は一般的によく利用されています。
数台のサーバであれば制御すべきプロセスも少なくシンプルに課題解決
できます。
しかし、大規模な仕組みにおいても同様の解決手法を用いることで多くの
ケースにて課題が発生しています。

ジョブ管理で解決しない理由
エンタープライズでも同様の課題は古くから存在。
規模が拡大すると商用『ジョブ管理』ツールを採用することが基本的な
解決策となっている。
革新システムのエンジニアは、ジョブ管理は利用していない。
OSSツールは、NTTデータ『Hinemos』、大和総研『JobAranger』、海外
OSSツール『SOS Jobscheduler』が存在。
これらツールの存在に関し把握しているもののプロセス制御の課題解決に
利用していない理由は以下の2つ。
① プロセス制御のために画面利用による管理が発生。
② 運用はコードで『Infrastructure as Code』が基本。
画面使うくらいなら、cronによるコード制御を選択。

悩みを解決するGoCuto
「Infrastructure as Code」の実現と共に、サー
バ間、サービス間のプロセス連携制御をコードで
実現可能とするOSSツールがGoCutoです。
3

GoCutoの概要
プロセス制御
GoCuto master
プロセス実行
GoCuto servant
■GoCuto master
ジョブ実行の「プロセスフロー」に対する全体制御と実行結果の記録
を行う非常駐プログラム。
本プログラムを直接もしくは外部ソフトウェアから実行することで、
ジョブ実行制御を実現。
プロセス実行
GoCuto servant
プロセス実行
GoCuto servant
■GoCuto servant
GoCuto masterで指定されたプロセスフローの各プロセスを実行するためのエージェント
機能。GoCuto masterからの制御指示にてプロセス実行。実行した際のリターンコードや
出力メッセージなどを後続のプロセスへ連携することも可能。
・・・
ジョブ実行
ジョブ連携
GoCutoはcronによる制御では難しいサーバ間、システム間のプロセスを簡
単に連携しプロセス制御を実現するOSSツールです。

静的制御プロセスフロー定義イメージ
CUTOJOB01 CUTOJOB02
CUTOJOB03
CUTOJOB04
CUTOJOB2A
CUTOJOB3A
CUTOJOB4A
Aサーバ
Bサーバ
Cサーバ
DサーバCUTOJOB05 CUTOJOB5A
*02→*2A、 *03→*3A、 *04→*4A、
*05→*5Aのジョブ連携では、直前に
実行された結果のリターンコードを後
ろのジョブへ変数として渡す。
イメージ①
CUTOJOB01 CUTOJOB02
イメージ②
CUTOJOB03
CUTOJOB04
CUTOJOB3A
CUTOJOB4A
Aサーバ
Bサーバ
Cサーバ
プロセスフロー名称 : cuto_flow_01
プロセスフロー名称 : cuto_flow_02
CUTOJOB2A

静的制御① プロセスフロー Excel定義
14
■プロセスフロー定義イメージ
GoCutoではプロセスフローをExcelにて定義いただくことでプロセスフ
ローの実行に必要なbpmnファイルを生成します。
拡張ジョブ定義CSVファイル
cutojob1 < cutojob2 cutojob2a >
cutojob3 cutojob3a
cutojob4 cutojob4a
cutojob5 cutojob5a
ジョブ名実行ノード
ポート
番号
実行ファ
イル
実行
時引
数
実行時環境変数
作業
ディレ
クトリ
警告終了
コード下限
警告終了出
力パターン
異常終了コード
下限
cutojob01 A_Server 2016 1
cutojob02 A_Server 2016 8
cutojob2a A_Server 2016 JOBRC2=$MJcutojob2:RC$ 1
cutojob03 B_Server 2016 8
cutojob3a B_Server 2016 JOBRC3=$MJcutojob3:RC$ 1
cutojob04 C_Server 2016 8
cutojob4a C_Server 2016 JOBRC4=$MJcutojob4:RC$ 1
cutojob05 D_Server 2016 8
cutojob5a D_Server 2016 JOBRC5=$MJcutojob5:RC$ 1

静的制御② プロセスフロー Text定義
15
■プロセスフロー定義イメージ
プロセスフローは、Excel以外の方法でも定義可能です。
下の例の通り、テキスト形式で定義した後、付属のユーティリティを利用
することで、プロセス実行に必要なbpmnファイルを作成します。
job1->job2->[job3,job4,job5->job6]->job7
【上記が表現するフロー】
[job1]━[job2]┳[job3]━━━━┳[job7]
┣[job4]━━━━┫
┗[job5]━[job6]┛

動的制御 JSON形式のプロセスフロー定義
16
■JSON形式のプロセスフロー
GoCutoでは、JSON形式でもプロセスフローを指定することができます。
Webアプリケーション上でJSON形式のプロセスフローを作成し、そのURL
をGoCutoに渡す事で、bpmnファイルを作成することなく、プロセスフロー
を実行できます。
Webアプリ
{
"flow":"フロー定義",
"jobs":[
{"name":"ジョブ1",“node":“PC1"},
{"name":"ジョブ2",“node":“PC2"},
.....
]
}
GoCuto
①フロー作成
②URL指定で実行
③JSONをダウンロード
④実行開始

JSON形式のプロセスフロー定義イメージ
17
■JSON形式のプロセスフロー定義イメージ
{
"flow":"job1->job2->[job3,job4,job5->job6]->job7",
"jobs":[
{"name":"job1","node":"123.45.67.89","port":"1234"},
{"name":"job2","env":"RESULT=$MJjob3:RC$"}
]
}
要素名 flow に定義するジョブの流れは、前ページの定義方法と同じです。

GoCuto実行イメージ① cuto_flow_01
18
月曜日～金曜日の毎日、AM10:00に「cuto_flow_01」を自動実行。
■cron またはタスクスケジューラから定期実行
master.exe –n cuto_flow_01 –s <CR
Aサーバ Bサーバ Cサーバ Dサーバ
ジョブ実行ジョブ実行ジョブ実行
servant.exe 常駐 servant.exe 常駐 servant.exe 常駐 servant.exe 常駐
CUTOJOB02 CUTOJOB03 CUTOJOB04
CUTOJOB2A CUTOJOB3A CUTOJOB4A
CUTOJOB05
CUTOJOB5A
Aサーバ
※master環境はservantと同居する必要
なく、どこからでも実行可能。
CUTOJOB01

GoCuto実行イメージ② cuto_flow_02
19
土曜と日曜日のみ、PM18:00に「cuto_flow_02」を自動実行。
■cron またはタスクスケジューラから定期実行
master.exe –n cuto_flow_02 –s <CR
Aサーバ Bサーバ Cサーバ
servant.exe 常駐 servant.exe 常駐 servant.exe 常駐
Aサーバ
※master環境はservantと同居する必要
なく、どこからでも実行可能。
CUTOJOB3A CUTOJOB4ACUTOJOB2A
CUTOJOB01

GoCutoだから簡単にできる便利機能①
CUTOJOB01
RC = 0008
CUTOJOB02
後続起動
GETRC=$MJcutojob01:RC$
拡張ジョブ定義CSVファイルの
CUTOJOB02の実行時環境変数
へ上記内容を記述。
CUTOJOB02内で変数GETRC
を利用しCUTOJOB01のRCを
取得可能。
後続起動
GETRC=$MJcutojob01:RC$
拡張ジョブ定義CSVファイルの
CUTOJOB03の実行時環境変数
へ上記内容を記述。
CUTOJOB03内で変数GETRC
を利用しCUTOJOB01のRCを
取得可能。
先に稼働したジョブの実行結果となる戻り値を後続起動のジョブへ引き渡すことが可能です。
例えば、Aサーバで実行されたCUTOJOB01のRCを後続のBサーバで稼働するCUTOJOB02、
同じく後続のCサーバで稼働するCUTOJOB03へパラメータとして渡すことなどが可能です。
CUTOJOB03

GoCutoだから簡単にできる便利機能②
CUTOJOB01
stdout = “normalend cutojob01”
CUTOJOB02
後続起動
先に稼働したジョブ内で最後に出力された標準出力を後続起動のジョブへ引き渡すことが可能
です。
例えば、Aサーバ、Bサーバ、Cサーバにてパラレルで稼働したCUTOJOB01、CUTOJOB02、
CUTOJOB03の各ジョブで出力された最終の標準出力をAサーバで後続起動される
CUTOJOB04へパラメータとして渡すことが可能です。
CUTOJOB03
stdout = “normalend cutojob02” stdout = “normalend cutojob03”
CUTOJOB04
GETMSG01=$MJcutojob01:OUT$+GETMSG02=$MJcutojob02:OUT$+GETMSG03=$MJcutojob03:OUT$
拡張ジョブ定義CSVファイルのCUTOJOB04の実行時環境変数へ上記内容を記述。
CUTOJOB04内で変数GETMSG01、02、03を利用しCUTOJOB01、02、03の最終出力MSG(stdout)を取得可能。

GoCutoだから簡単にできる便利機能③
22
ジョブを実行するサーバントは、2つまで設定できます。
あるジョブの実行先に、AサーバとBサーバを定義しておくと、Aサーバが停
止状態の場合は、Bサーバで実行します。
下の例では、Bサーバを「セカンダリ」と登録し、Aサーバで実行できない
場合にのみ、Bサーバで実行されます。
Aサーバ Bサーバ
servant servant
CUTOJOB01CUTOJOB01
master
マシンダウン
本来ならばA
サーバで実行
代わりにB
サーバで実行

GoCutoだから簡単にできる便利機能④
プロセスフローが異常終了した場合、異常終了したジョブから再実行することが可能です。
例えば、CUTOJOB03が異常終了した場合、再実行すると、CUTOJOB03から開始します。
CUTOJOB03で異常終了
servant servant servant
CUTOJOB3A CUTOJOB4ACUTOJOB2A
CUTOJOB01
異常
終了
未実行
リランモードで実行
未実行未実行
再実行
開始
※master – servant間の通信の
問題で異常終了した場合は、
CUTOJOB03の処理が、正常終
了しています。
その場合は、CUTOJOB03を起
動せずに後続ジョブを開始しま
す。

公式サイトなど
４

GoCuto ホームページ(http://cuto.unirita.co.jp/cuto/)

その他関連サイト
 マニュアル（日本語のみ）
http://cuto.unirita.co.jp/cuto/manual/
 Github
https://github.com/unirita/cuto
 Facebookファンページも公開しております。

Cuto紹介資料

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Cuto紹介資料

Similar to Cuto紹介資料 (20)

Cuto紹介資料