クラウドサービスの自動化

クラウドコンピューティングサービスの出現は、IT部門が彼らの顧客にサービスを提供する方法に更なる選択肢を与えました。Amazon Web Services などのクラウドベンダーのサービスは、低コスト、短い配備時間などの利益をもたらしました。無限のクラウドコンピューティング資源は、アプリケーション処理の負荷に対し「オンデマンド」で処理能力を追加するのに使うことができます。オフサイトのクラウドストレージは、オンサイトのストレージの「無限容量」のデータバックアップを提供します。ここでは、これらのクラウドサービスを企業のITプロセスに効果的に統合するためのTap IN Systemのアプローチを説明します。

システム自動化の課題

ほとんどの企業ではITサービスは独立して配備されていません。ITサービスは、時間をかけて発展してきた人とプロセスおよびテクノロジーとの複雑な相互関係の一部です。クラウドサービスの適用可能性を評価する場合、人は必ず、これらのサービスが組織内の現在のITプロセスとポリシーに適合するかをたずねるでしょう。どうやったらIT運用はこれらの新しいサービスを効果的に管理できるか？
クラウドのベンダーが彼らのサービスを配備するために奨励している方法は、プログラム言語のAPIです。彼らは、エンドユーザ、サードパティーのベンダーやコンサルティング会社が有用なアプリケーションにクラウドサービスを統合するのに、これらのAPIを使うことができるのを期待しています。それはすべて単純なプログラミングの問題です。しかし、歴史的に、効率を最適化し、稼働率を向上させ、オペレータの作業負荷を削減する方法としてのシステム自動化の開発は困難でした。システム自動化はいつも、下記の特徴を持つソフトウェアのアプリケーション開発プロジェクトとして進められてきました。

プロジェクトチームは、エンドユーザとオペレータ、システム管理者およびアプリケーションプログラマで構成されます。ある種のシステム管理ツールは、言語やプロトコル、APIの標準化により、このプロセスを容易にする可能性がありますが、それでもコードを書くことになります。
IT運用部門の必要から要件が導かれますが、全体システムの設計は、その構築方法を知っているプログラマによって行われます。IT運用部門は自動化がどのように働くべきかについての運用経験を持ちますが、ソフトウェア開発のスキルを持つ者は稀です。なせなら、ソフトウェアを書くには実践的なIT運用には関係ない専門知識－コード言語知識、コーディングツール、リポジトリ使用法、コーディングのベストプラクティス、ビルドの手法、が必要だからです。
ほとんどのソフトウェア開発プロジェクトでは、新しいアプリケーションの開発に時間がかかります。IT部門は継続的に発展しているので、開発プロセス途中での要件変更がプロジェクトの再スタートを引き起こします。
開発後、アプリケーションの元々の目的が達成された後でも、プロセスの変更は自動化アプリケーションの変更を必要とします。このために、些細な変更であったとしても、元々のチームメンバーの関与が必要となるでしょう。メンテナンスのオーバヘッドシステムは、システムの自動化の継続性と一貫性を達成することが困難である主な理由のひとつです。
自動化が導入される際には、運用グループ、サービス提供責任者と、サービスに影響するイベントに対応するプログラムである自動化アプリケーションの間に信頼要素が確立している必要がある。これなしには、運用グループは自動化が信用できなくて障害の影響が破滅的だと考えるため、堅牢な自動化アプリケーションであっても配備されないでしょう。

ソフトウェアベンダーは、コーディングなしに使用できる製品を提案することで自動化システムの管理を支援するツールを提供します。しかし、それらのアプリケーションは一般的に下記のようです:

