自動スケーリング

クラウドの自動スケーリングの例

この方法を使ってどのようにシステム自動化が導入されるかの例を見ていきましょう。
クラウドアプリケーションの共通的な要求に負荷に従って、サーバのスケーリングを自動化できることがあります。負荷（ユーザは負荷計算方法を定義できます）が閾値を超えたら、キャパシティを追加します。閾値を下回ったら、課やシティを削減します。

Tap In の Control Plan Editor を使って、下記のペトリネットを作成しました。

Control Plan Editor ユーザインタフェースでは、ドラック＆ドロップの操作でプレースを作成し、トランジションを接続できます。コントロールプランは自動スケーリングのワークフローを示します。プレースは下記の作業タスクを示します:

Check_Capacity -- Tap In 監視システムからの読み出しイベントで、負荷の閾値に達したことを示唆します。
インスタンスをList（リスト表示）、run（実行）および terminate（終了）します。これらは、クラウドシステムの稼動中コンピュートインスタンスをリストしたり、コンピュートインスタンスをスタートしたり、コンピュートインスタンスを終了させたりするために、API 呼び出しを開始します。このプランでは、これらのAPI呼び出しはプレースでカプセル化されているので、必要ならば他のクラウドベンダーの呼び出しに容易に変更できます。このことから、社内ITプロセスとベンダーのクラウドサービスのサポートとの分離が明らかです。
エラーレポート。これらのプレースは、監視ツールや通知メソッドへのエラーメッセージを生成します。これにより、自動化と運用担当者間のコミュニケーションを保証します。

このプランを実行すると、コントロールプランは、プランのカラーコードによってどのタスクが実行されているかを表示します。下図のように、キャパシティの閾値よりも負荷が低かったのでスケールダウンのタスクが実行されました。このプランでは、"terminate_instances" タスクがスケールダウン処理中で実施されます。

プランは、"end"プレースに着いたため、ここで完了しました。

そのプランが実行された場合の他の可能性は、負荷がキャパシティを超え、スケールアップのプロセスを実行するべきだと示すことです。この場合、まず、そのプランは、スタートするよう要求されたイメージが実際に存在するかを見るため、すべてのイメージをリストアップ（"describe_images"）します。存在しなければ、このイメージのインスタンスがスタートされるでしょう。プランは、定期的にチェックして、そのインスタンスが稼動状態になるのを保証します。下の図は、プランが、既存イメージのチェックによりスケールアップのプロセスをスタートするのを示しています。

下の図は、プランが、既存イメージのチェックによりスケールアップのプロセスをスタートするのを示しています。

このケースでは、イメージが検出され、インスタンスがスタートされました。そのプランは、今、インスタンスが稼動（"running"）状態になるのを待っています。

インスタンスは稼動状態になり、そしてインスタンスがうまく稼動した通知が、終了の前に送られます。

他の自動化アプリケーションでなく、コントロールプランを使用する利点は明白です。

コントロールプランのグラフィカルエディタを使うことにより、モデルが簡単に作れます。そのモデルはプログラム構成でなく、運用プロセスを表すため、経験のある運用担当者責任がそのプランを確認するのに適しています。
各プレースのタスクは、あらかじめパッケージ化されたモジュールや（Ruby や Java）のコードです。アプリケーション開発者は、彼ら自身の専門エリア－APIの実行とプログラムコンポーネント間の相互動作に集中することができます。
オペレータは、これらのアクションを自分で作成しテストしているので、信頼できます。上述のように、プランの実行状態を目で見ることもできます。また、オペレータは、プラン中に適当な通知を挿入することで、自動化タスクが適切にステータスの通信をしていることを確認できます。
コントロールプランの保守はもっと簡単です。定義済みのタスクはプランの変更によって追加できます。下記の画面図は、プランで使用可能なテンプレートを示します。

モデルにプレースのタスクを追加することは、ユーザはテンプレートをキャンバスにドラッグするだけでできます。たとえば、エラー発生時のｅメール通知を追加するには、email Notificationテンプレートをキャンバスにドラッグしてネットのエラー（error）セクションの中に置くだけです。

自動化プランを保守するための運用に対する能力は、ひとつの重要な利点です。たとえ新しいプレースタスクを追加するのに追加プログラミングが必要になった場合でも、自動化プラン全体を書き換える必要はありません。開発者は新しいプレースのタスクを作成し、オペレータがそれをモデルの中に置けるようにするだけです。

コントロールプランのモデルを使った開発方法は非常に柔軟です。オペレータは、関心のあるアプリケーション状態を定義し、それらの状態を判断するアクションとロジックを導入することにより、トップダウンのモデリング方法を使うことができます。基本的でハイレベルなモデルが開発されると、他のコントロールプランで個々のプレースを置き換えることにより、より複雑なロジックが使用できます。他のプラン内でプレースとして使用できるプランをスーパーノード（supernode）と呼びます。

上述の例の中に、システムの現在負荷を調べることでキャパシティが超過しているかどうかを計算するプレースがありました。しかし、この判断ポイントは、単一の変数を見るだけよりも、もっと複雑かもしれません。たとえば、そのロジックは、サーバの負荷、現在のユーザ数、時刻、曜日、稼動中のWebサーバの現在数や使用中のデータベース接続数などを参照するアルゴリズムを必要とするかもしれません。われわれは、それらの変数をカプセル化し、キャパシティが閾値を超えたか、下回ったか、それともOKかを出力とするコントロールプランを作成できます。このプランは、上レベルのダイアグラム内でのcheck_capacityプレースのスーパーノードとして定義できます。この機能によって、複雑なモデルを作成するためのプランの階層化が行えます。さらに必要に応じて、オペレータはその複雑さをハイレベルのプラン内で隠蔽することができます。