脆い。これらのベンダーは自動化シナリオを自分のアプリケーションのコード内にカプセル化しようとし、ユーザにその入力パラメータをカスタマイズできるようにします。これらのツールの実行可能性は、ユーザの定義がうまくできているのに依存します。入力パラメータ以外の変化は、アプリケーションで無視されるでしょう。各々の企業のITプロセスは自動化プロセスと緊密に強調しているので、ベンダーの自動化はカスタマイズ輔弼用性が高く、上述の問題を引き起こしやすいでしょう。
ベンダーの製品全体を必要とする。一般的に大きなソフトウェアベンダーは、サーバ管理、ネットワーク管理、アプリケーション管理にためのさまざまな製品－その各々のサブセットの付属製品、たとえばWindows 監視、Linux監視、Webアプリケーション監視、データベース監視などを持ちます。システム自動化は、さまざまのコンポーネント、テクノロジーやアプリケーション・プログラミング・インタフェースに亘る条件を必要とするので、顧客が個別業務を実行するそのベンダーの製品をすべて使っていれば、カスタマイズは容易化（売り込みも最適化）できます。
高額である。これらのアプリケーションを開発は複雑に入り組んでいるため、これらのツールのコストは直ぐに数十万ドル（数千万円）規模になってしまいます。

クラウド自動化

クラウドサービスは、とりわけ自動化が困難です。クラウドサービスをサポートするほとんどのアプリケーションはベンダーのAPI固有であり、そのため企業が有用だと考えられるアプリケーションは、異機種混合システムにわたるアクセスとコントロールが必要です。

これらのアプリケーションが持つ機能の例として下記があります。

クラウドのリソース・リカバリーの自動化。 Amazon EC2などのクラウドコンピューティングの価値はプログラムの制御下でスタートできることです。仮想化されたシステムはダイナミックにリソースを割り当てることができます。リカバリー自動化には、システムアラートに気がつく監視システムと、リソースをリスタートとする、クラウドサービスAPI間の相互作用が必要です。ITプロセスへの結び付きには、問題チケットの作成やリカバリー発生時のサービスレベルをトラッキングするための追跡運用担当者への通知が含まれます。
コンピュートクラウドをベースとした自動スケーリング。これはリカバリーシナリオのバリエーションです。この場合、自動スケーリング（スケールアップとダウン）のアクションはアプリケーション負荷に依存します。負荷の計算は、明示的あるいは暗黙に監視システム計測基準から提供され、クラウドAPIを使ってコンピュートインスタンスをスタートするトリガーとなります。他のアプリケーションコンポーネントとの統合の相互作用がさらなる複雑さを生じさせます。たとえば、Webサーバ機能を追加する場合、追加Webサーバ資源を定義するためにロードバランサーやアプリケーションコンポーネントを再構成する必要があります。構成変更を構成データベースに反映する必要があるITプロセスであれば、自動スケーリングプロセスは構成データベースと相互作用する必要があります。
クラウドストレージのバックアップ。クラウドストレージは理論的には「無限」で施設外にあるため、データセンターストレージのバックアップの良い候補です。自動化アプリケーションは、クラウドストレージへの転送を開始するため、監視システムからのストレージ容量をトリガーとするアラート、アプリケーション制御コマンドおよび、クラウドAPI アクションを連携させる必要があります。重要なアプリケーションデータを追跡監視するデータストレージのアプリケーションに通知する必要があります。
ハイブリッドアプリケーション。企業ITサービスは、ハイブリッドなアプリケーション－クラウド内と自社のデータセンター内にリソースを持つアプリケーションよって最もよく提供されるでしょう。たとえば、スケーラブルなコンポーネントのための、クラウドコンピュートサービスは、高速なネットワーク接続を最適化したデーセンター内のコンポーネントと組み合わせられるでしょう。クラウドと非クラウドのコンポーネント間の相互関係が自動化アプリケーションによって管理されます。
ベンダー横断的サービス。クラウドサービスを使用するデメリットのひとつに、ベンダーサービスがシングル・ポイント障害になる可能性があります。それを緩和するためのひとつの方法は、複数のクラウドサービスにリソースを分散することです。自動化アプリケーションは、下記を含む、これらサービスにまたがるアクティビティをコーディネートする必要があります:
- 複数のクラウドサービスAPIとインタフェースする
- ネットワークやコンポーネント障害を対比し、ベンダーの障害を認知する
- 一方の冗長クラウドサービスと協調するためコンポーネントを再構成する
- 両方のサービスでの変更と障害シナリオの計画と対処

クラウドサービスは、基本的にデータセンターの拡張なので、クラウドの自動化アプリケーションには、システムの自動化アプリケーションと同様な課題に、複数のベンダーのインタフェースに対応する複雑さが加わります。